Usar o Controle de Acesso Baseado em Atribuição com o Oracle Cloud Native Environment

Introdução

À medida que o número de implantações no cluster do Kubernetes aumenta, talvez você precise de ajuda para gerenciá-lo. A API do Kubernetes permite adicionar usuários e definir suas permissões ao cluster.

Depois que o usuário é autenticado, o Kubernetes verifica quais ações o usuário está autorizado a executar. O RBAC (Role-Based Access Control, Controle de acesso baseado em função) é suportado nativamente pelo Kubernetes e ativado por padrão no Oracle Cloud Native Environment (Oracle CNE). Torná-lo um dos métodos de controle de acesso comumente usados. O RBAC permite que você gerencie o acesso a recursos implantados no ambiente do Kubernetes aplicando regras que restringem o acesso dos usuários aos recursos do cluster. Essas regras podem ser restritas a namespace usando uma Atribuição ou em todo o cluster usando um ClusterRole.

Você achará útil ter uma compreensão dos principais componentes do RBAC (Role-Based Access Control) no Kubernetes, que são:

Atribuições: Um conjunto definido de permissões que definem ações permitidas em um namespace.
RoleBindings: Usado para vincular uma Atribuição a um usuário ou conta de serviço dentro de um namespace.
ClusterRole: Um conjunto definido de permissões que definem ações permitidas em todos os namespaces do cluster.
ClusterRoleBindings: Usado para vincular um ClusterRole a contas de usuário ou serviço em todos os namespaces do cluster.
Assuntos: São usuários, grupos ou contas de serviço vinculados a Atribuições ou ClusterRoles.
Permissões: definem as ações permitidas que uma Função, ou ClusterRole, pode executar em um recurso especificado. Eles são associados a atribuições e atribuições de cluster em vez de usuários ou contas de serviço.

Outra maneira de gerenciar o acesso ao cluster do Kubernetes é o ABAC (Attribute-Based Access Control, Controle de acesso baseado em atributo), que permite um ajuste mais fino das políticas em comparação com o RBAC. Mas isso está fora do escopo deste tutorial.

Este tutorial aborda os conceitos básicos de uso do RBAC para gerenciar o acesso ao seu cluster do Kubernetes e demonstra um caso de uso simples.

Para obter mais informações sobre o Oracle Cloud Native Environment 2, consulte o site atual da Documentação de Versão.

Objetivos

Neste tutorial, você aprenderá a:

Crie uma Atribuição para demonstrar a restrição de permissões de usuário por namespace.
Crie um ClusterRole para demonstrar a concessão de permissões de usuário em todo o cluster.

Pré-requisitos

Instalação do Oracle Cloud Native Environment (Oracle CNE)
Um único nó de controle e um nó de trabalho

Configurar o Oracle Cloud Native Environment

Observação: Se estiver em execução na sua própria tenancy, leia o projeto linux-virt-labs GitHub README.md e conclua os pré-requisitos antes de implantar o ambiente de laboratório.

Abra um terminal no Luna Desktop.

Clone o projeto linux-virt-labs GitHub.

git clone https://github.com/oracle-devrel/linux-virt-labs.git

Altere para o diretório de trabalho.
```
cd linux-virt-labs/ocne2
```

Instale as coleções necessárias.

ansible-galaxy collection install -r requirements.yml

Implante o ambiente de laboratório.
```
ansible-playbook create_instance.yml -e localhost_python_interpreter="/usr/bin/python3.6" -e install_ocne_rpm=true -e create_ocne_cluster=true -e "ocne_cluster_node_options='-n 1 -w 1'"
```
O ambiente de laboratório gratuito requer a variável extra local_python_interpreter, que define ansible_python_interpreter para reproduções em execução no localhost. Essa variável é necessária porque o ambiente instala o pacote RPM do Oracle Cloud Infrastructure SDK para Python, localizado nos módulos python3.6.

A forma de implantação padrão usa a CPU AMD e o Oracle Linux 8. Para usar uma CPU Intel ou um Oracle Linux 9, adicione -e instance_shape="VM.Standard3.Flex" ou -e os_version="9" ao comando de implantação.

Importante: Aguarde a execução bem-sucedida do playbook e atinja a tarefa de pausa. Neste estágio do playbook, a instalação do Oracle CNE está concluída e as instâncias estão prontas. Anote o jogo anterior, que imprime os endereços IP públicos e privados dos nós que ele implanta e quaisquer outras informações de implantação necessárias durante a execução do laboratório.

Acessar o Cluster do Kubernetes

Abra um terminal e conecte-se via SSH à instância do ocne.
```
ssh oracle@<ip_address_of_instance>
```
Aguarde a estabilização do cluster e todos os pods reportem em um estado de execução.
```
watch kubectl get pods -A
```
Depois que todos os pods mostrarem um STATUS de Em Execução, digite Ctrl-C para sair do comando watch.
Confirme quantos nós estão presentes.
```
kubectl get nodes
```

Confirmar a configuração atual do RBAC

O RBAC gerencia as permissões das ações que você executa em recursos implantados no cluster do Kubernetes. Você verificará se o RBAC está ativado e verificará as atribuições padrão no seu cluster.

Confirme se o RBAC está ativado.

Se a API rbac.authorization.k8s.io estiver visível, isso significa que o RBAC está configurado e é usado para controlar quais ações os usuários ou as contas de serviço podem executar nos recursos do cluster.
```
kubectl api-versions | grep rbac
```
Exemplo de Saída:
```
[oracle@ocne ~]$ kubectl api-versions | grep rbac
rbac.authorization.k8s.io/v1
```

Mostrar as atribuições de cluster incorporadas.

kubectl get clusterroles | grep admin

Exemplo de Saída:

[oracle@ocne ~]$ kubectl get clusterroles | grep admin
admin                                                                  2025-07-23T10:21:55Z
cluster-admin                                                          2025-07-23T10:21:55Z
system:aggregate-to-admin                                              2025-07-23T10:21:55Z
system:kubelet-api-admin                                               2025-07-23T10:21:55Z

Os usuários normais usam as funções admin e cluster-admin, enquanto a API RBAC reserva as funções system: para componentes internos.

Liste as permissões para cluster-admin.
```
kubectl describe clusterrole cluster-admin
```
Exemplo de Saída:
```
[oracle@ocne ~]$ kubectl describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]
```
Os asteriscos nas colunas Verbos e Recursos significam que a atribuição cluster-admin pode executar qualquer ação. Uma lista de alto nível das operações (Verbos) disponíveis para cada release do Kubernetes está disponível na Visão Geral da API dessa release. Por exemplo, no Kubernetes v1.33.0. Uma lista detalhada de operações válidas (Verbos) disponíveis para cada tipo de Recurso está disponível por meio da execução de kubectl api-resources -o wide na linha de comando.

No entanto, como você não faz log-in no kubectl, como o Kubernetes sabe quem é o usuário que está executando o comando? Em geral, os sistemas de produção usam um servidor LDAP para autenticação. Um ServiceAccount poderá ser usado se um sistema de autenticação externo não estiver disponível.

Observação: ServiceAccounts são usados por cargas de trabalho automatizadas, como pipelines de CI/CD, mas também podem ser usados para teste.

Criar uma Função

Uma Atribuição é um recurso restrito a namespace que define as permissões para acessar recursos do Kubernetes em um único namespace.

Criar um Namespace e uma Atribuição

Criar um Namespace.

Crie um novo namespace para este exemplo.
```
kubectl create namespace rbac-example
```
Criar uma Função.

Crie uma Atribuição que conceda acesso somente leitura (permissões ('get' e 'list') a pods e implantações no namespace rbac-example.
```
cat << EOF | tee pod-reader-role.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: rbac-example
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
EOF
```
Onde:
- rules: - Define as permissões concedidas à Atribuição. Este exemplo define duas regras (veja abaixo).
- apiGroups: [""] - Permite que a conta de usuário ou serviço vinculada a essa regra recupere e liste pods no namespace rbac-example.
- apiGroups: ["apps"] - Permite que o usuário ou a conta de serviço vinculada a essa regra recupere e liste implantações no namespace rbac-example.
Aplique o arquivo.
```
kubectl apply -f pod-reader-role.yaml
```

Verifique as permissões para a função pod-reader recém-criada.

kubectl describe role/pod-reader -n rbac-example

Exemplo de Saída:

[oracle@ocne ~]$ kubectl describe role/pod-reader -n rbac-example
Name:         pod-reader
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
 pods              []                 []              [get list]
 deployments.apps  []                 []              [get list]

Criar um Usuário e Vincular à Função

Crie um novo usuário ServiceAccount chamado pod-reader-user e vincule-o à atribuição pod-reader.
```
cat << EOF | tee pod-reader-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: rbac-example
roleRef:
  name: pod-reader
  kind: Role
subjects:
- kind: ServiceAccount
  name: pod-reader-user
  namespace: rbac-example
EOF
```
Onde:
- O ServiceAccount cria a conta de serviço.
  - name: - O nome do usuário da conta de serviço (pod-reader-user).
  - namespace - O namespace no qual ele é criado (rbac-example).
- O RoleBinding concede as permissões relacionadas ao namespace à conta de serviço.
  - roleRef: - Especifica a Atribuição de associação. Neste exemplo, ele faz referência a uma Atribuição chamada pod-reader.
  - subjects: - Especifica a entidade para conceder permissões. Neste exemplo, uma conta de serviço chamada pod-reader-user.
Aplique o arquivo.
```
kubectl apply -f pod-reader-user.yaml
```

Teste o RoleBinding

Em seguida, teste o RoleBinding criando um novo Pod e acessando-o usando a conta de serviço pod-reader-user recém-criada.

Criar uma nova implantação de teste.
```
cat << EOF | tee testpod.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: rbac-example
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 80
  serviceAccountName: pod-reader-user
EOF
```
Onde:
- O spec: define o estado desejado do pod.
  - containers: - Especifica a lista de contêineres a serem executados no pod. Neste exemplo, há apenas um contêiner.
    - name: - O nome do contêiner (test-container).
    - image: - A imagem a ser usada (ghcr.io/oracle/oraclelinux9-nginx:1.20).
    - ports: - Especifica a porta exposta pelo contêiner. Neste exemplo, é a porta 80 (containerPort: 80).
  - serviceAccountName: - Especifica a conta de serviço a ser usada para o Pod. Nessa configuração, o Pod usa as permissões e as credenciais designadas à conta de serviço pod-reader-user.
Aplique o arquivo.
```
kubectl apply -f testpod.yaml
```
Agora, tente acessar o Pod usando o pod-reader-user ServiceAccount.
```
kubectl auth can-i get pod/test-pod --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
```
Você deverá ver yes como a saída, indicando que o pod-reader-user tem permissão para acessar o pod.

Observação: use a funcionalidade kubectl auth can-i para executar comandos como a conta de usuário ServiceAccount recém-criada para verificar se uma ação é permitida.

Confirme se o ServiceAccount funciona conforme esperado.

kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example

Exemplo de Saída:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          109s

Tente excluir um Pod usando a atribuição pod-reader-user.

kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example

Exemplo de Saída:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example
Error from server (Forbidden): pods "test-pod" is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot delete resource "pods" in API group "" in the namespace "rbac-example"

A atribuição pod-reader-user não pode excluir pods no rbac-example. Talvez eles possam começar novos pods?

Tente executar um Pod usando a atribuição pod-reader-role.

kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:default:my-serviceaccount -n rbac-example

Exemplo de Saída:

[oracle@ocne ~]$ kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot create resource "pods" in API group "" in the namespace "rbac-example"

Este erro está correto porque a atribuição pod-reader-user só tem permissão para executar ações get e list em recursos do Pod no namespace rbac-example do cluster. Quaisquer outras ações, excluir ou criar, não são permitidas.

Criar um ClusterRole

ClusterRoles são semelhantes às Atribuições, mas definem permissões permitidas em recursos em todo o cluster.

Observação: tenha cuidado ao conceder permissões muito amplas. Em vez disso, use o 'princípio do privilégio mínimo' mínimo para conceder aos usuários e às contas de serviço somente as permissões necessárias para concluir suas tarefas designadas.

Criar um ClusterRole e um ClusterRoleBinding

O exemplo anterior mostrou como criar um usuário e uma função específicos do namespace. As etapas a seguir demonstram como criar um ClusterRole e vinculá-lo a um usuário para conceder a ele acesso de administrador em todo o cluster.

Crie uma nova ClusterRole.

Este ClusterRole permite que os usuários adicionados a ele conduzam qualquer ação em todos os recursos do cluster.
```
cat << EOF | tee cluster-admin-clusterrole.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-cr
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF
```
Onde:
- rules: - Define as permissões concedidas ao ClusterRole. Este exemplo tem apenas uma regra:
  - apiGroups: ["*"] - Especifica que a regra se aplica a todos os grupos de APIs.
  - resources: ["*"] - Especifica que a regra se aplica a todos os recursos dos grupos de APIs.
  - verbs: ["*"] - Especifica que a regra concede todos os verbos possíveis nos recursos, incluindo get, list, create, delete etc.

Aplique o arquivo.

kubectl apply -f cluster-admin-clusterrole.yaml

Crie um ClusterRoleBinding para vincular o ClusterRole a um novo usuário.

O ClusterRoleBinding é semelhante ao RoleBinding criado anteriormente, mas tem um escopo de cluster.

cat << EOF | tee cluster-admin-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cluster-admin-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-crb
roleRef:
  name: cluster-admin-cr
  kind: ClusterRole
subjects:
- kind: ServiceAccount
  name: cluster-admin-user
  namespace: rbac-example
EOF

Onde:

subjects: - Define as entidades para conceder permissões no ClusterRole. Neste exemplo, é a conta de serviço cluster-admin-user.

Aplique o arquivo.

kubectl apply -f cluster-admin-user.yaml

Teste o ClusterRoleBinding

Teste a atribuição de cluster tentando acessar um recurso em outro namespace. Por exemplo, o namespace padrão.
```
kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n default
```
Você deverá ver yes como saída, indicando que o cluster-admin-user tem acesso de administrador de cluster.

Confirme se o ClusterRole recém-criado funciona conforme esperado.

kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

Exemplo de Saída:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
kube-flannel   kube-flannel-ds-ptwkz                          1/1     Running   0          6h58m
kube-flannel   kube-flannel-ds-wn2g6                          1/1     Running   0          6h58m
kube-system    coredns-7cbdbfd99c-7xqkl                       1/1     Running   0          6h59m
kube-system    coredns-7cbdbfd99c-k2ssb                       1/1     Running   0          6h59m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          6h59m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          6h59m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          6h59m
kube-system    kube-proxy-48rm5                               1/1     Running   0          6h59m
kube-system    kube-proxy-h4kd2                               1/1     Running   0          6h58m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          6h59m
ocne-system    ocne-catalog-577b7cd5f9-bnvtm                  1/1     Running   0          6h58m
ocne-system    ui-846bddd4b-lnrwm                             1/1     Running   0          6h58m
rbac-example   test-pod                                       1/1     Running   0          6h34m

Essa saída confirma que o ClusterRole recém-criado pode acessar todos os namespaces definidos no cluster.

Confirme se o Usuário do ClusterRole pode Criar uma Nova Implantação

Teste o ClusterRole para ver se ele permite que os usuários designados criem uma nova implantação. Em seguida, tente acessá-lo usando o ClusterRole recém-criado.

Criar uma nova implantação de teste.

cat << EOF | tee testpod2.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod2
  namespace: default
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 8080
EOF

Observe que essa implantação é implantada no namespace 'default' e não no namespace rbac-example usado anteriormente.

Aplique o arquivo.
```
kubectl apply -f testpod2.yaml
```

Confirme se a implantação foi concluída com sucesso.

kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

Exemplo de Saída:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
default        test-pod2                                      1/1     Running   0          28s
kube-flannel   kube-flannel-ds-shgh7                          1/1     Running   0          38m
kube-flannel   kube-flannel-ds-zzrgh                          1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-jg6lz                       1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-wh5g4                       1/1     Running   0          38m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          38m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          38m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          38m
kube-system    kube-proxy-5qngx                               1/1     Running   0          38m
kube-system    kube-proxy-6fz2q                               1/1     Running   0          38m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          38m
ocne-system    ocne-catalog-577b7cd5f9-vz782                  1/1     Running   0          38m
ocne-system    ui-846bddd4b-bbhtj                             1/1     Running   0          38m
rbac-example   test-pod                                       1/1     Running   0          21m

Confirmando se o novo ClusterRole permite novas implantações em outro namespace.

Próximas Etapas

Este tutorial demonstrou como configurar e usar o RBAC (Role-Based Access Control) com o Kubernetes criando Atribuições para gerenciar o acesso aos recursos do Kubernetes. Você conseguiu isso definindo atribuições e bindings para controlar quais ações permitidas foram permitidas em recursos dentro de um namespace ou em uma base de cluster. Dessa forma, o controle granular que o RBAC fornece é essencial para proteger seu ambiente Kubernetes, especialmente para grandes implementações. Confira o Oracle Linux Training Station para obter tutoriais e conteúdo adicionais.

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal do Oracle Learning YouTube. Além disso, acesse education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

Título e Informações de Copyright

Use Role-Based Access Control with Oracle Cloud Native Environment

G40840-01

Oracle e/ou suas empresas afiliadas.

Usar o Controle de Acesso Baseado em Atribuição com o Oracle Cloud Native Environment

Introdução

Objetivos

Pré-requisitos

Configurar o Oracle Cloud Native Environment

Acessar o Cluster do Kubernetes

Confirmar a configuração atual do RBAC

Criar uma Função

Criar um Namespace e uma Atribuição

Criar um Usuário e Vincular à Função

Teste o RoleBinding

Criar um ClusterRole

Criar um ClusterRole e um ClusterRoleBinding

Teste o ClusterRoleBinding

Confirme se o Usuário do ClusterRole pode Criar uma Nova Implantação

Próximas Etapas

Links Relacionados

Mais Recursos de Aprendizagem