Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Protezione dell'accesso alle risorse con IAM

Gli utenti e i service account Kubernetes devono disporre delle autorizzazioni per gestire le risorse di Config Connector. Con Config Connector, il control plane del tuo progetto può essere gestito da identità che utilizzano il controllo degli accessi basato su ruoli (RBAC) di Kubernetes. Puoi anche fare riferimento alle policy di Identity and Access Management (IAM).

Le risorse che possono fare riferimento a IAMPolicy e IAMPolicyMember sono elencate nel Riferimento risorsa. Queste risorse hanno la proprietà "Può essere referenziata da IAMPolicy/IAMPolicyMember".

Questo argomento spiega come proteggere l'accesso alle risorse Google Cloud utilizzando Identity and Access Management.

Prima di iniziare

Installa Config Connector sul tuo cluster.

Protezione dell'accesso al control plane con RBAC

In questo esempio, creerai un account di servizio e gli concederai le autorizzazioni per gestire un PubSubTopic. Questo account di servizio non può gestire altri tipi di risorse Config Connector.

Crea un file denominato pubsub-topic-service-account.yaml con i seguenti contenuti:
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pubsub-topic-service-account
  namespace: default
```
Applica questo criterio per creare il account di servizio pubsub-topic-service-account:
```
kubectl apply -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE
```
Sostituisci CC_NAMESPACE con lo spazio dei nomi da cui Config Connector gestisce le risorse.
Verifica che pubsub-topic-service-account non possa creare risorse PubSubTopic controllando che l'output del seguente comando contenga no:
```
kubectl auth can-i get pubsubtopics --as=system:serviceaccount:default:pubsub-topic-service-account
```
Successivamente, crea un ClusterRole che consenta la creazione di argomenti Pub/Sub.

Il ClusterRole può gestire solo le risorse con valori specificati in rules.apiGroups e rules.resources. Per trovare i valori di apiGroups e resources, consulta il riferimento per le tue risorse.

Crea un file denominato pubsub-topic-editor-role.yaml con i seguenti contenuti:
```
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
```
Applica pubsub-topic-editor.yaml per creare ClusterRole:
```
kubectl apply -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
```
Sostituisci CC_NAMESPACE con lo spazio dei nomi da cui Config Connector gestisce le risorse.

Successivamente, crea un RoleBinding tra il ClusterRole e il tuo account di servizio. Crea un file denominato pubsub-topic-editor-rolebinding.yaml con i seguenti contenuti:

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

Applica pubsub-topic-editor-rolebinding.yaml al tuo cluster.
```
kubectl apply -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
```
Sostituisci CC_NAMESPACE con lo spazio dei nomi da cui Config Connector gestisce le risorse.
Verifica che pubsub-topic-service-account sia autorizzato a creare risorse PubSubTopic confermando che l'output del seguente comando sia yes:
```
kubectl auth can-i get pubsubtopics \
  --as=system:serviceaccount:default:pubsub-topic-service-account
```

Pulizia

Utilizza kubectl delete per rimuovere il service account, il ruolo IAM e l'associazione dei ruoli.

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

Sostituisci CC_NAMESPACE con lo spazio dei nomi da cui Config Connector gestisce le risorse.

Protezione del piano dati con le policy IAM

In questo esempio, utilizzi le autorizzazioni concesse in precedenza per creare un PubSubTopic e limitare l'accesso con una risorsa IAMPolicyMember.

Crea un file denominato pubsub-topic-sample.yaml con i seguenti contenuti:
```
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: pubsubtopic-sample
```
Applica pubsub-topic-sample.yaml con kubectl:
```
kubectl apply -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE
```
Sostituisci CC_NAMESPACE con lo spazio dei nomi da cui Config Connector gestisce le risorse.

Crea un file denominato iampolicymember.yaml con i seguenti contenuti, sostituendo EMAIL_ADDRESS con l'indirizzo email del tuo account 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"

Applica iampolicymember.yaml.
```
kubectl apply -f iampolicymember.yaml  --namespace CC_NAMESPACE 
```
Sostituisci CC_NAMESPACE con lo spazio dei nomi da cui Config Connector gestisce le risorse.
Verifica che la policy sia stata applicata a Google Cloud eseguendo questo comando e cercando il tuo indirizzo email nell'output, sostituendo PROJECT_ID con il tuo ID progetto:
```
gcloud beta pubsub topics get-iam-policy projects/PROJECT_ID/topics/pubsubtopic-sample
```

L'accesso ai tuoi argomenti Pub/Sub è ora protetto con un IAMPolicyMember.

Pulizia

Utilizza kubectl delete per rimuovere l'argomento Pub/Sub e IAMPolicyMember dal progetto Google Cloud .

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

Best practice per la sicurezza per l'isolamento multi-tenant

Per evitare l'escalation dei privilegi non autorizzata e applicare l'isolamento dei tenant, segui queste best practice:

Applica la modalità con spazio dei nomi: evita la modalità cluster in ambienti multi-tenant. In modalità cluster, tutti i namespace condividono un unico account di servizio IAM. Qualsiasi utente che può creare risorse Config Connector in qualsiasi spazio dei nomi può agire con le autorizzazioni IAM complete di quel account di servizio.
Limita RBAC per le risorse IAM: limita le autorizzazioni di creazione e modifica per le risorse IAMPolicy, IAMPartialPolicy e IAMPolicyMember utilizzando controllo dell'accesso basato su ruoli (RBAC) di Kubernetes. Se gli sviluppatori hanno un ampio accesso in scrittura a queste risorse, possono modificare le associazioni IAM di Google Cloud .
Definisci l'ambito delle associazioni IAM per Workload Identity Federation for GKE: configura queste associazioni rigorosamente per i ServiceAccount Kubernetes designati in spazi dei nomi specifici. In modalità con spazi dei nomi, associa ogni account di servizio IAM solo al ServiceAccount Kubernetes di Config Connector per il relativo spazio dei nomi:
```
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"
```
Sostituisci quanto segue:
- GSA_NAME: il nome del account di servizio IAM utilizzato da Config Connector per lo spazio dei nomi.
- PROJECT_ID: l'ID del progetto che contiene il tuo cluster e il account di servizio IAM.
- CC_NAMESPACE: lo spazio dei nomi da cui Config Connector gestisce le risorse.
Non concedere il ruolo roles/iam.workloadIdentityUser a un set di entità, ad esempio tutti i pod nello spazio dei nomi cnrm-system. In modalità con spazio dei nomi, i controller Config Connector per tutti gli spazi dei nomi vengono eseguiti in cnrm-system, quindi questo tipo di associazione consente al controller di ogni spazio dei nomi di impersonare il account di servizio IAM.

Passaggi successivi

Utilizza i secret per trasmettere informazioni in modo sicuro alle risorse Google Cloud .