O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Como proteger o acesso a recursos com o IAM

Os usuários e as contas de serviço do Kubernetes precisam de permissões para gerenciar os recursos do Config Connector. Com o Config Connector, o plano de controle do projeto pode ser gerenciado por identidades que usam o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes. Também é possível se referir às políticas de gerenciamento de identidade e acesso (IAM, na sigla em inglês).

Os recursos que podem referenciar IAMPolicy e IAMPolicyMember estão listados na Referência de recursos. Esses recursos têm a propriedade "Pode ser referenciado pelo IAMPolicy/IAMPolicyMember".

Neste tópico, explicamos como proteger o acesso aos recursos do Google Cloud usando o Identity and Access Management.

Antes de começar

Instale o Config Connector no cluster.

Como proteger o acesso do plano de controle com o RBAC

Neste exemplo, você criará uma conta de serviço e concederá permissões para gerenciar um PubSubTopic. Essa conta de serviço não pode gerenciar outros tipos de recursos do Config Connector.

Crie um arquivo chamado pubsub-topic-service-account.yaml com o conteúdo a seguir:
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pubsub-topic-service-account
  namespace: default
```
Aplique isso para criar a conta de serviço pubsub-topic-service-account:
```
kubectl apply -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE
```
Substitua CC_NAMESPACE pelo namespace em que o Config Connector gerencia recursos.
Confirme que pubsub-topic-service-account não pode criar recursos PubSubTopic verificando se o resultado do comando a seguir contém no:
```
kubectl auth can-i get pubsubtopics --as=system:serviceaccount:default:pubsub-topic-service-account
```
Em seguida, crie um ClusterRole que permita a criação do tópico Pub/Sub.

O ClusterRole só pode gerenciar recursos que têm valores especificados em rules.apiGroups e rules.resources. Para encontrar valores para apiGroups e resources, consulte a referência dos recursos.

Crie um arquivo chamado pubsub-topic-editor-role.yaml com o seguinte conteúdo:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: pubsub-topic-editor
rules:
- apiGroups:
  - pubsub.cnrm.cloud.google.com
  resources:
  - pubsubtopics
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
```
Aplique pubsub-topic-editor.yaml para criar o ClusterRole:
```
kubectl apply -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
```
Substitua CC_NAMESPACE pelo namespace em que o Config Connector gerencia recursos.

Em seguida, crie um RoleBinding entre o ClusterRole e sua conta de serviço. Crie um arquivo chamado pubsub-topic-editor-rolebinding.yaml com o conteúdo a seguir:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pubsub-topic-editor-rolebinding.
subjects:
- kind: ServiceAccount
  name: pubsub-topic-service-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pubsub-topic-editor

Aplique pubsub-topic-editor-rolebinding.yaml ao cluster.
```
kubectl apply -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
```
Substitua CC_NAMESPACE pelo namespace em que o Config Connector gerencia recursos.
Confirme se pubsub-topic-service-account tem permissão para criar recursos PubSubTopic confirmando que o resultado do comando a seguir é yes:
```
kubectl auth can-i get pubsubtopics \
  --as=system:serviceaccount:default:pubsub-topic-service-account
```

Como fazer a limpeza

Use kubectl delete para remover a Conta de serviço, o Papel do Cloud IAM e a Vinculação do papel.

kubectl delete -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

Substitua CC_NAMESPACE pelo namespace em que o Config Connector gerencia recursos.

Como proteger o plano de dados com políticas do IAM

Neste exemplo, você usa as permissões concedidas anteriormente para criar um PubSubTopic e limitar o acesso a ele com um recurso IAMPolicyMember.

Crie um arquivo chamado pubsub-topic-sample.yaml com o conteúdo a seguir:
```
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: pubsubtopic-sample
```
Aplique pubsub-topic-sample.yaml com kubectl:
```
kubectl apply -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE
```
Substitua CC_NAMESPACE pelo namespace em que o Config Connector gerencia recursos.

Crie um arquivo chamado iampolicymember.yaml com o conteúdo a seguir, substituindo EMAIL_ADDRESS pelo endereço de e-mail da sua conta do Google Cloud :

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: iampolicymember-sample
spec:
  resourceRef:
    apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
    kind: PubSubTopic
    name: pubsubtopic-sample
  role: roles/pubsub.admin
  member: "user:EMAIL_ADDRESS"

Aplique iampolicymember.yaml.
```
kubectl apply -f iampolicymember.yaml  --namespace CC_NAMESPACE 
```
Substitua CC_NAMESPACE pelo namespace em que o Config Connector gerencia recursos.
Confirme se a política foi aplicada a Google Cloud executando este comando e procurando seu endereço de e-mail na saída, substituindo PROJECT_ID pelo ID do projeto:
```
gcloud beta pubsub topics get-iam-policy projects/PROJECT_ID/topics/pubsubtopic-sample
```

O acesso aos temas do seu Pub/Sub agora está protegido com um IAMPolicyMember.

Limpar

Use kubectl delete para remover o tópico do Pub/Sub e o IAMPolicyMember do projeto do Google Cloud .

kubectl delete -f iampolicymember.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

Práticas recomendadas de segurança para isolamento multilocatário

Para ajudar a evitar o escalonamento de privilégios não autorizado e aplicar o isolamento de locatários, siga estas práticas recomendadas:

Aplicar o modo de namespace: evite o modo de cluster em ambientes multilocatários. No modo de cluster, todos os namespaces compartilham uma única conta de serviço do IAM. Qualquer usuário que possa criar recursos do Config Connector em qualquer namespace pode agir com as permissões completas do IAM dessa conta de serviço.
Restringir o RBAC para recursos do IAM: limite as permissões de criação e modificação para recursos IAMPolicy, IAMPartialPolicy e IAMPolicyMember usando o controle de acesso baseado em papéis (RBAC) do Kubernetes. Se os desenvolvedores tiverem acesso amplo de gravação a esses recursos, eles poderão alterar as vinculações do IAM do Google Cloud .
Defina o escopo das vinculações do IAM para a federação de identidade da carga de trabalho para GKE: configure essas vinculações estritamente para as ServiceAccounts do Kubernetes designadas em namespaces específicos. No modo com namespace, vincule cada conta de serviço do IAM apenas à conta de serviço do Kubernetes do Config Connector para o namespace dela:
```
gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member="serviceAccount:PROJECT_ID.svc.id.goog[cnrm-system/cnrm-controller-manager-CC_NAMESPACE]" \
    --role="roles/iam.workloadIdentityUser"
```
Substitua:
- GSA_NAME: o nome da conta de serviço do IAM que o Config Connector usa para o namespace.
- PROJECT_ID: o ID do projeto que contém o cluster e a conta de serviço do IAM.
- CC_NAMESPACE: o namespace em que o Config Connector gerencia os recursos.
Não conceda o papel roles/iam.workloadIdentityUser a um conjunto de principais, como todos os pods no namespace cnrm-system. No modo com namespace, os controladores do Config Connector para todos os namespaces são executados em cnrm-system. Portanto, esse tipo de vinculação permite que o controlador de cada namespace personifique a conta de serviço do IAM.

A seguir

Use Secrets para transmitir informações com segurança aos recursos do Google Cloud .