Questo argomento descrive come abilitare Workload Identity per i tuoi carichi di lavoro Anthos clusters on AWS (GKE on AWS) per controllare il loro accesso alle risorse AWS.
Per informazioni sull'utilizzo di Workload Identity con gli account Google Cloud Identity and Access Management (IAM) per controllare l'accesso alle risorse GCP, consulta Utilizzo di Workload Identity con Google Cloud.
Panoramica
Workload Identity utilizza le autorizzazioni AWS IAM per controllare l'accesso alle risorse cloud. Con Workload Identity, puoi assegnare ruoli IAM diversi a ciascun carico di lavoro. Questo controllo granulare delle autorizzazioni ti consente di seguire il principio del privilegio minimo. Senza Workload Identity, devi assegnare ruoli AWS IAM ai tuoi cluster Anthos sui nodi AWS, concedendo a tutti i carichi di lavoro sul nodo le stesse autorizzazioni del nodo stesso.
Per abilitare Workload Identity per il tuo cluster, completa i seguenti passaggi, raggruppati in base ai ruoli amministrativi che li eseguono.
Amministratore del cluster
- Crea un bucket Cloud Storage per archiviare i dati di rilevamento OIDC.
- Creare un ruolo Identity and Access Management da leggere dal bucket.
- Crea un cluster utente con identità del carico di lavoro abilitato.
- Crea un webhook sul tuo cluster che applichi le credenziali di Workload Identity ai pod al momento della creazione. Se non vuoi utilizzare il webhook, puoi impostare manualmente le variabili di ambiente nei pod.
- Configura il provider OIDC AWS.
- Crea ruoli e criteri IAM di AWS.
- Crea account di servizio Kubernetes e associavi i criteri AWS.
Prerequisiti
Per completare i passaggi in questo documento, devi disporre della seguente configurazione:
- Un servizio di gestione Cluster Anthos on AWS.
Cluster utente che eseguono una versione di Kubernetes successiva alla 1.17.9.
Le autorizzazioni e gli strumenti indicati di seguito.
Autorizzazioni
Per creare un cluster con Workload Identity abilitato, devi disporre delle seguenti autorizzazioni:
Google Cloud
- Creare un bucket Cloud Storage leggibile pubblicamente con accesso uniforme a livello di bucket abilitato.
- Concedi
management-sa@PROJECT_NAME.iam.gserviceaccount.com
le autorizzazioni di lettura/scrittura al bucket.
AWS
- Crea un provider AWS OIDC
- Creazione di ruoli IAM AWS
Strumenti
Sul tuo computer locale, ti consigliamo di installare lo strumento jq
.
Creazione del bucket di rilevamento OIDC
Questa sezione è dedicata agli amministratori di cluster.
Il cluster utente deve archiviare i dati di rilevamento OIDC in un bucket Cloud Storage accessibile pubblicamente. Il bucket include la configurazione di rilevamento OIDC e le chiavi pubbliche. AWS utilizza i contenuti per autenticare le richieste dai tuoi cluster utente.
Il bucket deve avere i seguenti attributi:
- Essere leggibili pubblicamente.
- Aver abilitato l'accesso uniforme a livello di bucket.
Se non hai un bucket con questi attributi, creane uno utilizzando i seguenti comandi gsutil
:
BUCKET=BUCKET_NAME
gsutil mb -b on gs://${BUCKET}
gsutil iam ch allUsers:objectViewer gs://${BUCKET}
Sostituisci BUCKET_NAME
con il nome del tuo nuovo bucket.
Concedi le autorizzazioni all'account di servizio di gestione
L'account di servizio Identity and Access Management per il servizio di gestione di Cluster Anthos on AWS ha bisogno delle autorizzazioni per leggere e scrivere oggetti in questo bucket.
Concedi le autorizzazioni all'account di servizio di gestione utilizzando il seguente comando
gsutil
.MANAGEMENT_SA=management-sa@PROJECT_NAME.iam.gserviceaccount.com gsutil iam ch serviceAccount:${MANAGEMENT_SA}:admin gs://${BUCKET}
Sostituisci
PROJECT_NAME
con il tuo progetto Google Cloud.Crea un nuovo ruolo IAM con le autorizzazioni per gestire questo bucket. Per creare il ruolo, salva prima la definizione del ruolo in un file, quindi crea il ruolo e associalo al tuo account di servizio di gestione.
Per completare questi passaggi, esegui questi comandi:
cat << EOF > anthos-oidc-role.yaml title: anthosAwsOidcStorageAdmin description: permissions to manage the OIDC buckets stage: GA includedPermissions: - storage.buckets.get EOF gcloud iam roles create anthosAwsOidcStorageAdmin --project=PROJECT_NAME \ --file=anthos-oidc-role.yaml gcloud projects add-iam-policy-binding \ PROJECT_NAME \ --member=serviceAccount:${MANAGEMENT_SA} \ --role=projects/PROJECT_NAME/roles/anthosAwsOidcStorageAdmin
Sostituisci
PROJECT_NAME
con il tuo progetto Google Cloud.Google Cloud CLI conferma che l'associazione dei criteri è stata creata.
Creazione di un cluster utente
Questa sezione è dedicata agli amministratori di cluster.
Crea un cluster utente con l'abilitazione di Workload Identity
Crea un cluster utente contenente i dettagli del bucket di rilevamento OIDC. Queste informazioni vengono impostate nel campo spec.controlPlane.workloadIdentity.oidcDiscoveryGCSBucket
dell'account AWSCluster
.
In questo esempio, crei un cluster manualmente dai CRD AWSCluster
e AWSNodePool
.
Passa alla directory con la configurazione di Cluster Anthos on AWS. Hai creato questa directory durante l'installazione del servizio di gestione.
cd anthos-aws
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
Apri un editor di testo e copia la seguente definizione di
AWSCluster
in un file denominatocustom-cluster.yaml
.apiVersion: multicloud.cluster.gke.io/v1 kind: AWSCluster metadata: name: CLUSTER_NAME spec: region: AWS_REGION networking: vpcID: VPC_ID podAddressCIDRBlocks: POD_ADDRESS_CIDR_BLOCKS serviceAddressCIDRBlocks: SERVICE_ADDRESS_CIDR_BLOCKS ServiceLoadBalancerSubnetIDs: SERVICE_LOAD_BALANCER_SUBNETS controlPlane: version: CLUSTER_VERSION # Latest version is 1.25.5-gke.2100 instanceType: AWS_INSTANCE_TYPE keyName: SSH_KEY_NAME subnetIDs: - CONTROL_PLANE_SUBNET_IDS securityGroupIDs: - CONTROL_PLANE_SECURITY_GROUPS iamInstanceProfile: CONTROL_PLANE_IAM_ROLE rootVolume: sizeGiB: ROOT_VOLUME_SIZE volumeType: ROOT_VOLUME_TYPE # Optional iops: ROOT_VOLUME_IOPS # Optional kmsKeyARN: ROOT_VOLUME_KEY # Optional etcd: mainVolume: sizeGiB: ETCD_VOLUME_SIZE volumeType: ETCD_VOLUME_TYPE # Optional iops: ETCD_VOLUME_IOPS # Optional kmsKeyARN: ETCD_VOLUME_KEY # Optional databaseEncryption: kmsKeyARN: ARN_OF_KMS_KEY hub: # Optional membershipName: ANTHOS_CONNECT_NAME cloudOperations: # Optional projectID: YOUR_PROJECT location: GCP_REGION enableLogging: ENABLE_LOGGING enableMonitoring: ENABLE_MONITORING workloadIdentity: # Optional oidcDiscoveryGCSBucket: WORKLOAD_IDENTITY_BUCKET
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del tuo cluster.
AWS_REGION: la regione AWS in cui viene eseguito il cluster.
VPC_ID: l'ID del VPC in cui viene eseguito il cluster.
POD_ADDRESS_CIDR_BLOCKS: l'intervallo di indirizzi IPv4 utilizzati dai pod del cluster. Attualmente è supportato un solo intervallo. L'intervallo non deve sovrapporsi ad alcuna subnet raggiungibile dalla tua rete. È sicuro utilizzare lo stesso intervallo su più oggetti AWSCluster diversi. Ad esempio,
10.2.0.0/16
.SERVICE_ADDRESS_CIDR_BLOCKS: l'intervallo di indirizzi IPv4 utilizzati dai servizi del cluster. Attualmente è supportato un solo intervallo. L'intervallo non deve sovrapporsi ad alcuna subnet raggiungibile dalla tua rete. È sicuro utilizzare lo stesso intervallo in più oggetti AWSCluster diversi. Ad esempio,
10.1.0.0/16
.SERVICE_LOAD_BALANCER_SUBNETS: gli ID subnet in cui i cluster Anthos su AWS possono creare bilanciatori del carico pubblici o privati.
CLUSTER_VERSION: una versione di Kubernetes supportata dai cluster Anthos su AWS. La versione più recente è 1.25.5-gke.2100.
AWS_INSTANCE_TYPE: un tipo di istanza EC2 supportato.
SSH_KEY_NAME: una coppia di chiavi AWS EC2.
CONTROL_PLANE_SUBNET_IDS: gli ID subnet nelle AZ in cui vengono eseguite le istanze del piano di controllo.
CONTROL_PLANE_SECURITY_GROUPS: un securityGroupID creato durante l'installazione del servizio di gestione. Puoi personalizzare l'aggiunta aggiungendo eventuali ID gruppo di sicurezza necessari per la connessione al piano di controllo.
CONTROL_PLANE_IAM_PROFILE: nome del profilo dell'istanza AWS EC2 assegnato alle repliche del piano di controllo.
ROOT_VOLUME_SIZE: le dimensioni in gibibyte (GiB) dei volumi root del tuo piano di controllo.
ROOT_VOLUME_TYPE con il tipo di volume EBS. Ad esempio:
gp3
.ROOT_VOLUME_IOPS con la quantità di operazioni di I/O al secondo (IOPS) di cui è stato eseguito il provisioning per il volume. Valido solo quando
volumeType
èGP3
. Per saperne di più, consulta Volumi SSD per uso generico (gp3).ROOT_VOLUME_KEY con il nome risorsa Amazon della chiave KMS AWS che cripta i volumi root dell'istanza del piano di controllo.
ETCD_VOLUME_SIZE: la dimensione dei volumi utilizzati da etcd.
ETCD_VOLUME_TYPE con il tipo di volume EBS. Ad esempio:
gp3
.ETCD_VOLUME_IOPS con la quantità di operazioni di I/O al secondo (IOPS) di cui è stato eseguito il provisioning per il volume. Valido solo quando
volumeType
ègp3
. Per saperne di più, consulta Volumi SSD per uso generico (gp3).ETCD_VOLUME_KEY con il nome risorsa Amazon della chiave KMS AWS che cripta i volumi di dati etcd del piano di controllo.
ARN_OF_KMS_KEY: la chiave AWS KMS utilizzata per criptare i secret del cluster.
ANTHOS_CONNECT_NAME: il nome dell'abbonamento Connetti utilizzato per registrare il cluster. Il nome dell'appartenenza deve essere univoco. Ad esempio,
projects/YOUR_PROJECT/locations/global/memberships/CLUSTER_NAME
, doveYOUR_PROJECT
è il tuo progetto Google Cloud eCLUSTER_NAME
è un nome univoco nel tuo progetto. Questo campo è facoltativo.YOUR_PROJECT: il tuo ID progetto.
GCP_REGION: la regione di Google Cloud in cui vuoi archiviare i log. Scegli una regione vicina a quella di AWS. Per ulteriori informazioni, consulta Località globali - Regioni e zone, ad esempio
us-central1
.ENABLE_LOGGING:
true
ofalse
, se Cloud Logging è abilitato sui nodi del piano di controllo.ENABLE_MONITORING:
true
ofalse
, se Cloud Monitoring è abilitato sui nodi del piano di controllo.WORKLOAD_IDENTITY_BUCKET: il nome del bucket Cloud Storage contenente le informazioni di rilevamento dell'identità del carico di lavoro. Questo campo è facoltativo.
Crea uno o più pool di AWSNode per il tuo cluster. Apri un editor di testo e copia la seguente definizione di AWSCluster in un file denominato
custom-nodepools.yaml
.apiVersion: multicloud.cluster.gke.io/v1 kind: AWSNodePool metadata: name: NODE_POOL_NAME spec: clusterName: AWSCLUSTER_NAME version: CLUSTER_VERSION # latest version is 1.25.5-gke.2100 region: AWS_REGION subnetID: AWS_SUBNET_ID minNodeCount: MINIMUM_NODE_COUNT maxNodeCount: MAXIMUM_NODE_COUNT maxPodsPerNode: MAXIMUM_PODS_PER_NODE_COUNT instanceType: AWS_NODE_TYPE keyName: KMS_KEY_PAIR_NAME iamInstanceProfile: NODE_IAM_PROFILE proxySecretName: PROXY_SECRET_NAME rootVolume: sizeGiB: ROOT_VOLUME_SIZE volumeType: VOLUME_TYPE # Optional iops: IOPS # Optional kmsKeyARN: NODE_VOLUME_KEY # Optional
Sostituisci quanto segue:
- NODE_POOL_NAME: un nome univoco per il tuo AWSNodePool.
- AWSCLUSTER_NAME: il nome del tuo AWSCluster. Ad esempio,
staging-cluster
. - CLUSTER_VERSION: un cluster Anthos supportato su versione di AWS Kubernetes.
- AWS_REGION: la stessa regione AWS di AWSCluster.
- AWS_SUBNET_ID: una subnet AWS nella stessa regione del tuo AWSCluster.
- MINIMUM_NODE_COUNT: il numero minimo di nodi nel pool di nodi. Per ulteriori informazioni, consulta Scalabilità dei cluster utente.
- MAXIMUM_NODE_COUNT: il numero massimo di nodi nel pool di nodi.
- MAXIMUM_PODS_PER_NODE_COUNT: il numero massimo di pod che i cluster Anthos su AWS possono allocare a un nodo.
- AWS_NODE_TYPE: un tipo di istanza AW2 EC2.
- KMS_KEY_PAIR_NAME: la coppia di chiavi AWS KMS assegnata a ogni worker del pool di nodi.
- NODE_IAM_PROFILE: il nome del profilo istanza AWS EC2 assegnato ai nodi nel pool.
- ROOT_VOLUME_SIZE: le dimensioni in gibibyte (GiB) dei volumi root del tuo piano di controllo.
- VOLUME_TYPE: il tipo di volume EBS del nodo AWS.
Ad esempio:
gp3
. - IOPS: la quantità di operazioni di I/O al secondo (IOPS) di cui è stato eseguito il provisioning per i volumi. Valido solo quando
volumeType
ègp3
. - NODE_VOLUME_KEY: l'ARN della chiave AWS KMS utilizzato per criptare il volume. Per maggiori informazioni, vedi Utilizzo di un CMK gestito dal cliente per criptare i volumi.
Applica i manifest al tuo servizio di gestione.
env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f custom-cluster.yaml env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f custom-nodepools.yaml
Crea una configurazione kube
All'avvio del cluster utente, puoi creare un contesto kubeconfig
per il tuo nuovo cluster utente. Puoi utilizzare il contesto per eseguire l'autenticazione a un cluster
utente o di gestione.
Utilizza
anthos-gke aws clusters get-credentials
per generare unkubeconfig
per il cluster utente in~/.kube/config
.env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del tuo cluster. Ad esempio,
cluster-0
.Utilizza
kubectl
per l'autenticazione nel tuo nuovo cluster utente.env HTTPS_PROXY=http://localhost:8118 \ kubectl cluster-info
Se il tuo cluster è pronto, l'output include gli URL per i componenti Kubernetes all'interno del cluster.
Visualizza lo stato del cluster
Il servizio di gestione esegue il provisioning di risorse AWS quando applichi un elemento AWSCluster
o AWSNodePool
.
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
Per elencare i cluster, utilizza
kubectl get AWSClusters
.env HTTPS_PROXY=http://localhost:8118 \ kubectl get AWSClusters
L'output include nome, stato, età, versione ed endpoint di ogni cluster.
Ad esempio, il seguente output include solo un elemento
AWSCluster
denominatocluster-0
:NAME STATE AGE VERSION ENDPOINT cluster-0 Provisioning 2m41s 1.25.5-gke.2100 gke-xyz.elb.us-east-1.amazonaws.com
Visualizza gli eventi del cluster
Per visualizzare gli eventi Kubernetes recenti dal tuo cluster utente, utilizza kubectl get events
.
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
Esegui
kubectl get events
.env HTTPS_PROXY=http://localhost:8118 \ kubectl get events
L'output include informazioni, avvisi ed errori relativi al tuo servizio di gestione.
Creazione del webhook di Workload Identity
Questa sezione è dedicata agli amministratori di cluster.
Per fornire le credenziali di Workload Identity ai tuoi carichi di lavoro senza ulteriori configurazioni, puoi facoltativamente creare un webhook nei cluster utente. Questo webhook intercetta le richieste di creazione di pod e rende disponibili al pod le seguenti informazioni su AWS IAM:
AWS_ROLE_ARN
: il nome della risorsa Amazon (ARN) del ruolo IAMaws-iam-token
: il token scambiato con le credenziali AWS IAMAWS_WEB_IDENTITY_TOKEN_FILE
: il percorso in cui è archiviato il token
Con queste variabili, i carichi di lavoro possono chiamare lo strumento a riga di comando AWS oppure l'SDK può accedere alle risorse concesse al ruolo AWS.
La creazione del webhook è facoltativa. Se decidi di non creare il webhook, devi impostare le variabili di ambiente elencate in precedenza nel pod. Per informazioni sul fatto di non utilizzare un webhook, consulta l'articolo Applicare le credenziali senza webhook.
Creare file YAML per il webhook
Per eseguire il deployment del webhook, segui questi passaggi:
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
Ottieni il nome del cluster utente con
kubectl
:env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster
kubectl
elenca tutti i cluster utente. Scegli il cluster utente creato con l'identità del carico di lavoro abilitata.Imposta il nome del cluster in una variabile di ambiente.
CLUSTER_NAME=CLUSTER_NAME
Sostituisci
CLUSTER_NAME
con il nome del tuo cluster. Ad esempio,cluster-0
.Imposta le variabili di ambiente per l'immagine e lo spazio dei nomi dei pod di Workload Identity.
IDENTITY_IMAGE=amazon/amazon-eks-pod-identity-webhook:ed8c41f WEBHOOK_NAMESPACE=workload-identity-webhook
Genera il manifest YAML del webhook in un file denominato
aws-webhook.yaml
seguendo questi passaggi:env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials ${CLUSTER_NAME} CLUSTER_CA=$(env HTTPS_PROXY=http://localhost:8118 \ kubectl config view --raw -o json | jq -r '.clusters[] | select(.name == "'$(kubectl config current-context)'") | .cluster."certificate-authority-data"') cat << EOF > aws-webhook.yaml apiVersion: v1 kind: Namespace metadata: name: ${WEBHOOK_NAMESPACE} --- apiVersion: v1 kind: ServiceAccount metadata: name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} rules: - apiGroups: [''] resources: ['secrets'] verbs: ['create'] - apiGroups: [''] resources: ['secrets'] verbs: ['get', 'update', 'patch'] resourceNames: - pod-identity-webhook --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-identity-webhook subjects: - kind: ServiceAccount name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-identity-webhook rules: - apiGroups: [''] resources: ['serviceaccounts'] verbs: ['get', 'watch', 'list'] - apiGroups: ['certificates.k8s.io'] resources: ['certificatesigningrequests'] verbs: ['create', 'get', 'list', 'watch'] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pod-identity-webhook roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: pod-identity-webhook subjects: - kind: ServiceAccount name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} --- apiVersion: apps/v1 kind: Deployment metadata: name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} spec: replicas: 1 selector: matchLabels: app: pod-identity-webhook template: metadata: labels: app: pod-identity-webhook spec: serviceAccountName: pod-identity-webhook containers: - name: pod-identity-webhook image: ${IDENTITY_IMAGE} imagePullPolicy: Always command: - /webhook - --in-cluster - --namespace=${WEBHOOK_NAMESPACE} - --service-name=pod-identity-webhook - --tls-secret=pod-identity-webhook - --annotation-prefix=eks.amazonaws.com - --token-audience=sts.amazonaws.com - --logtostderr volumeMounts: - name: webhook-certs mountPath: /var/run/app/certs readOnly: false volumes: - name: webhook-certs emptyDir: {} --- apiVersion: v1 kind: Service metadata: name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} annotations: prometheus.io/port: '443' prometheus.io/scheme: https prometheus.io/scrape: 'true' spec: ports: - port: 443 targetPort: 443 selector: app: pod-identity-webhook --- apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration metadata: name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} webhooks: - name: pod-identity-webhook.amazonaws.com failurePolicy: Ignore sideEffects: 'None' admissionReviewVersions: ['v1beta1'] clientConfig: service: name: pod-identity-webhook namespace: ${WEBHOOK_NAMESPACE} path: /mutate caBundle: ${CLUSTER_CA} rules: - operations: ['CREATE'] apiGroups: [''] apiVersions: ['v1'] resources: ['pods'] EOF
I contenuti di
aws-webhook.yaml
sono pronti per essere applicati al tuo cluster.
Applica il webhook al cluster utente
Per applicare il webhook al cluster utente, segui questi passaggi.
Applica il file
aws-webhook.yaml
al tuo cluster utente.env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f aws-webhook.yaml
Quando applichi il manifest, il pod webhook genera richieste di firma del certificato (CSR) di Kubernetes. Approva tutte le richieste da
system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook
conkubectl certificate approve
.env HTTPS_PROXY=http://localhost:8118 \ kubectl certificate approve $(env HTTPS_PROXY=http://localhost:8118 \ &&\ kubectl get csr -o \ jsonpath="{.items[?(@.spec.username==\"system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook\")].metadata.name}")
Verifica che non siano presenti altri CSR non approvati.
Utilizza
kubectl get csr
per verificare che tutti i CSR del richiedentesystem:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook
siano approvati:env HTTPS_PROXY=http://localhost:8118 \ kubectl get csr
Risposta:
NAME AGE REQUESTOR CONDITION csr-mxrt8 10s system:serviceaccount:default:pod-identity-webhook Approved,Issued
Configurazione del provider AWS OIDC
Questa sezione è dedicata agli amministratori di cluster.
Per creare un provider OIDC su AWS, AWS richiede un'identificazione intermedia dell'autorità di certificazione (CA) o un certificato di server. Le tue credenziali di rilevamento OIDC sono archiviate su
storage.googleapis.com
, con un certificato firmato da una CA intermedia denominata
GTS CA 1C3
. L'impronta digitale SHA-1
della sua CA intermedia GTS CA 1C3
è 08745487E891C19E3078C1F2A07E452950EF36F6
.
Per registrare il tuo bucket di individuazione OIDC come provider OIDC con AWS, esegui questi passaggi:
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
Salva l'URL dell'emittente OIDC, il percorso host dell'emittente e l'identificazione personale di Cloud Storage nelle variabili di ambiente.
ISSUER_URL=$(env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.workloadIdentityInfo.issuerURL}') ISSUER_HOSTPATH=${ISSUER_URL#"https://"} CA_THUMBPRINT=08745487E891C19E3078C1F2A07E452950EF36F6
Utilizza lo strumento a riga di comando
aws
per creare un provider OIDC su AWS.aws iam create-open-id-connect-provider \ --url ${ISSUER_URL} \ --thumbprint-list ${CA_THUMBPRINT} \ --client-id-list sts.amazonaws.com
Aggiorna l'identificazione personale
Se Google ruota la CA per storage.googleapis.com
, esegui questi comandi:
Copia l'identificazione personale del certificato aggiornata,
08745487E891C19E3078C1F2A07E452950EF36F6
.Segui le istruzioni per il comando
aws iam update-open-id-connect-provider-thumbprint
. Utilizzastorage.googleapis.com
come nome host di destinazione e08745487E891C19E3078C1F2A07E452950EF36F6
come Identificazione personale.
Creazione di ruoli e criteri di AWS IAM
Questa sezione è dedicata agli amministratori di cluster.
Creare un ruolo AWS IAM da associare a un account di servizio Kubernetes. Il ruolo IAM dispone delle autorizzazioni per sts:AssumeRoleWithWebIdentity
.
Per creare il ruolo, segui questi passaggi:
Trova o crea un criterio IAM AWS che conceda le autorizzazioni necessarie per i carichi di lavoro.
È necessario il nome risorsa Amazon (ARN) del criterio.Criterio IAM AWS. Ad esempio,
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
.Imposta le variabili di ambiente con le informazioni di autenticazione.
KSA_NAME=KUBERNETES_SERVICE_ACCOUNT WORKLOAD_NAMESPACE=WORKLOAD_IDENTITY_NAMESPACE AWS_ROLE_NAME=AWS_ROLE_NAME AWS_POLICY=EXISTING_AWS_POLICY
Sostituisci quanto segue:
- KUBERNETES_SERVICE_ACCOUNT: il nome del nuovo account di servizio Kubernetes
- WORKLOAD_IDENTITY_NAMESPACE: il nome dello spazio dei nomi in cui vengono eseguiti i carichi di lavoro
- AWS_ROLE_NAME: il nome di un nuovo ruolo AWS per i carichi di lavoro
- EXISTING_AWS_POLICY: il nome risorsa Amazon (ARN) di
un
criterio IAM AWS
esistente, ad esempio
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
.
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
Crea un criterio AWS IAM che consenta al tuo cluster utente di utilizzare credenziali di sicurezza temporanee con il AWS Security Token Service:
CLUSTER_ID=$(env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}') # Get the ID Provider ARN PROVIDER_ARN=$(aws iam list-open-id-connect-providers \ | jq '.OpenIDConnectProviderList' \ | jq ".[] | select(.Arn | contains(\"${CLUSTER_ID}\"))" \ | jq '.Arn' | tr -d '"') # Create AWS role and policy cat > irp-trust-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "${PROVIDER_ARN}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${ISSUER_HOSTPATH}:sub": "system:serviceaccount:${WORKLOAD_NAMESPACE}:${KSA_NAME}" } } } ] } EOF
Per creare un ruolo AWS IAM con questo criterio e collegare il criterio esistente al ruolo, esegui questi comandi:
aws iam create-role \ --role-name ${AWS_ROLE_NAME} \ --assume-role-policy-document file://irp-trust-policy.json aws iam update-assume-role-policy \ --role-name ${AWS_ROLE_NAME} \ --policy-document file://irp-trust-policy.json aws iam attach-role-policy \ --role-name ${AWS_ROLE_NAME} \ --policy-arn ${AWS_POLICY}
Lo strumento a riga di comando
aws
conferma che il criterio è associato al tuo ruolo.
Creazione di account di servizio Kubernetes per carichi di lavoro
Questa sezione è dedicata agli sviluppatori o agli amministratori di cluster.
Per creare account di servizio Kubernetes associati al ruolo AWS IAM specificato in precedenza, segui questi passaggi:
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del cluster utente.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del tuo cluster utente.Crea l'account di servizio Kubernetes eseguendo questi comandi:
S3_ROLE_ARN=$(aws iam get-role \ --role-name AWS_ROLE_NAME \ --query Role.Arn --output text) cat << EOF > k8s-service-account.yaml apiVersion: v1 kind: ServiceAccount metadata: name: ${KSA_NAME} namespace: WORKLOAD_IDENTITY_NAMESPACE EOF env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f k8s-service-account.yaml env HTTPS_PROXY=http://localhost:8118 \ kubectl annotate sa --namespace ${WORKLOAD_NAMESPACE} ${KSA_NAME} eks.amazonaws.com/role-arn=${S3_ROLE_ARN}
Sostituisci quanto segue:
AWS_ROLE_NAME
: il nome del ruolo AWS IAM da applicare ai carichi di lavoroWORKLOAD_IDENTITY_NAMESPACE
: il nome dello spazio dei nomi in cui vengono eseguiti i carichi di lavoro
Applicazione delle credenziali ai pod
Questa sezione è dedicata agli sviluppatori.
Questa sezione presuppone che tu abbia eseguito il deployment dell'identità del carico di lavoro webhook. Se non hai eseguito il deployment del webhook, vai ad Applicazione delle credenziali senza webhook.
Applicare le credenziali con il webhook
Questa sezione descrive come configurare i pod per leggere le credenziali messe a disposizione dal webhook.
Aggiungi l'account di servizio al pod
Per utilizzare Workload Identity con un carico di lavoro, aggiungi l'account di servizio Kubernetes ai campi seguenti:
- Per un deployment:
spec.template.spec.serviceAccountName
- Per un pod:
spec.serviceAccount
Il seguente manifest del pod lancia un'immagine CentOS di base e contiene il campo spec.serviceAccount
.
apiVersion: v1
kind: Pod
metadata:
name: sample-centos-pod
namespace: WORKLOAD_IDENTITY_NAMESPACE
spec:
containers:
- command:
- /bin/bash
- -ec
- while :; do echo '.'; sleep 500 ; done
image: amazon/aws-cli
name: centos
serviceAccount: KUBERNETES_SERVICE_ACCOUNT
Sostituisci quanto segue:
WORKLOAD_IDENTITY_NAMESPACE
: il nome dello spazio dei nomi in cui vengono eseguiti i carichi di lavoroKUBERNETES_SERVICE_ACCOUNT
: il nome dell'account di servizio Kubernetes creato in precedenza
Controlla se i pod hanno le variabili di ambiente impostate
Per verificare se i pod hanno le variabili di ambiente impostate, esegui questo comando per ottenere le informazioni del pod:
kubectl get pod --namespace WORKLOAD_IDENTITY_NAMESPACE POD_NAME -o yaml
Sostituisci quanto segue:
WORKLOAD_IDENTITY_NAMESPACE
: il nome dello spazio dei nomi in cui vengono eseguiti i carichi di lavoroPOD_NAME
: il nome del pod da controllare
L'output contiene i valori della variabile di ambiente in spec.containers.command.env
e il punto di montaggio per il token AWS IAM. Segue un esempio di manifest del pod.
apiVersion: v1
kind: Pod
metadata:
...
spec:
containers:
- command:
- /bin/bash
- -ec
- while :; do echo '.'; sleep 500 ; done
env:
- name: AWS_ROLE_ARN
value: arn:aws:iam::1234567890:role/my-example-workload-role-1
- name: AWS_WEB_IDENTITY_TOKEN_FILE
value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
image: amazon/aws-cli
imagePullPolicy: IfNotPresent
name: centos
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: my-k8s-serviceaccount-token-d4nz4
readOnly: true
- mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
name: aws-iam-token
readOnly: true
serviceAccount: my-k8s-serviceaccount
serviceAccountName: my-k8s-serviceaccount
volumes:
- name: aws-iam-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: sts.amazonaws.com
expirationSeconds: 86400
path: token
- name: my-k8s-serviceaccount-token-d4nz4
secret:
defaultMode: 420
secretName: my-k8s-serviceaccount-token-d4nz4
...
status:
...
Applicare le credenziali senza il webhook
Se non esegui il deployment dell'identità del carico di lavoro webhook, devi fare quanto segue:
Controlla se sono impostate le seguenti variabili di ambiente:
AWS_ROLE_ARN
: il nome della risorsa Amazon (ARN) del ruolo IAMAWS_WEB_IDENTITY_TOKEN_FILE
: il percorso in cui è archiviato il token
Crea un punto di montaggio per il token IAM (
aws-iam-token
) e l'account di servizio associato al ruolo AWS IAM
Crea un pod con credenziali per Workload Identity
Per creare un pod che includa le credenziali necessarie per l'identità del carico di lavoro, esegui questi passaggi:
Copia il seguente manifest del pod in un file denominato
sample-pod-no-webhook.yaml
. La configurazione avvia un'immagine CentOS di base con le credenziali necessarie.apiVersion: v1 kind: Pod metadata: name: sample-centos-pod-no-webhook namespace: WORKLOAD_IDENTITY_NAMESPACE spec: containers: - command: - /bin/bash - -ec - while :; do echo '.'; sleep 500 ; done image: centos:7 name: centos env: - name: AWS_ROLE_ARN value: IAM_ROLE_ARN - name: AWS_WEB_IDENTITY_TOKEN_FILE value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token volumeMounts: - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount name: aws-iam-token readOnly: true volumes: - name: aws-iam-token projected: defaultMode: 420 sources: - serviceAccountToken: audience: sts.amazonaws.com expirationSeconds: 86400 path: token serviceAccount: KUBERNETES_SERVICE_ACCOUNT
Sostituisci quanto segue:
WORKLOAD_IDENTITY_NAMESPACE
: il nome dello spazio dei nomi in cui vengono eseguiti i carichi di lavoro.IAM_ROLE_ARN
: l'ARN del ruolo IAM concesso al pod. Ad esempio,arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
.KUBERNETES_SERVICE_ACCOUNT
: il nome dell'account di servizio Kubernetes creato in precedenza.
Applica il manifest del pod al cluster utilizzando
kubectl
:env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f sample-pod-no-webhook.yaml
Verifica se i pod possono accedere alle risorse AWS
La procedura seguente descrive come verificare se il pod ha ricevuto le credenziali necessarie per il funzionamento di Workload Identity.
Per completare la procedura, devi disporre di:
bash
l'accesso alla shell al container; la maggior parte delle immagini di produzione non ha una shell disponibile. L'esempio seguente mostra come utilizzare il pod specificato nella sezione precedente per accedere ad AWS S3.Il pod deve avere accesso in uscita a Internet per scaricare l'interfaccia a riga di comando di AWS.
Per verificare se il pod può accedere a un bucket S3, segui questi passaggi:
Utilizza
kubectl exec
per avviare una shell bash interattiva sul podsample-centos-pod-no-webhook
:env HTTPS_PROXY=http://localhost:8118 \ kubectl exec -it --namespace ${WORKLOAD_NAMESPACE} sample-centos-pod-no-webhook -- bash
Il terminale apre la shell bash sul pod.
Controlla le autorizzazioni e le credenziali AWS IAM utilizzando lo strumento
aws
:aws sts assume-role-with-web-identity \ --role-arn ${AWS_ROLE_ARN} \ --role-session-name mh9test \ --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token \ --duration-seconds 1000
Lo strumento
aws
stampa informazioni sulle credenziali simili alle seguenti:{ "AssumedRoleUser": { "AssumedRoleId": "AROAR2ZZZLEXVSDCDJ37N:mh9test", "Arn": "arn:aws:sts::126285863215:assumed-role/my-example-workload-role-1/mh9test" }, "Audience": "sts.amazonaws.com", "Provider": "arn:aws:iam::126285863215:oidc-provider/storage.googleapis.com/gke-issuer-cec6c353", "SubjectFromWebIdentityToken": "system:serviceaccount:default:my-s3-reader-ksa", "Credentials": { "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "SessionToken": "MY_TOKEN", "Expiration": "2020-08-14T22:46:36Z", "AccessKeyId": "AKIAIOSFODNN7EXAMPLE" } }
Se viene visualizzato il seguente messaggio, controlla che il bucket sia accessibile pubblicamente:
An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements
Upgrade del webhook
Se hai creato un cluster Kubernetes 1.18 o precedente con Workload Identity abilitato e la versione webhook del carico di lavoro release-0.2.2-gke.0
, devi eseguire l'upgrade del webhook prima di eseguire l'upgrade a Kubernetes 1.19.
Per eseguire l'upgrade del webhook, segui questi passaggi:
Verifica che il webhook sia installato eseguendo i comandi seguenti:
env HTTPS_PROXY=http://localhost:8118 \ kubectl get MutatingWebhookConfiguration
Se nel cluster è stato eseguito il deployment del webhook, l'output include quanto segue:
NAME WEBHOOKS AGE pod-identity-webhook 1 11m
Se non viene eseguito il deployment del webhook nel cluster, puoi saltare i seguenti passaggi.
Se hai salvato il file
aws-webhook.yaml
, puoi eliminare il manifest. Se questo file non è disponibile, puoi eliminare manualmente i componenti del webhook. Scegli tra i file o i componenti di seguito.File
Se hai ancora il file
aws-webhook.yaml
, esegui il seguente comando per eliminare il webhook:env HTTPS_PROXY=http://localhost:8118 \ kubectl delete -f aws-webhook.yaml
Componenti
Per eliminare manualmente i componenti del webhook, esegui i comandi seguenti:
env HTTPS_PROXY=http://localhost:8118 \ kubectl delete namespace WEBHOOK_NAMESPACE env HTTPS_PROXY=http://localhost:8118 \ kubectl delete clusterrole pod-identity-webhook env HTTPS_PROXY=http://localhost:8118 \ kubectl delete clusterrolebinding pod-identity-webhook env HTTPS_PROXY=http://localhost:8118 \ kubectl delete mutatingwebhookconfiguration pod-identity-webhook
Sostituisci WEBHOOK_NAMESPACE con lo spazio dei nomi in cui hai installato il webhook di Workload Identity. Ad esempio:
workload-identity-webhook
.Verifica se sono presenti altre richieste di firma del certificato (CSR) eseguendo il seguente comando:
env HTTPS_PROXY=http://localhost:8118 \ kubectl get csr |grep pod-identity-webhook
Se l'output è vuoto, vai al passaggio successivo. Se sono presenti altri CSR, il comando
kubectl
elencherà gli CSR esistenti. Per rimuovere i CSR, esegui questo comando:env HTTPS_PROXY=http://localhost:8118 \ kubectl delete csr $(kubectl get csr -o \ jsonpath="{.items[?(@.spec.username==\"system:serviceaccount:WEBHOOK_NAMESPACE:pod-identity-webhook\")].metadata.name}")
Sostituisci WEBHOOK_NAMESPACE con lo spazio dei nomi in cui hai installato il webhook di Workload Identity. Ad esempio:
workload-identity-webhook
.Segui i passaggi descritti in Creare il webhook per eseguire il deployment della nuova versione del webhook.
Dopo aver eseguito il deployment della nuova versione del webhook, devi riavviare i pod che utilizzano il webhook. Puoi riavviare i tuoi pod eseguendo l'upgrade di un cluster utente.
Eseguire la pulizia
Questa sezione mostra come rimuovere le risorse create in precedenza in questo documento.
Esegui la pulizia dell'account di servizio e del relativo ruolo IAM associato
Per eliminare l'account di servizio e il ruolo IAM associato:
Libera spazio nell'account di servizio:
env HTTPS_PROXY=http://localhost:8118 \ kubectl delete sa KUBERNETES_SERVICE_ACCOUNT --namespace WORKLOAD_IDENTITY_NAMESPACE
Sostituisci quanto segue:
KUBERNETES_SERVICE_ACCOUNT
: il nome del nuovo account di servizio KubernetesWORKLOAD_IDENTITY_NAMESPACE
: il nome dello spazio dei nomi in cui vengono eseguiti i carichi di lavoro
Eseguire la pulizia del ruolo AWS IAM. Scegli una delle seguenti opzioni:
Elimina il ruolo AWS IAM con la console AWS.
Elimina il ruolo con lo strumento a riga di comando AWS utilizzando i seguenti comandi:
aws iam detach-role-policy \ --role-name=${AWS_ROLE_NAME} \ --policy-arn=${AWS_POLICY} aws iam delete-role --role-name=${AWS_ROLE_NAME}
Elimina il cluster utente
Per eliminare il cluster utente, esegui i passaggi per disinstallare i cluster Anthos su AWS.
Pulisci il provider AWS OIDC
Dopo aver eliminato il cluster utente, annulla la registrazione ed elimina il provider OIDC su AWS utilizzando il seguente comando shell bash
o la console AWS.
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
Elimina il ruolo con lo strumento a riga di comando AWS con i seguenti comandi:
CLUSTER_ID=$(env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}') PROVIDER_ARN=$(aws iam list-open-id-connect-providers \ | jq '.OpenIDConnectProviderList' \ | jq ".[] | select(.Arn | contains(\"${CLUSTER_ID}\"))" \ | jq '.Arn' | tr -d '"') aws iam delete-open-id-connect-provider \ --open-id-connect-provider-arn=${PROVIDER_ARN}
Riceverai la conferma dell'eliminazione del provider AWS OIDC.
Passaggi successivi
- Scopri di più sui ruoli IAM per gli account di servizio (IRSA) di AWS, che i cluster Anthos su AWS utilizzano per Workload Identity.
- Scopri di più sull'utilizzo di Workload Identity con Google Cloud.