kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Add controllingi access and authorization for pt-br

pull/34097/head
Jose Almaraz 2022-06-01 15:20:24 +02:00
parent 1571c32cfd
commit 1745ad5e79
2 changed files with 434 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

186
content/pt-br/docs/concepts/security/controlling-access.md Normal file
View File

@ -0,0 +1,186 @@
---
title: Controlando Acesso à API do Kubernetes
content_type: concept
---
<!-- overview -->
Esta página fornece uma visão geral do controle de acesso à API do Kubernetes.
<!-- body -->
Usuários podem acessar a [API do Kubernetes](/pt-br/docs/concepts/overview/kubernetes-api/) utilizando `kubectl`,
bibliotecas, ou executando requisições REST. Ambos, usuários humanos e
[Contas de serviço do Kubernetes](/pt-br/docs/tasks/configure-pod-container/configure-service-account/) podem ser autorizados
a acessar a API.
Quando uma requisição chega a API, ela passa por diversos estágios,
ilustrados no seguinte diagrama:
![Diagrama de etapas de tratamento de requisições enviadas a API do Kubernetes](/images/docs/admin/access-control-overview.svg)
## Segurança na camada de transporte
Em um tipico cluster Kubernetes, a API fica disponível na porta 443, protegida por segurança na camada de transporte (TLS).
O servidor de API apresenta um certificado. Este certificado pode ser assinado utilizando
uma autoridade privada de certificados (CA), ou baseado em uma infraestrutura de chave publica ligada
a uma autoridade de certificados reconhecida publicamente.
Se o seu cluster utiliza uma autoridade privada de certificados, voce precisa de uma copia do certificado
da autoridade de certificados (CA) dentro do arquivo de configuração `~/.kube/config`, no lado do cliente, para que
voce possa confiar na conexão e tenha a garantia de que nao ha interceptação de trafico.
O seu cliente pode apresentar o certificado de cliente TLS neste estagio.
## Autenticação
Uma vez em que a segurança na camada de transporte (TLS) é estabelecida, a requisição HTTP move para o passo de autenticação.
Isto é demonstrado no passo **1** no diagrama abaixo.
O script de criação do cluster ou configurações de administração configuram o servidor de API para executar
um ou mais módulos autenticadores.
Autenticadores sao descritos em maiores detalhes em
[Autenticação](/pt-br/docs/reference/access-authn-authz/authentication/).
A entrada para o passo de autenticação é a completa requisição HTTP; no entanto, tipicamente
sao verificados os cabeçalhos e/ou o certificado de cliente.
Módulos de autenticação incluem certificados de cliente, senhas, tokens simples,
tokens de auto-inicialização e JSON Web Tokens (utilizados para contas de serviço).
Vários módulos de autenticação podem ser especificados, em que cada um é tentado em sequência,
até que um deles tenha sucesso.
Se a requisição nao pode ser autenticada, será rejeitada com o código de status HTTP 401 (não autorizado).
Caso contrário, o usuário é autenticado com um "nome de usuário" específico e o nome de usuário
está disponível para as etapas subsequentes para usar em suas decisões. Alguns autenticadores
também fornecem as associações de grupo do usuário, enquanto outros autenticadores
não o fazem.
Enquanto o Kubernetes usa nomes de usuário para decisões de controle de acesso e no registro de requisições,
ele não possui um objeto `user` nem armazena nomes de usuários ou outras informações sobre
usuários em sua API.
## Autorização
Apos a requisição ser autenticada é originada de um usuário especifico, a requisição deve ser autorizada. Isso é mostrado no passo **2** no diagrama.
Uma requisição deve incluir o nome do usuário requerente, a ação requisitada e o objeto afetado pela ação. A requisição é autorizada se uma
politica existente declarar que o usuário tem as devidas permissões para concluir a ação requisitada.
Por exemplo, se Bob possui a politica abaixo, então ele somente poderá ler pods no namespace `projectCaribou`:
```json
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}
```
Se Bob fizer a seguinte requisição, a requisição será autorizada porque ele tem permissão para ler objetos no namespace `projectCaribou`:
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "projectCaribou",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
}
}
}
```
Se Bob fizer uma requisição para escrever (`create` ou `update`) em objetos no namespace `projectCaribou`, sua autorização será negada. Se Bob fizer uma requisição para ler (`get`) objetos em um namespace diferente, como `projectFish`, sua autorização será negada.
A autorização do Kubernetes requer que você use atributos comuns a REST para interagir com os sistemas de controle de acesso existentes em toda uma organização ou em todo o provedor de nuvem utilizado. É importante usar a formatação REST porque esses sistemas de controle podem interagir com outras APIs além da API do Kubernetes.
O Kubernetes oferece suporte a vários módulos de autorização, como o modo de controle de acesso baseado em atributos (ABAC), o modo de controle de acesso baseado em função (RBAC) e o modo Webhook. Quando um administrador cria um cluster, ele configura os módulos de autorização que devem ser utilizados no servidor de API. Se mais de um módulo de autorização for configurado, o Kubernetes verificará cada módulo e, se algum módulo autorizar a requisição, a requisição poderá prosseguir. Se todos os módulos negarem a requisição, a requisição será negada (com código de status HTTP 403 - Acesso Proibido).
Para saber mais sobre a autorização do Kubernetes, incluindo detalhes sobre como criar políticas usando os módulos de autorização compatíveis, consulte [Authorization](/pt-br/docs/reference/access-authn-authz/authorization/).
## Controle de admissão
Os módulos de controle de admissão são módulos de software que podem modificar ou rejeitar requisições.
Além dos atributos disponíveis para os módulos de Autorização, os módulos do controlador de admissão
podem acessar o conteúdo do objeto que está sendo criado ou modificado.
Os controladores de admissão atuam em requisições que criam, modificam, excluem ou se conectam a um objeto (proxy).
Os controladores de admissão não agem em requisições que apenas leem objetos.
Quando vários controladores de admissão são configurados, eles são chamados em ordem.
Isso é mostrado como etapa **3** no diagrama.
Ao contrário dos módulos de autenticação e autorização, se algum módulo controlador de admissão
rejeita, a solicitação é imediatamente rejeitada.
Além de rejeitar objetos, os controladores de admissão também podem definir padrões complexos para
campos.
Os módulos de Controle de Admissão disponíveis são descritos em [Controladores de Admissão](/pt-br/docs/reference/access-authn-authz/admission-controllers/).
Após uma requisição passar por todos os controladores de admissão, ela é validada usando as rotinas de validação
para o objeto de API correspondente e, em seguida, gravados no armazenamento de objetos (mostrado como etapa **4** no diagrama).
## Auditoria
A auditoria do Kubernetes fornece um conjunto de registros cronológicos relevantes para a segurança que documentam a sequência de ações em um cluster.
O cluster audita as atividades geradas pelos usuários, pelos aplicativos que usam a API do Kubernetes e pela própria camada de gerenciamento.
Para mais informações, consulte [Auditoria](/pt-br/docs/tasks/debug/debug-cluster/audit/).
## Portas e IPs do servidor de API
A discussão anterior se aplica a requisições enviadas para a porta segura do servidor de API
(o caso típico). O servidor de API pode realmente servir em 2 portas.
Por padrão, o servidor da API Kubernetes atende HTTP em 2 portas:
1. Porta `localhost`:
- destina-se a testes e auto-inicialização e a outros componentes do nó mestre
(scheduler, controller-manager) para falar com a API
- sem segurança na camada de transporte (TLS)
- o padrão é a porta 8080
- IP padrão é localhost, mude com a flag `--insecure-bind-address`.
- requisitar módulos de autenticação e autorização **ignora**.
- requisição tratada pelo(s) módulo(s) de controle de admissão.
- protegido pela necessidade de ter acesso ao host
2. “Porta segura”:
- utilize sempre que possível
- utiliza segurança na camada de transporte (TLS). Defina o certificado com `--tls-cert-file` e a chave com a flag `--tls-private-key-file`.
- o padrão é a porta 6443, mude com a flag `--secure-port`.
- IP padrão é a primeira interface de rede não localhost, mude com a flag `--bind-address`.
- requisição tratada pelos módulos de autenticação e autorização.
- requisição tratada pelo(s) módulo(s) de controle de admissão.
- módulos de autenticação e autorização executados.
## {{% heading "whatsnext?" %}}
Consulte mais documentação sobre autenticação, autorização e controle de acesso à API:
- [Autenticando](/pt-br/docs/reference/access-authn-authz/authentication/)
- [Autenticando com tokens de auto-inicialização](/pt-br/docs/reference/access-authn-authz/bootstrap-tokens/)
- [Controladores de Admissão](/pt-br/docs/reference/access-authn-authz/admission-controllers/)
- [Controle de Admissão Dinâmico](/pt-br/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [Autorização](/pt-br/docs/reference/access-authn-authz/authorization/)
- [Controle de acesso baseado em função](/pt-br/docs/reference/access-authn-authz/rbac/)
- [Controle de acesso baseado em atributos](/pt-br/docs/reference/access-authn-authz/abac/)
- [Autorização Node ](/pt-br/docs/reference/access-authn-authz/node/)
- [Webhook de Autorização](/pt-br/docs/reference/access-authn-authz/webhook/)
- [Requisições de assinatura de certificado](/pt-br/docs/reference/access-authn-authz/certificate-signing-requests/)
- including [Aprovação de Requisições de assinatura de certificado](/pt-br/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
and [Assinando certificados](/pt-br/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
- Contas de serviço
- [Guia do desenvolvedor](/pt-br/docs/tasks/configure-pod-container/configure-service-account/)
- [Administração](/pt-br/docs/reference/access-authn-authz/service-accounts-admin/)
Você pode aprender mais sobre:
- como os pods podem usar
[Secrets](/pt-br/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
para obter credenciais de API.

248
content/pt-br/docs/reference/access-authn-authz/authorization.md Normal file
View File

@ -0,0 +1,248 @@
---
title: Visão geral sobre autorização
content_type: concept
weight: 60
---
<!-- overview -->
Aprenda mais sobre autorização no Kubernetes, incluindo detalhes sobre
criação de politicas utilizando módulos de autorização suportados.
<!-- body -->
No Kubernetes, você deve estar autenticado (conectado) antes que sua requisição possa ser
autorizada (permissão concedida para acesso). Para obter informações sobre autenticação,
visite [Controlling Access to the Kubernetes API](/pt-br/docs/concepts/security/controlling-access/).
O Kubernetes espera atributos que são comuns a requisições de APIs REST. Isto significa
que autorização no Kubernetes funciona com sistemas de controle de acesso a nível de organizações
ou de provedores de nuvem que possam lidar com outras APIs além das APIs do Kubernetes.
## Determinar se uma requisição é permitida ou negada
Kubernetes autoriza requisições de API utilizando o servidor de API. Ele avalia
todos os atributos de uma requisição em relação a todas as políticas disponíveis a permite ou nega a requisição.
Todas as partes de uma requisição de API deve ser permitido por alguma política para que possa prosseguir.
Isto significa que permissões sao negadas por padrão.
(Embora o Kubernetes use o servidor de API, controles de acesso e políticas que
dependem de campos específicos de tipos específicos de objetos são tratados pelo Admission
Controller.)
Quando múltiplos modules de autorização são configurados, cada um será verificado em sequência.
Se qualquer dos autorizadores aprovarem ou negarem uma requisição, a decisão é imediatamente
retornada e nenhum outro autorizador é consultado. Se todos os módulos de autorização não tiverem
nenhuma opinião sobre requisição, então a requisição é negada. Uma negação retorna um
código de status HTTP 403.
## Revisão de atributos de sua requisição
O Kubernetes revisa somente os seguintes atributos de uma requisição de API:
* **user** - O string de `user` fornecido durante a autenticação.
* **group** - A lista de nomes de grupos aos quais o usuário autenticado pertence.
* **extra** - Um mapa de chaves de string arbitrárias para valores de string, fornecido pela camada de autenticação.
* **API** - Indica se a solicitação é para um recurso de API.
* **Caminho da requisição** - Caminho para diversos endpoints sem recursos, como `/api` ou `/healthz`.
* **Verbo de requisição de API** - Verbos da API como `get`, `list`, `create`, `update`, `patch`, `watch`, `delete` e `deletecollection` que são utilizados para solicitações de recursos. Para determinar o verbo de requisição para um endpoint de recurso de API , consulte [Determine o verbo da requisição](/pt-br/docs/reference/access-authn-authz/authorization/#determine-the-request-verb).
* **Verbo de requisição HTTP** - Métodos HTTP em letras minúsculas como `get`, `post`, `put` e `delete` que são utilizados para requisições que não são de recursos.
* **Recurso** - O identificador ou nome do recurso que está sendo acessado (somente para requisições de recursos) -- Para requisições de recursos usando os verbos `get`, `update`, `patch` e `delete`, deve-se fornecer o nome do recurso.
* **Subrecurso** - O sub-recurso que está sendo acessado (somente para solicitações de recursos).
* **Namespace** - O namespace do objeto que está sendo acessado (somente para solicitações de recursos com namespace).
* **Grupo de API** - O {{< glossary_tooltip text="API Group" term_id="api-group" >}} sendo acessado (somente para requisições de recursos). Uma string vazia designa o _core_ [Grupo de API](/pt-br/docs/reference/using-api/#api-groups).
## Determine o verbo da requisição {#determine-the-request-verb}
**Requisições de não-recursos**
Requisições para endpoints diferentes de `/api/v1/...` ou `/apis/<group>/<version>/...`
são considerados "requisições sem recursos" e usam o método HTTP em letras minúsculas da solicitação como o verbo.
Por exemplo, uma solicitação `GET` para endpoints como `/api` ou `/healthz` usaria `get` como o verbo.
**Requisições de recursos**
Para determinar o verbo de requisição para um endpoint de API de recurso, revise o verbo HTTP
utilizado e se a requisição atua ou não em um recurso individual ou em uma
coleção de recursos:
Verbo HTTP | Verbo de Requisição
---------- |---------------
POST | create
GET, HEAD | get (para recursos individuais), list (para coleções, includindo o conteúdo do objeto inteiro), watch (para assistir um recurso individual ou coleção de recursos)
PUT | update
PATCH | patch
DELETE | delete (para recursos individuais), deletecollection (para coleções)
Às vezes, o Kubernetes verifica a autorização para permissões adicionais utilizando verbos especializados. Por exemplo:
* [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/)
* `use` verbo em recursos `podsecuritypolicies` no grupo `policy` de API.
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
* `bind` e `escalate` verbos em `roles` e recursos `clusterroles` no grupo `rbac.authorization.k8s.io` de API.
* [Authentication](/pt-br/docs/reference/access-authn-authz/authentication/)
* `impersonate` verbo em `users`, `groups`, e `serviceaccounts` no grupo de API principal, e o `userextras` no grupo `authentication.k8s.io` de API.
## Modos de Autorização {#authorization-modules}
O servidor da API Kubernetes pode autorizar uma solicitação usando um dos vários modos de autorização:
* **Node** - Um modo de autorização de finalidade especial que concede permissões a `kubelets` com base nos `pods` que estão programados para execução. Para saber mais sobre como utilizar o modo de autorização do nó, consulte [Node Authorization](/pt-br/docs/reference/access-authn-authz/node/).
* **ABAC** - Attribute-based access control (ABAC), ou Controle de acesso baseado em atributos, define um paradigma de controle de acesso pelo qual os direitos de acesso são concedidos aos usuários por meio do uso de políticas que combinam atributos. As políticas podem usar qualquer tipo de atributo (atributos de usuário, atributos de recurso, objeto, atributos de ambiente, etc.). Para saber mais sobre como usar o modo ABAC, consulte [ABAC Mode](/pt-br/docs/reference/access-authn-authz/abac/).
* **RBAC** - Role-based access control (RBAC), ou controle de acesso baseado em função, é um método de regular o acesso a recursos de computador ou rede com base nas funções de usuários individuais dentro de uma empresa. Nesse contexto, acesso é a capacidade de um usuário individual realizar uma tarefa específica, como visualizar, criar ou modificar um arquivo. Para saber mais sobre como usar o modo RBAC, consulte [RBAC Mode](/pt-br/docs/reference/access-authn-authz/rbac/)
* Quando especificado RBAC (Role-Based Access Control) usa o group de API `rbac.authorization.k8s.io` para orientar as decisões de autorização, permitindo que os administradores configurem dinamicamente as políticas de permissão por meio da API do Kubernetes.
* Para habilitar o modo RBAC, inicie o servidor de API (apiserver) com a opção `--authorization-mode=RBAC`.
* **Webhook** - Um WebHook é um retorno de chamada HTTP: um HTTP POST que ocorre quando algo acontece; uma simples notificação de evento via HTTP POST. Um aplicativo da Web que implementa WebHooks postará uma mensagem em um URL quando ocorrerem determinadas coisas. Para saber mais sobre como usar o modo Webhook, consulte [Webhook Mode](/pt-br/docs/reference/access-authn-authz/webhook/).
#### Verificando acesso a API
`kubectl` fornece o subcomando `auth can-i` para consultar rapidamente a camada de autorização da API.
O comando usa a API `SelfSubjectAccessReview` para determinar se o usuário atual pode executar
uma determinada ação e funciona independentemente do modo de autorização utilizado.
```bash
# "can-i create" = "posso criar"
kubectl auth can-i create deployments --namespace dev
```
A saída é semelhante a esta:
```
yes
```
```shell
# "can-i create" = "posso criar"
kubectl auth can-i create deployments --namespace prod
```
A saída é semelhante a esta:
```
no
```
Os administradores podem combinar isso com [user impersonation](/pt-br/docs/reference/access-authn-authz/authentication/#user-impersonation)
para determinar qual ação outros usuários podem executar.
```bash
# "can-i list" = "posso listar"
kubectl auth can-i list secrets --namespace dev --as dave
```
A saída é semelhante a esta:
```
no
```
Da mesma forma, para verificar se uma ServiceAccount chamada `dev-sa` no Namespace `dev`
pode listar Pods no namespace `target`:
```bash
# "can-i list" = "posso listar"
kubectl auth can-i list pods \
--namespace target \
--as system:serviceaccount:dev:dev-sa
```
A saída é semelhante a esta:
```
yes
```
`SelfSubjectAccessReview` faz parte do grupo de API `authorization.k8s.io`, que
expõe a autorização do servidor de API para serviços externos. Outros recursos em
este grupo inclui:
* `SubjectAccessReview` - * `SubjectAccessReview` - Revisão de acesso para qualquer usuário, não apenas o atual. Útil para delegar decisões de autorização para o servidor de API. Por exemplo, o kubelet e extensões de servidores de API utilizam disso para determinar o acesso do usuário às suas próprias APIs.
* `LocalSubjectAccessReview` - Similar a `SubjectAccessReview`, mas restrito a um namespace específico.
* `SelfSubjectRulesReview` - Uma revisão que retorna o conjunto de ações que um usuário pode executar em um namespace. Útil para usuários resumirem rapidamente seu próprio acesso ou para Interfaces de Usuário ocultarem/mostrar ações.
Essas APIs podem ser consultadas criando recursos normais do Kubernetes, onde a resposta `status`
campo do objeto retornado é o resultado da consulta.
```bash
kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
resourceAttributes:
group: apps
resource: deployments
verb: create
namespace: dev
EOF
```
A `SelfSubjectAccessReview` gerada seria:
```yaml
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
creationTimestamp: null
spec:
resourceAttributes:
group: apps
resource: deployments
namespace: dev
verb: create
status:
allowed: true
denied: false
```
## Usando flags para seu módulo de autorização
Você deve incluir uma flag em sua política para indicar qual módulo de autorização
suas políticas incluem:
As seguintes flags podem ser utilizadas:
* `--authorization-mode=ABAC` O modo de controle de acesso baseado em atributos [Attribute-Based Access Control (ABAC)] permite configurar políticas usando arquivos locais.
* `--authorization-mode=RBAC` O modo de controle de acesso baseado em função [Role-based access control (RBAC)] permite que você crie e armazene políticas usando a API Kubernetes.
* `--authorization-mode=Webhook` WebHook é um modo de retorno de chamada HTTP que permite gerenciar a autorização usando endpoint REST.
* `--authorization-mode=Node` A autorização de nó é um modo de autorização de propósito especial que autoriza especificamente requisições de API feitas por kubelets.
* `--authorization-mode=AlwaysDeny` Esta flag bloqueia todas as requisições. Utilize esta flag somente para testes.
* `--authorization-mode=AlwaysAllow` Esta flag permite todas as requisições. Utilize esta flag somente se nao existam requisitos de autorização para as requisições de API.
Você pode escolher mais de um modulo de autorização. Módulos são verificados
em ordem, então, um modulo anterior tem maior prioridade para permitir ou negar uma requisição.
## Escalonamento de privilégios através da criação ou edição da cargas de trabalho {#privilege-escalation-via-pod-creation}
Usuários que podem criar ou editar pods em um namespace diretamente ou através de um [controlador](/pt-br/docs/concepts/architecture/controller/)
como, por exemplo, um operador e então poderiam escalar privilégios naquele namespace.
{{< caution >}}
Administradores de sistemas, tenham cuidado ao permitir acesso para criar ou editar cargas de trabalho.
Detalhes de como estas permissões podem ser usadas de forma maliciosa podem ser encontradas em [caminhos para escalonamento](#escalation-paths).
{{< /caution >}}
### Caminhos para escalonamento {#escalation-paths}
- Montar segredos arbitrários nesse namespace
- Pode ser utilizado para acessar segredos destinados a outras cargas de trabalho
- Pode ser utilizado para obter um token da conta de serviço com maior privilegio
- Usando contas de serviço arbitrárias nesse namespace
- Pode executar ações da API do Kubernetes como outra carga de trabalho (personificação)
- Pode executar quaisquer ações privilegiadas que a conta de serviço tenha
- Montagem de configmaps destinados a outras cargas de trabalho nesse namespace
- Pode ser utilizado para obter informações destinadas a outras cargas de trabalho, como nomes de host de banco de dados.
- Montar volumes destinados a outras cargas de trabalho nesse namespace
- Pode ser utilizado para obter informações destinadas a outras cargas de trabalho e alterá-las.
{{< caution >}}
Administradores de sistemas devem ser cuidadosos ao instalar CRDs que
promovam mudanças nas areas mencionadas acima. Estes podem abrir caminhos para escalonamento.
Isto deve ser considerado ao decidir os controles de acesso baseado em função (RBAC).
{{< /caution >}}
## {{% heading "whatsnext?" %}}
* Para aprender mais sobre autenticação, visite **Authentication** in [Controlando acesso a APIs do Kubernetes](/pt-br/docsconcepts/security/controlling-access/).
* Para aprender mais sobre Admission Control, visite [Utilizando Admission Controllers](/pt-br/docs/reference/access-authn-authz/admission-controllers/).