From 2f2272897f4eaba15cbabd5ce59bf758aa7e5334 Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Wed, 10 Aug 2022 15:07:35 +0200 Subject: [PATCH 01/10] Adding the translation to brazilian portuguese for authorization --- .../access-authn-authz/authorization.md | 248 ++++++++++++++++++ 1 file changed, 248 insertions(+) create mode 100644 content/pt-br/docs/reference/access-authn-authz/authorization.md diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md new file mode 100644 index 0000000000000..8ad311a0b79e9 --- /dev/null +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -0,0 +1,248 @@ +--- +title: Autorização +content_type: concept +weight: 60 +--- + + +Aprenda mais sobre autorização no Kubernetes, incluindo detalhes sobre +criação de politicas utilizando módulos de autorização suportados. + + + +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 [Controlando Acesso à API do Kubernetes](/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///...` +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/). \ No newline at end of file From 0a816da12065104f2cf941b55a1f9c32c0fdc5f1 Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Wed, 10 Aug 2022 15:54:05 +0200 Subject: [PATCH 02/10] moving links not yet translated to base doc --- .../reference/access-authn-authz/authorization.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index 8ad311a0b79e9..c3a6f9ec0bdd1 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -49,7 +49,7 @@ O Kubernetes revisa somente os seguintes atributos de uma requisição de API: * **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). + * **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](/docs/reference/using-api/#api-groups). ## Determine o verbo da requisição {#determine-the-request-verb} @@ -85,12 +85,12 @@ DELETE | delete (para recursos individuais), deletecollection (para coleçõ 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/) + * **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](/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](/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](/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/). + * **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](/docs/reference/access-authn-authz/webhook/). #### Verificando acesso a API @@ -244,5 +244,5 @@ Isto deve ser considerado ao decidir os controles de acesso baseado em função ## {{% 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/). \ No newline at end of file +* Para aprender mais sobre autenticação, visite **Authentication** in [Controlando acesso a APIs do Kubernetes](/pt-br/docs/concepts/security/controlling-access/). +* Para aprender mais sobre Admission Control, visite [Utilizando Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). \ No newline at end of file From 53016dbc6770ccae16305c77daae5e4eefda22c8 Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Thu, 18 Aug 2022 14:44:26 +0200 Subject: [PATCH 03/10] addressing review items --- .../access-authn-authz/authorization.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index c3a6f9ec0bdd1..8d06676767396 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -20,10 +20,10 @@ ou de provedores de nuvem que possam lidar com outras APIs além das APIs do Kub ## 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. +O 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 e permite ou nega a requisição. +Todas as partes de uma requisição de API deve ser permitidas por alguma política para que possa prosseguir. +Isto significa que permissões são 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 @@ -225,12 +225,12 @@ Detalhes de como estas permissões podem ser usadas de forma maliciosa podem ser ### 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 +- Montar Secret arbitrários nesse namespace + - Pode ser utilizado para acessar Secret destinados a outras cargas de trabalho + - Pode ser utilizado para obter um token da conta de serviço com maior privilégio - 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 + - Pode executar quaisquer ações privilegiadas que a conta de serviço tenha acesso - 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 @@ -238,11 +238,11 @@ Detalhes de como estas permissões podem ser usadas de forma maliciosa podem ser {{< caution >}} Administradores de sistemas devem ser cuidadosos ao instalar CRDs que -promovam mudanças nas areas mencionadas acima. Estes podem abrir caminhos para escalonamento. +promovam mudanças nas áreas 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?" %}} +## {{% heading "whatsnext" %}} * Para aprender mais sobre autenticação, visite **Authentication** in [Controlando acesso a APIs do Kubernetes](/pt-br/docs/concepts/security/controlling-access/). * Para aprender mais sobre Admission Control, visite [Utilizando Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). \ No newline at end of file From 05f324fb18e373bcd03e95fd08da77e205555f9a Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Fri, 23 Sep 2022 16:55:36 +0200 Subject: [PATCH 04/10] sorry, I left lots of reviewed items left --- .../access-authn-authz/authorization.md | 40 +++++++++---------- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index 8d06676767396..31fbc55c95073 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -1,5 +1,5 @@ --- -title: Autorização +title: Visão Geral de Autorização content_type: concept weight: 60 --- @@ -26,12 +26,11 @@ Todas as partes de uma requisição de API deve ser permitidas por alguma polít Isto significa que permissões são 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.) +dependem de campos específicos de tipos específicos de objetos são tratados pelos controladores de admissão.) -Quando múltiplos modules de autorização são configurados, cada um será verificado em sequência. +Quando múltiplos módulos 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 +retornada e nenhum outro autorizador é consultado. Se nenhum módulo de autorização tiver nenhuma opinião sobre requisição, então a requisição é negada. Uma negação retorna um código de status HTTP 403. @@ -43,10 +42,10 @@ O Kubernetes revisa somente os seguintes atributos de uma requisição de API: * **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`. + * **Caminho da requisição** - Caminho para diversos endpoints que não manipulam 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. + * **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](/docs/reference/using-api/#api-groups). @@ -54,8 +53,7 @@ O Kubernetes revisa somente os seguintes atributos de uma requisição de API: ## 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///...` +Requisições sem recursos de `/api/v1/...` ou `/apis///...` 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. @@ -79,18 +77,18 @@ DELETE | delete (para recursos individuais), deletecollection (para coleçõ * [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. + * `impersonate` verbo em `users`, `groups`, e `serviceaccounts` no grupo de API `core`, 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](/docs/reference/access-authn-authz/node/). + * **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](/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](/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](/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. + * **RBAC** - Role-based access control (RBAC), ou controle de acesso baseado em função, é um método de regular o acesso a recursos computacionais ou de 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](/docs/reference/access-authn-authz/rbac/) + * Quando especificado RBAC (Role-Based Access Control) usa o grupo 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](/docs/reference/access-authn-authz/webhook/). + * **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 um determinado evento ocorrer. Para saber mais sobre como usar o modo Webhook, consulte [Webhook Mode](/docs/reference/access-authn-authz/webhook/). #### Verificando acesso a API @@ -121,7 +119,7 @@ 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) +Os administradores podem combinar isso com [personificação de usuário](/pt-br/docs/reference/access-authn-authz/authentication/#personificação-de-usuário) para determinar qual ação outros usuários podem executar. ```bash @@ -153,14 +151,14 @@ 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: +expõe a autorização do servidor de API para serviços externos. Outros recursos +neste 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. +* `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. +* `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 mostrarem ações. Essas APIs podem ser consultadas criando recursos normais do Kubernetes, onde a resposta `status` campo do objeto retornado é o resultado da consulta. @@ -203,7 +201,7 @@ 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=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 do 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. @@ -215,7 +213,7 @@ em ordem, então, um modulo anterior tem maior prioridade para permitir ou negar ## 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. +como, por exemplo, um operador, e conseguiriam escalar seus próprios privilégios naquele namespace. {{< caution >}} Administradores de sistemas, tenham cuidado ao permitir acesso para criar ou editar cargas de trabalho. From 9957f6c7caf83fd29f41d6bb6fa0304b9b68e042 Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Fri, 23 Sep 2022 17:04:11 +0200 Subject: [PATCH 05/10] missed caution admonition fix --- .../pt-br/docs/reference/access-authn-authz/authorization.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index 31fbc55c95073..65ccf289e1e4f 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -70,6 +70,10 @@ PUT | update PATCH | patch DELETE | delete (para recursos individuais), deletecollection (para coleções) +{{< caution >}} +Os verbos `get`, `list` e `watch` podem retornar todos os detalhes de um recurso. Eles são equivalentes em relação aos dados retornados. Por exemplo, `list` em `secrets` revelará os atributos de `data` de qualquer recurso retornado. +{{< /caution >}} + Às vezes, o Kubernetes verifica a autorização para permissões adicionais utilizando verbos especializados. Por exemplo: * [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) From 7e8f1fcbd87ca2fc853a13de6b9825be1126810f Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Mon, 24 Oct 2022 16:12:24 +0200 Subject: [PATCH 06/10] still some accents --- .../pt-br/docs/reference/access-authn-authz/authorization.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index 65ccf289e1e4f..039f055412f5d 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -6,7 +6,7 @@ weight: 60 Aprenda mais sobre autorização no Kubernetes, incluindo detalhes sobre -criação de politicas utilizando módulos de autorização suportados. +criação de políticas utilizando módulos de autorização suportados. @@ -209,7 +209,7 @@ As seguintes flags podem ser utilizadas: * `--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. + * `--authorization-mode=AlwaysAllow` Esta flag permite todas as requisições. Utilize esta flag somente se não 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. From 64cda2e66a15bbff177165161e43c32e269a7a80 Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Tue, 25 Oct 2022 09:43:21 +0200 Subject: [PATCH 07/10] group API core order fix --- .../pt-br/docs/reference/access-authn-authz/authorization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index 039f055412f5d..5f51012a77189 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -48,7 +48,7 @@ O Kubernetes revisa somente os seguintes atributos de uma requisição de API: * **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](/docs/reference/using-api/#api-groups). + * **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 [Grupo de API](/docs/reference/using-api/#api-groups) _core_. ## Determine o verbo da requisição {#determine-the-request-verb} From b53e77805e99426196b8ed3724c0ea2fa0d4421e Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Tue, 25 Oct 2022 09:55:15 +0200 Subject: [PATCH 08/10] GET/HEAD request verb fix --- .../pt-br/docs/reference/access-authn-authz/authorization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index 5f51012a77189..5ead89c8e7907 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -65,7 +65,7 @@ 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) +GET, HEAD | get (para recursos individuais), list (para coleções, includindo o conteúdo do objeto inteiro), watch (para observar um recurso individual ou coleção de recursos) PUT | update PATCH | patch DELETE | delete (para recursos individuais), deletecollection (para coleções) From 0b9c077c05d30de97bd0ab7d224bc1ebdc41667b Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Tue, 15 Nov 2022 20:27:47 +0100 Subject: [PATCH 09/10] fix latest reviewed items --- .../access-authn-authz/authorization.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index 5ead89c8e7907..e0de1403a8085 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -77,17 +77,17 @@ Os verbos `get`, `list` e `watch` podem retornar todos os detalhes de um recurso À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. + * Verbo `use` 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. + * Verbos `bind` e `escalate` 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 `core`, e o `userextras` no grupo `authentication.k8s.io` de API. + * Verbo `impersonate` em `users`, `groups`, e `serviceaccounts` no grupo de API `core`, 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](/docs/reference/access-authn-authz/node/). + * **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](/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](/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 computacionais ou de 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](/docs/reference/access-authn-authz/rbac/) * Quando especificado RBAC (Role-Based Access Control) usa o grupo 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. @@ -164,8 +164,8 @@ neste grupo inclui: * `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 mostrarem ações. -Essas APIs podem ser consultadas criando recursos normais do Kubernetes, onde a resposta `status` -campo do objeto retornado é o resultado da consulta. +Essas APIs podem ser consultadas criando recursos normais do Kubernetes, onde a resposta no campo `status` +do objeto retornado é o resultado da consulta. ```bash kubectl create -f - -o yaml << EOF @@ -204,8 +204,8 @@ 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 do Kubernetes. + * `--authorization-mode=ABAC` O modo de controle de acesso baseado em atributos (ABAC) permite configurar políticas usando arquivos locais. + * `--authorization-mode=RBAC` O modo de controle de acesso baseado em função (RBAC) permite que você crie e armazene políticas usando a API do 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. @@ -217,7 +217,7 @@ em ordem, então, um modulo anterior tem maior prioridade para permitir ou negar ## 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 conseguiriam escalar seus próprios privilégios naquele namespace. +como, por exemplo, um operador, conseguiriam escalar seus próprios privilégios naquele namespace. {{< caution >}} Administradores de sistemas, tenham cuidado ao permitir acesso para criar ou editar cargas de trabalho. @@ -227,15 +227,15 @@ Detalhes de como estas permissões podem ser usadas de forma maliciosa podem ser ### Caminhos para escalonamento {#escalation-paths} -- Montar Secret arbitrários nesse namespace +- Montagem de Secret arbitrários nesse namespace - Pode ser utilizado para acessar Secret destinados a outras cargas de trabalho - Pode ser utilizado para obter um token da conta de serviço com maior privilégio -- Usando contas de serviço arbitrárias nesse namespace +- Uso de 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 acesso - 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 +- Montagem de 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 >}} From ddfbaad0c6d835b60dde420b52bd5bd9997daf76 Mon Sep 17 00:00:00 2001 From: Jose Almaraz Date: Tue, 15 Nov 2022 22:27:41 +0100 Subject: [PATCH 10/10] missing kubelet and pods format --- .../docs/reference/access-authn-authz/authorization.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/pt-br/docs/reference/access-authn-authz/authorization.md b/content/pt-br/docs/reference/access-authn-authz/authorization.md index e0de1403a8085..efba8eb731188 100644 --- a/content/pt-br/docs/reference/access-authn-authz/authorization.md +++ b/content/pt-br/docs/reference/access-authn-authz/authorization.md @@ -139,7 +139,7 @@ no ``` Da mesma forma, para verificar se uma ServiceAccount chamada `dev-sa` no Namespace `dev` -pode listar Pods no namespace `target`: +pode listar ```Pods``` no namespace `target`: ```bash # "can-i list" = "posso listar" @@ -158,7 +158,7 @@ yes expõe a autorização do servidor de API para serviços externos. Outros recursos neste grupo inclui: -* `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. +* `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. @@ -207,7 +207,7 @@ As seguintes flags podem ser utilizadas: * `--authorization-mode=ABAC` O modo de controle de acesso baseado em atributos (ABAC) permite configurar políticas usando arquivos locais. * `--authorization-mode=RBAC` O modo de controle de acesso baseado em função (RBAC) permite que você crie e armazene políticas usando a API do 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=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 não existam requisitos de autorização para as requisições de API. @@ -216,7 +216,7 @@ em ordem, então, um modulo anterior tem maior prioridade para permitir ou negar ## 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/) +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, conseguiriam escalar seus próprios privilégios naquele namespace. {{< caution >}}