Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Identity and Access Management
Identity and Access Management (IAM) è un servizio AWS che svolge due funzioni essenziali: autenticazione e autorizzazione. L'autenticazione implica la verifica di un'identità, mentre l'autorizzazione regola le azioni che possono essere eseguite dalle risorse AWS. All'interno di AWS, una risorsa può essere un altro servizio AWS EC2, ad esempio, o un principale AWS come un utente o un ruolo IAM. Le regole che regolano le azioni che una risorsa è autorizzata a eseguire sono espresse come politiche IAM.
Controllo dell'accesso ai cluster EKS
Il progetto Kubernetes supporta una varietà di strategie diverse per autenticare le richieste al servizio kube-apiserver, ad esempio Bearer Tokens, certificati X.509, OIDC, ecc. Attualmente EKS offre il supporto nativo per l'autenticazione dei token webhook, i token
La strategia di autenticazione webhook richiede un webhook che verifica i token bearer. Su EKS, questi token bearer vengono generati dalla CLI AWS o dal aws-iam-authenticatorkubectl
Mentre esegui i comandi, il token viene passato al kube-apiserver che lo inoltra al webhook di autenticazione. Se la richiesta è ben formata, il webhook richiama un URL prefirmato incorporato nel corpo del token. Questo URL convalida la firma della richiesta e restituisce informazioni sull'utente, ad esempio l'account dell'utente, Arn e il kube-apiserver. UserId
Per generare manualmente un token di autenticazione, digitate il seguente comando in una finestra di terminale:
aws eks get-token --cluster-name <cluster_name>
Puoi anche ottenere un token a livello di codice. Di seguito è riportato un esempio scritto in Go:
package main import ( "fmt" "log" "sigs.k8s.io/aws-iam-authenticator/pkg/token" ) func main() { g, _ := token.NewGenerator(false, false) tk, err := g.Get("<cluster_name>") if err != nil { log.Fatal(err) } fmt.Println(tk) }
L'output dovrebbe essere simile al seguente:
{ "kind": "ExecCredential", "apiVersion": "client.authentication.k8s.io/v1alpha1", "spec": {}, "status": { "expirationTimestamp": "2020-02-19T16:08:27Z", "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFKTkdSSUxLTlNSQzJXNVFBJTJGMjAyMDAyMTklMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDIxOVQxNTU0MjdaJlgtQW16LUV4cGlyZXM9NjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JTNCeC1rOHMtYXdzLWlkJlgtQW16LVNpZ25hdHVyZT0yMjBmOGYzNTg1ZTMyMGRkYjVlNjgzYTVjOWE0MDUzMDFhZDc2NTQ2ZjI0ZjI4MTExZmRhZDA5Y2Y2NDhhMzkz" } }
Ogni token inizia con k8s-aws-v1.
seguito da una stringa codificata in base64. La stringa, una volta decodificata, dovrebbe assomigliare a qualcosa di simile a questa:
https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXJPFRILKNSRC2W5QA%2F20200219%2Fus-xxxx-1%2Fsts%2Faws4_request&X-Amz-Date=20200219T155427Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Signature=XXXf8f3285e320ddb5e683a5c9a405301ad76546f24f28111fdad09cf648a393
Il token è costituito da un URL prefirmato che include una credenziale e una firma Amazon. Per ulteriori dettagli, consulta https://docs.aws.amazon.com/STS/latest/APIReference/API_ GetCallerIdentity .html.
Il token ha un tempo di vita (TTL) di 15 minuti, dopodiché sarà necessario generare un nuovo token. Questa operazione viene gestita automaticamente quando utilizzi un client, ad esempiokubectl
, se utilizzi la dashboard di Kubernetes, dovrai generare un nuovo token e riautenticarti ogni volta che il token scade.
Una volta che l'identità dell'utente è stata autenticata dal servizio AWS IAM, il kube-apiserver legge il file aws-auth
ConfigMap nel kube-system
Namespace per determinare il gruppo RBAC da associare all'utente. aws-auth
ConfigMap Viene utilizzato per creare una mappatura statica tra i principali IAM, ovvero IAM Users and Roles e i gruppi Kubernetes RBAC. È possibile fare riferimento ai gruppi RBAC in Kubernetes o. RoleBindings ClusterRoleBindings Sono simili ai ruoli IAM in quanto definiscono un insieme di azioni (verbi) che possono essere eseguite su una raccolta di risorse (oggetti) Kubernetes.
Cluster Access Manager
Cluster Access Manager, ora il modo preferito per gestire l'accesso dei principali AWS IAM ai cluster Amazon EKS, è una funzionalità dell'API AWS ed è una funzionalità opzionale per i cluster EKS v1.23 e versioni successive (nuovi o esistenti). Semplifica la mappatura delle identità tra AWS IAM e KubernetesRBACs, eliminando la necessità di passare da AWS a Kubernetes APIs o di modificarla aws-auth
ConfigMap per la gestione degli accessi, riducendo il sovraccarico operativo e aiutando a risolvere le configurazioni errate. Lo strumento consente inoltre agli amministratori del cluster di revocare o perfezionare cluster-admin
le autorizzazioni concesse automaticamente al principale AWS IAM utilizzato per creare il cluster.
Questa API si basa su due concetti:
-
Voci di accesso: un'identità di cluster direttamente collegata a un principale AWS IAM (utente o ruolo) autorizzata ad autenticarsi su un cluster Amazon EKS.
-
Policy di accesso: sono politiche specifiche di Amazon EKS che forniscono l'autorizzazione a un Access Entry per eseguire azioni nel cluster Amazon EKS.
Al momento del lancio Amazon EKS supporta solo policy predefinite e gestite da AWS. Le policy di accesso non sono entità IAM e sono definite e gestite da Amazon EKS.
Cluster Access Manager consente la combinazione di RBAC upstream con policy di accesso che supportano le decisioni di autorizzazione e approvazione (ma non negazione) sulle decisioni di Kubernetes AuthZ relative alle richieste dei server API. Una decisione di rifiuto viene presa quando entrambi gli autorizzatori RBAC a monte e Amazon EKS non sono in grado di determinare l'esito della valutazione di una richiesta.
Con questa funzionalità, Amazon EKS supporta tre modalità di autenticazione:
-
CONFIG_MAP
per continuare a utilizzare esclusivamenteaws-auth
ConfigMap. -
API_AND_CONFIG_MAP
per reperire i principali IAM autenticati sia da EKS Access Entry APIs che daaws-auth
ConfigMap, dando priorità agli Access Entries. Ideale per migrare le autorizzazioni esistenti su Access Entries.aws-auth
-
API
affidarsi esclusivamente a EKS Access Entry. APIs Questo è il nuovo approccio consigliato.
Per iniziare, gli amministratori dei cluster possono creare o aggiornare i cluster Amazon EKS, impostare l'autenticazione API_AND_CONFIG_MAP
o il API
metodo preferito e definire gli Access Entries per concedere l'accesso ai principali AWS IAM desiderati.
$ aws eks create-cluster \ --name <CLUSTER_NAME> \ --role-arn <CLUSTER_ROLE_ARN> \ --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \ --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \ --access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=false
Il comando precedente è un esempio di creazione di un cluster Amazon EKS già senza le autorizzazioni di amministratore del creatore del cluster.
È possibile aggiornare la configurazione dei cluster Amazon EKS per abilitare API
AuthenticationMode utilizzando il update-cluster-config
comando, per farlo sui cluster esistenti CONFIG_MAP
dovrai prima aggiornare a e poi a. API_AND_CONFIG_MAP
API
Queste operazioni non possono essere annullate, il che significa che non è possibile passare da API
API_AND_CONFIG_MAP
o CONFIG_MAP
e viceversa. API_AND_CONFIG_MAP
CONFIG_MAP
$ aws eks update-cluster-config \ --name <CLUSTER_NAME> \ --access-config authenticationMode=API
L'API supporta i comandi per aggiungere e revocare l'accesso al cluster, nonché per convalidare le politiche di accesso e le voci di accesso esistenti per il cluster specificato. Le politiche predefinite vengono create per corrispondere a RBACs Kubernetes come segue.
Politica di accesso EKS | Kubernetes RBAC |
---|---|
Amazon EKSCluster AdminPolicy |
amministratore del cluster |
EKSAdminPolitica di Amazon |
admin |
EKSEditPolitica di Amazon |
modifica |
EKSViewPolitica di Amazon |
visualizzazione |
$ aws eks list-access-policies { "accessPolicies": [ { "name": "AmazonEKSAdminPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy" }, { "name": "AmazonEKSClusterAdminPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy" }, { "name": "AmazonEKSEditPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy" }, { "name": "AmazonEKSViewPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy" } ] } $ aws eks list-access-entries --cluster-name <CLUSTER_NAME> { "accessEntries": [] }
Non sono disponibili voci di accesso quando il cluster viene creato senza l'autorizzazione di amministratore del creatore del cluster, che è l'unica voce creata per impostazione predefinita.
Il aws-auth
ConfigMap (obsoleto)
Un modo in cui l'integrazione di Kubernetes con l'autenticazione AWS può essere effettuata tramite aws-auth
ConfigMap, che risiede nel Namespace. kube-system
È responsabile della mappatura dell'autenticazione AWS IAM Identities (Users, Groups and Roles) all'autorizzazione di controllo degli accessi basato sui ruoli (RBAC) di Kubernetes. aws-auth
ConfigMap Viene creato automaticamente nel cluster Amazon EKS durante la fase di provisioning. È stato inizialmente creato per consentire ai nodi di unirsi al cluster, ma come accennato in precedenza, è possibile utilizzarlo anche ConfigMap per aggiungere RBACs l'accesso ai principali IAM.
Per controllare quello del tuo cluster aws-auth
ConfigMap, puoi usare il seguente comando.
kubectl -n kube-system get configmap aws-auth -o yaml
Questo è un esempio di configurazione predefinita di aws-auth
ConfigMap.
apiVersion: v1 data: mapRoles: | - groups: - system:bootstrappers - system:nodes - system:node-proxier rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/kube-system-<SELF_GENERATED_UUID> username: system:node:{{SessionName}} kind: ConfigMap metadata: creationTimestamp: "2023-10-22T18:19:30Z" name: aws-auth namespace: kube-system
La sessione principale di questo ConfigMap, si trova data
sotto il mapRoles
blocco, che è fondamentalmente composto da 3 parametri.
-
gruppi: Kubernetes group/groups a cui mappare il ruolo IAM. Può essere un gruppo predefinito o un gruppo personalizzato specificato in un o.
clusterrolebinding
rolebinding
Nell'esempio precedente abbiamo dichiarato solo gruppi di sistema. -
rolearn: L'ARN del ruolo AWS IAM deve essere mappato al gruppo/gruppi Kubernetes add, utilizzando il seguente formato.
arn:<PARTITION>:iam::<AWS_ACCOUNT_ID>:role/role-name
-
username: il nome utente all'interno di Kubernetes da mappare al ruolo AWS IAM. Può essere qualsiasi nome personalizzato.
È anche possibile mappare le autorizzazioni per gli utenti di AWS IAM, definendo un nuovo blocco di configurazione permapUsers
, data
in the aws-auth
ConfigMap, che sostituisce il parametro rolearn per userarn, tuttavia come best practice è sempre consigliato all'utente. mapRoles
Per gestire le autorizzazioni, puoi modificare l'aws-auth
ConfigMap aggiunta o la rimozione dell'accesso al tuo cluster Amazon EKS. Sebbene sia possibile modificarlo aws-auth
ConfigMap manualmente, è consigliabile utilizzare strumenti comeeksctl
, poiché si tratta di una configurazione molto sensibile e una configurazione imprecisa può bloccarti all'esterno del cluster Amazon EKS. Consulta la sottosezione Usa gli strumenti per apportare modifiche all' ConfigMapaws-auth di seguito per
Consigli per l'accesso al cluster
Rendi privato l'EKS Cluster Endpoint
Per impostazione predefinita, quando si effettua il provisioning di un cluster EKS, l'endpoint del cluster API è impostato su pubblico, ovvero è accessibile da Internet. Nonostante sia accessibile da Internet, l'endpoint è ancora considerato sicuro perché richiede che tutte le richieste API siano autenticate da IAM e quindi autorizzate da Kubernetes RBAC. Detto questo, se la tua politica di sicurezza aziendale impone di limitare l'accesso all'API da Internet o ti impedisce di instradare il traffico all'esterno del VPC del cluster, puoi:
-
Configurate l'endpoint del cluster EKS in modo che sia privato. Per ulteriori informazioni su questo argomento, vedere Modifica dell'accesso agli endpoint del cluster.
-
Lascia pubblico l'endpoint del cluster e specifica quali blocchi CIDR possono comunicare con l'endpoint del cluster. I blocchi sono in effetti un insieme di indirizzi IP pubblici inseriti nella lista bianca a cui è consentito accedere all'endpoint del cluster.
-
Configura l'accesso pubblico con una serie di blocchi CIDR inseriti nella whitelist e imposta l'accesso privato agli endpoint su abilitato. Ciò consentirà l'accesso pubblico da una gamma specifica di utenti pubblici, forzando al IPs contempo tutto il traffico di rete tra i kubelet (worker) e l'API Kubernetes attraverso l'account incrociato ENIs che viene fornito nel VPC del cluster quando viene effettuato il provisioning del piano di controllo.
Non utilizzare un token di account di servizio per l'autenticazione
Un token di account di servizio è una credenziale statica di lunga durata. Se viene compromessa, smarrita o rubata, un utente malintenzionato potrebbe essere in grado di eseguire tutte le azioni associate a quel token fino all'eliminazione dell'account del servizio. A volte, potrebbe essere necessario concedere un'eccezione per le applicazioni che devono utilizzare l'API Kubernetes dall'esterno del cluster, ad esempio un'applicazione di pipeline CI/CD. Se tali applicazioni vengono eseguite sull'infrastruttura AWS, come le EC2 istanze, prendi in considerazione l'utilizzo di un profilo di istanza e la mappatura su un ruolo RBAC di Kubernetes.
Utilizza l'accesso meno privilegiato alle risorse AWS
A un utente IAM non è necessario assegnare privilegi alle risorse AWS per accedere all'API Kubernetes. Se devi concedere a un utente IAM l'accesso a un cluster EKS, crea una voce aws-auth
ConfigMap per quell'utente che corrisponda a uno specifico gruppo Kubernetes RBAC.
Rimuovi le autorizzazioni di amministratore del cluster dal cluster creator principal
Per impostazione predefinita, i cluster Amazon EKS vengono creati con un'cluster-admin
autorizzazione permanente associata al cluster creator principal. Con l'API Cluster Access Manager, è possibile creare cluster senza che questa autorizzazione imposti sufalse
, quando si utilizza la --access-config bootstrapClusterCreatorAdminPermissions
modalità API_AND_CONFIG_MAP
di API
autenticazione. La revoca di questo accesso è considerata una best practice per evitare modifiche indesiderate alla configurazione del cluster. La procedura per revocare questo accesso segue la stessa procedura per revocare qualsiasi altro accesso al cluster.
L'API offre la flessibilità necessaria per dissociare solo un principale IAM da una policy di accesso, in questo caso il. AmazonEKSClusterAdminPolicy
$ aws eks list-associated-access-policies \ --cluster-name <CLUSTER_NAME> \ --principal-arn <IAM_PRINCIPAL_ARN> $ aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \ --principal-arn <IAM_PRINCIPAL_ARN. \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
Oppure rimuovendo completamente la voce di accesso associata all'cluster-admin
autorizzazione.
$ aws eks list-access-entries --cluster-name <CLUSTER_NAME> { "accessEntries": [] } $ aws eks delete-access-entry --cluster-name <CLUSTER_NAME> \ --principal-arn <IAM_PRINCIPAL_ARN>
Questo accesso può essere nuovamente concesso se necessario durante uno scenario di incidente, emergenza o rottura del vetro in cui il cluster è altrimenti inaccessibile.
Se il cluster aws-auth
ConfigMap è ancora configurato con il metodo di CONFIG_MAP
autenticazione, a tutti gli utenti aggiuntivi dovrebbe essere concesso l'aws-auth
ConfigMapaccesso al cluster tramite e dopo la configurazione il ruolo assegnato all'entità che ha creato il cluster, che può essere eliminato e ricreato solo in caso di incidente, emergenza o scenario di rottura del vetro, o se il cluster aws-auth
ConfigMap è danneggiato e il cluster è altrimenti inaccessibile. Ciò può essere particolarmente utile nei cluster di produzione.
Usa IAM Roles quando più utenti necessitano di un accesso identico al cluster
Invece di creare una voce per ogni singolo utente IAM, consenti a tali utenti di assumere un ruolo IAM e mappare tale ruolo a un gruppo Kubernetes RBAC. Questo sarà più facile da gestire, soprattutto con l'aumentare del numero di utenti che richiedono l'accesso.
Importante
Quando si accede al cluster EKS con l'entità IAM mappata da aws-auth
ConfigMap, il nome utente descritto viene registrato nel campo utente del registro di controllo di Kubernetes. Se utilizzi un ruolo IAM, gli utenti effettivi che assumono quel ruolo non vengono registrati e non possono essere controllati.
Se usi ancora aws-auth
ConfigMap come metodo di autenticazione, quando assegni le autorizzazioni RBAC di K8s a un ruolo IAM, dovresti includere\ {{}} nel tuo nome utente. SessionName In questo modo, il registro di controllo registrerà il nome della sessione in modo da poter tenere traccia dell'utente effettivo che assume questo ruolo insieme al registro. CloudTrail
- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole username: testRole:{{SessionName}} groups: - system:masters
Utilizza l'accesso meno privilegiato durante la creazione e RoleBindings ClusterRoleBindings
Come il punto precedente sulla concessione dell'accesso alle risorse AWS, RoleBindings e ClusterRoleBindings dovrebbe includere solo il set di autorizzazioni necessarie per eseguire una funzione specifica. Evita di utilizzarlo ["*"]
nei tuoi ruoli e ClusterRoles a meno che non sia assolutamente necessario. Se non sei sicuro delle autorizzazioni da assegnare, prendi in considerazione l'utilizzo di uno strumento come audit2rbac
Crea un cluster utilizzando un processo automatizzato
Come illustrato nei passaggi precedenti, quando si crea un cluster Amazon EKS, se non si utilizza la modalità di utilizzo API_AND_CONFIG_MAP
o di API
autenticazione e non si sceglie di delegare cluster-admin
le autorizzazioni al creatore del cluster, all'utente o ruolo dell'entità IAM, ad esempio un utente federato che crea il cluster, vengono automaticamente concesse system:masters
le autorizzazioni nella configurazione RBAC del cluster. Pur essendo una buona pratica per rimuovere questa autorizzazione, come descritto qui, se si utilizza il metodo di CONFIG_MAP
autenticazione aws-auth
ConfigMap, tale accesso non può essere revocato. Pertanto è una buona idea creare il cluster con una pipeline di automazione dell'infrastruttura legata a un ruolo IAM dedicato, senza che altri utenti o entità si assumano autorizzazioni e verificare regolarmente le autorizzazioni, le policy e chi ha accesso per attivare la pipeline. Inoltre, questo ruolo non deve essere utilizzato per eseguire azioni di routine sul cluster ed essere utilizzato esclusivamente per azioni a livello di cluster attivate dalla pipeline, ad esempio tramite modifiche al codice SCM.
Crea il cluster con un ruolo IAM dedicato
Quando crei un cluster Amazon EKS, all'utente o al ruolo dell'entità IAM, ad esempio un utente federato che crea il cluster, vengono automaticamente concesse system:masters
le autorizzazioni nella configurazione RBAC del cluster. Questo accesso non può essere rimosso e non è gestito tramite. aws-auth
ConfigMap Pertanto è una buona idea creare il cluster con un ruolo IAM dedicato e verificare regolarmente chi può assumere tale ruolo. Questo ruolo non deve essere utilizzato per eseguire azioni di routine sul cluster e, a tal fine, dovrebbe essere concesso l'accesso al cluster aws-auth
ConfigMap ad altri utenti tramite il. Una volta aws-auth
ConfigMap configurato, il ruolo deve essere protetto e utilizzato solo in modalità temporanea con privilegi elevati /break glass per scenari in cui il cluster è altrimenti inaccessibile. Ciò può essere particolarmente utile nei cluster in cui non è configurato l'accesso diretto degli utenti.
Controlla regolarmente l'accesso al cluster
È probabile che chi richiede l'accesso cambi nel tempo. Pianifica di controllarli periodicamente aws-auth
ConfigMap per vedere a chi è stato concesso l'accesso e quali diritti sono stati assegnati. Puoi anche utilizzare strumenti open source come kubectl-who-can
Se ti affidi a aws-auth
ConfigMap, usa gli strumenti per apportare modifiche.
Un aws-auth formattato in modo errato ConfigMap può causare la perdita dell'accesso al cluster. Se è necessario apportare modifiche al, utilizzare uno strumento. ConfigMap
eksctl La eksctl
CLI include un comando per aggiungere mappature di identità a aws-auth. ConfigMap
Visualizza la guida CLI:
$ eksctl create iamidentitymapping --help ...
Controlla le identità mappate sul tuo cluster Amazon EKS.
$ eksctl get iamidentitymapping --cluster $CLUSTER_NAME --region $AWS_REGION ARN USERNAME GROUPS ACCOUNT arn:aws:iam::788355785855:role/kube-system-<SELF_GENERATED_UUID> system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
Assegna a un ruolo IAM un amministratore del cluster:
$ eksctl create iamidentitymapping --cluster <CLUSTER_NAME> --region=<region> --arn arn:aws:iam::123456:role/testing --group system:masters --username admin ...
Per ulteriori informazioni, consulta i eksctl
documenti
aws-auth
by keikoproj include sia una libreria cli che una go.
Scarica e visualizza la guida CLI di aiuto:
$ go get github.com/keikoproj/aws-auth ... $ aws-auth help ...
In alternativa, installalo aws-auth
con il gestore di plugin krew
$ kubectl krew install aws-auth ... $ kubectl aws-auth ...
Consulta i documenti aws-auth su GitHub per ulteriori informazioni, inclusa la libreria go
Il aws-iam-authenticator
progetto include una CLI per l'aggiornamento di. ConfigMap
Scarica una versione
Aggiungi le autorizzazioni del cluster a un ruolo IAM:
$ ./aws-iam-authenticator add role --rolearn arn:aws:iam::185309785115:role/lil-dev-role-cluster --username lil-dev-user --groups system:masters --kubeconfig ~/.kube/config ...
Approcci alternativi all'autenticazione e alla gestione degli accessi
Sebbene IAM sia il modo preferito per autenticare gli utenti che devono accedere a un cluster EKS, è possibile utilizzare un provider di identità OIDC, ad esempio GitHub utilizzando un proxy di autenticazione e l'imitazione di Kubernetes.
Importante
EKS supporta nativamente l'autenticazione OIDC senza utilizzare un proxy. Per ulteriori informazioni, leggi il blog di lancio, Introducing OIDC identity provider authentication for Amazon EKS
Puoi anche usare AWS SSO per federare AWS con un provider di identità esterno, ad esempio Azure AD. Se decidi di utilizzarlo, AWS CLI v2.0 include un'opzione per creare un profilo denominato che semplifica l'associazione di una sessione SSO alla sessione CLI corrente e l'assunzione di un ruolo IAM. Tieni presente che devi assumere un ruolo prima di iniziare, kubectl
poiché il ruolo IAM viene utilizzato per determinare il gruppo RBAC Kubernetes dell'utente.
Identità e credenziali per i pod EKS
Alcune applicazioni eseguite all'interno di un cluster Kubernetes richiedono l'autorizzazione per chiamare l'API Kubernetes per funzionare correttamente. Ad esempio, il controller AWS Load Balancer
Account di servizio Kubernetes
Un account di servizio è un tipo speciale di oggetto che consente di assegnare un ruolo Kubernetes RBAC a un pod. Un account di servizio predefinito viene creato automaticamente per ogni Namespace all'interno di un cluster. Quando distribuisci un pod in un Namespace senza fare riferimento a un account di servizio specifico, l'account di servizio predefinito per quel Namespace verrà automaticamente assegnato al Pod e il Secret, ovvero il token dell'account di servizio (JWT) per quell'account di servizio, verrà montato sul pod come volume in. /var/run/secrets/kubernetes.io/serviceaccount
La decodifica del token dell'account di servizio in quella directory rivelerà i seguenti metadati:
{ "iss": "kubernetes/serviceaccount", "kubernetes.io/serviceaccount/namespace": "default", "kubernetes.io/serviceaccount/secret.name": "default-token-5pv4z", "kubernetes.io/serviceaccount/service-account.name": "default", "kubernetes.io/serviceaccount/service-account.uid": "3b36ddb5-438c-11ea-9438-063a49b60fba", "sub": "system:serviceaccount:default:default" }
L'account di servizio predefinito dispone delle seguenti autorizzazioni per l'API Kubernetes.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: "2020-01-30T18:13:25Z" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:discovery resourceVersion: "43" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery uid: 350d2ab8-438c-11ea-9438-063a49b60fba rules: - nonResourceURLs: - /api - /api/* - /apis - /apis/* - /healthz - /openapi - /openapi/* - /version - /version/ verbs: - get
Questo ruolo autorizza gli utenti non autenticati e autenticati a leggere le informazioni sull'API ed è considerato sicuro in quanto accessibile al pubblico.
Quando un'applicazione in esecuzione all'interno di un Pod chiama Kubernetes APIs, al Pod deve essere assegnato un account di servizio che gli conceda esplicitamente l'autorizzazione a chiamarli. APIs Analogamente alle linee guida per l'accesso degli utenti, il ruolo o l'account ClusterRole associato a un account di servizio devono essere limitati alle risorse e ai metodi API di cui l'applicazione ha bisogno per funzionare e nient'altro. Per utilizzare un account di servizio non predefinito, è sufficiente impostare il spec.serviceAccountName
campo di un Pod sul nome dell'account di servizio che si desidera utilizzare. Per ulteriori informazioni sulla creazione di account di servizio, consultate https://kubernetes. io/docs/reference/access-authn-authz/rbac/#. service-account-permissions
Nota
Prima di Kubernetes 1.24, Kubernetes creava automaticamente un segreto per ogni account di servizio. Questo segreto era montato sul pod all'indirizzo/var/run/secrets/kubernetes.io/serviceaccounte veniva utilizzato dal pod per l'autenticazione sul server dell'API Kubernetes. In Kubernetes 1.24, un token di account di servizio viene generato dinamicamente quando il pod è in esecuzione ed è valido solo per un'ora per impostazione predefinita. Non verrà creato un segreto per l'account di servizio. Se hai un'applicazione che viene eseguita all'esterno del cluster e che deve autenticarsi nell'API Kubernetes, ad esempio Jenkins, dovrai creare un tipo segreto kubernetes.io/service-account-token
insieme a un'annotazione che faccia riferimento all'account del servizio, ad esempio. metadata.annotations.kubernetes.io/service-account.name: <SERVICE_ACCOUNT_NAME>
I segreti creati in questo modo non scadono.
IAM Roles for Service Accounts (IRSA)
IRSA è una funzionalità che consente di assegnare un ruolo IAM a un account di servizio Kubernetes. Funziona sfruttando una funzionalità di Kubernetes nota come Service Account Token Volume Projection.sts:AssumeRoleWithWebIdentity
. Dopo aver convalidato la firma del token, IAM scambia il token emesso da Kubernetes con una credenziale di ruolo AWS temporanea.
Quando si utilizza IRSA, è importante riutilizzare le sessioni SDK AWS per evitare chiamate non necessarie ad AWS STS.
La decodifica del token (JWT) per IRSA produrrà un output simile all'esempio riportato di seguito:
{ "aud": [ "sts.amazonaws.com" ], "exp": 1582306514, "iat": 1582220114, "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128", "kubernetes.io": { "namespace": "default", "pod": { "name": "alpine-57b5664646-rf966", "uid": "5a20f883-5407-11ea-a85c-0e62b7a4a436" }, "serviceaccount": { "name": "s3-read-only", "uid": "a720ba5c-5406-11ea-9438-063a49b60fba" } }, "nbf": 1582220114, "sub": "system:serviceaccount:default:s3-read-only" }
Questo particolare token concede al Pod i privilegi di sola visualizzazione a S3 assumendo un ruolo IAM. Quando l'applicazione tenta di leggere da S3, il token viene scambiato con un set temporaneo di credenziali IAM simile al seguente:
{ "AssumedRoleUser": { "AssumedRoleId": "AROA36C6WWEJULFUYMPB6:abc", "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-winterfell-addon-iamserviceaccount-de-Role1-1D61LT75JH3MB/abc" }, "Audience": "sts.amazonaws.com", "Provider": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128", "SubjectFromWebIdentityToken": "system:serviceaccount:default:s3-read-only", "Credentials": { "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "SessionToken": "FwoGZXIvYXdzEGMaDMLxAZkuLpmSwYXShiL9A1S0X87VBC1mHCrRe/pB2oesl1eXxUYnPJyC9ayOoXMvqXQsomq0xs6OqZ3vaa5Iw1HIyA4Cv1suLaOCoU3hNvOIJ6C94H1vU0siQYk7DIq9Av5RZeuE2FnOctNBvYLd3i0IZo1ajjc00yRK3v24VRq9nQpoPLuqyH2jzlhCEjXuPScPbi5KEVs9fNcOTtgzbVf7IG2gNiwNs5aCpN4Bv/Zv2A6zp5xGz9cWj2f0aD9v66vX4bexOs5t/YYhwuwAvkkJPSIGvxja0xRThnceHyFHKtj0Hbi/PWAtlI8YJcDX69cM30JAHDdQHltm/4scFptW1hlvMaPWReCAaCrsHrATyka7ttw5YlUyvZ8EPogj6fwHlxmrXM9h1BqdikomyJU00gm1FJelfP1zAwcyrxCnbRl3ARFrAt8hIlrT6Vyu8WvWtLxcI8KcLcJQb/LgkWsCTGlYcY8z3zkigJMbYn07ewTL5Ss7LazTJJa758I7PZan/v3xQHd5DEc5WBneiV3iOznDFgup0VAMkIviVjVCkszaPSVEdK2NU7jtrh6Jfm7bU/3P6ZGCkyDLIa8MBn9KPXeJd/yjTk5IifIwO/mDpGNUribg6TPxhzZ8b/XdZO1kS1gVgqjXyVCM+BRBh6C4H21w/eMzjCtDIpoxt5rGKL6Nu/IFMipoC4fgx6LIIHwtGYMG7SWQi7OsMAkiwZRg0n68/RqWgLzBt/4pfjSRYuk=", "Expiration": "2020-02-20T18:49:50Z", "AccessKeyId": "ASIAIOSFODNN7EXAMPLE" } }
Un webhook mutante che viene eseguito come parte del piano di controllo EKS inserisce l'AWS Role ARN e il percorso di un file di token di identità Web nel Pod come variabili di ambiente. Questi valori possono essere forniti anche manualmente.
AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
Il kubelet ruoterà automaticamente il token proiettato quando supera l'80% del suo TTL totale o dopo 24 ore. AWS è SDKs responsabile del ricaricamento del token quando ruota. Per ulteriori informazioni su IRSA, consulta https://docs.aws.amazon.com/eks/ latest/userguide/iam - -technical-overview.html. roles-for-service-accounts
EKS Pod Identity
EKS Pod Identities è una funzionalità lanciata al re:Invent 2023 che ti consente di assegnare un ruolo IAM a un account di servizio Kubernetes, senza la necessità di configurare un provider di identità (IDP) Open Id Connect (OIDC) per ogni cluster del tuo account AWS. Per utilizzare EKS Pod Identity, devi implementare un agente che funzioni come pod su ogni nodo di lavoro idoneo. DaemonSet Questo agente è reso disponibile come componente aggiuntivo EKS ed è un prerequisito per utilizzare la funzione EKS Pod Identity. Le tue applicazioni devono utilizzare una versione supportata dell'SDK AWS per utilizzare questa funzionalità.
Quando le identità dei pod EKS sono configurate per un Pod, EKS monterà e aggiornerà un token di identità del pod su. /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
Questo token verrà utilizzato dall'SDK AWS per comunicare con l'EKS Pod Identity Agent, che utilizza il token di identità del pod e il ruolo IAM dell'agente per creare credenziali temporanee per i tuoi pod chiamando l'API. AssumeRoleForPodIdentity Il token di identità del pod fornito ai tuoi pod è un JWT emesso dal tuo cluster EKS e firmato crittograficamente, con dichiarazioni JWT appropriate da utilizzare con EKS Pod Identities.
Per ulteriori informazioni su EKS Pod Identities, consulta questo blog.
Non è necessario apportare modifiche al codice dell'applicazione per utilizzare EKS Pod Identities. Le versioni AWS SDK supportate scopriranno automaticamente le credenziali rese disponibili con EKS Pod Identities utilizzando la catena di fornitori di credenziali. Come IRSA, le identità dei pod EKS impostano le variabili all'interno dei pod per indirizzarli a trovare le credenziali AWS.
Utilizzo dei ruoli IAM per EKS Pod Identities
-
EKS Pod Identities può assumere direttamente solo un ruolo IAM che appartiene allo stesso account AWS del cluster EKS. Per accedere a un ruolo IAM in un altro account AWS, devi assumere quel ruolo configurando un profilo nella configurazione dell'SDK o nel codice dell'applicazione.
-
Quando le identità EKS Pod vengono configurate per gli account di servizio, la persona o il processo che configura la Pod Identity Association deve avere l'
iam:PassRole
autorizzazione per quel ruolo. -
A ciascun account di servizio può essere associato un solo ruolo IAM tramite EKS Pod Identities, tuttavia è possibile associare lo stesso ruolo IAM a più account di servizio.
-
I ruoli IAM utilizzati con EKS Pod Identities devono consentire al
pods.eks.amazonaws.com
Service Principal di assumerli e impostare i tag di sessione. Di seguito è riportato un esempio di policy di trust dei ruoli che consente a EKS Pod Identities di utilizzare un ruolo IAM:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:SourceOrgId": "${aws:ResourceOrgId}" } } } ] }
AWS consiglia di utilizzare chiavi condizionali come quelle aws:SourceOrgId
che aiutano a proteggersi dal problema del sostituto confuso tra diversi servizi. Nell'esempio precedente, role trust policy, ResourceOrgId
è una variabile uguale all'ID dell'organizzazione AWS Organizations dell'organizzazione AWS a cui appartiene l'account AWS. EKS passerà un valore aws:SourceOrgId
uguale a quello quando assumerà un ruolo con EKS Pod Identities.
ABAC ed EKS Pod Identities
Quando EKS Pod Identities assume un ruolo IAM, imposta i seguenti tag di sessione:
Tag di sessione EKS Pod Identities | Valore |
---|---|
spazio dei nomi kubernetes |
Lo spazio dei nomi in cui viene eseguito il pod associato a EKS Pod Identities. |
kubernetes-service-account |
Il nome dell'account del servizio Kubernetes associato a EKS Pod Identities |
eks-cluster-arn |
L'ARN del cluster EKS, ad es. |
eks-cluster-name |
Il nome del cluster EKS. Tieni presente che i nomi dei cluster EKS possono essere gli stessi all'interno del tuo account AWS e i cluster EKS in altri account AWS. |
kubernetes-pod-name |
Il nome del pod in EKS. |
kubernetes-pod-uid |
L'UID del pod in EKS. |
Questi tag di sessione consentono di utilizzare Attribute Based Access Control (ABAC) per concedere l'accesso alle risorse AWS solo a specifici account di servizio Kubernetes. Nel fare ciò, è molto importante capire che gli account dei servizi Kubernetes sono unici solo all'interno di uno spazio dei nomi e gli spazi dei nomi Kubernetes sono unici solo all'interno di un cluster EKS. È possibile accedere a questi tag di sessione nelle politiche AWS utilizzando la chiave aws:PrincipalTag/<tag-key>
global condition, ad esempio aws:PrincipalTag/eks-cluster-arn
Ad esempio, se desideri concedere l'accesso solo a un account di servizio specifico per accedere a una risorsa AWS nel tuo account con una IAM o una policy delle risorse, dovresti controllare eks-cluster-arn
e kubernetes-namespace
kubernetes-service-account
etichettare e assicurarti che solo gli account di servizio del cluster previsto abbiano accesso a quella risorsa, come altri cluster potrebbero avere lo stesso kubernetes-service-accounts
ekubernetes-namespaces
.
Questo esempio di policy S3 Bucket concede l'accesso agli oggetti nel bucket S3 a cui è collegato, solo se eks-cluster-arn
tutti soddisfano i valori previsti kubernetes-service-account
kubernetes-namespace
, dove il cluster EKS è ospitato nell'account AWS. 111122223333
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::ExampleBucket/*" ], "Condition": { "StringEquals": { "aws:PrincipalTag/kubernetes-service-account": "s3objectservice", "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-west-2:111122223333:cluster/ProductionCluster", "aws:PrincipalTag/kubernetes-namespace": "s3datanamespace" } } } ] }
EKS Pod Identities rispetto a IRSA
Sia EKS Pod Identities che IRSA sono metodi preferiti per fornire credenziali AWS temporanee ai tuoi pod EKS. A meno che non abbiate casi d'uso specifici per IRSA, vi consigliamo di utilizzare EKS Pod Identities quando utilizzate EKS. Questa tabella consente di confrontare le due funzionalità.
# | EKS Pod Identity | IRSA |
---|---|---|
Richiede l'autorizzazione per creare un IDP OIDC nei tuoi account AWS? |
No |
Sì |
Richiede una configurazione IDP unica per cluster |
No |
Sì |
Imposta i tag di sessione pertinenti da utilizzare con ABAC |
Sì |
No |
Richiede un iam: PassRole Check? |
Sì |
No |
Utilizza AWS STS Quota dal tuo account AWS? |
No |
Sì |
Può accedere ad altri account AWS |
Indirettamente con il concatenamento dei ruoli |
Direttamente con sts: AssumeRoleWithWebIdentity |
Compatibile con AWS SDKs |
Sì |
Sì |
Richiede Pod Identity Agent Daemonset sui nodi? |
Sì |
No |
Identità e credenziali per i pod EKS: raccomandazioni
Aggiorna il daemonset aws-node per utilizzare IRSA
Al momento, il daemonset aws-node è configurato per utilizzare un ruolo assegnato alle istanze da assegnare ai pod. EC2 IPs Questo ruolo include diverse policy gestite da AWS, ad esempio Amazoneks_CNI_Policy, che consentono efficacemente a tutti i pod in esecuzione su un nodo di indirizzare gli indirizzi IP o di EC2 ContainerRegistryReadOnly estrarre immagini da ECR. attach/detach ENIs assign/unassign Poiché ciò rappresenta un rischio per il cluster, si consiglia di aggiornare il daemset aws-node per utilizzare IRSA. Uno script per eseguire questa operazione è disponibile nell'archivio di questa guida.
Il daemonset aws-node supporta EKS Pod Identities nelle versioni v1.15.5 e successive.
Limita l'accesso al profilo dell'istanza assegnato al nodo di lavoro
Quando utilizzi IRSA o EKS Pod Identities, aggiorna la catena di credenziali del pod in modo da utilizzare prima le identità IRSA o EKS Pod, tuttavia, il pod può comunque ereditare i diritti del profilo di istanza assegnato al nodo di lavoro. Per i pod che non richiedono queste autorizzazioni, puoi bloccare l'accesso ai metadati dell'istanza per garantire che le applicazioni dispongano solo delle autorizzazioni necessarie e non dei relativi nodi.
avvertimento
Il blocco dell'accesso ai metadati dell'istanza impedirà ai pod che non utilizzano IRSA o EKS Pod Identities di ereditare il ruolo assegnato al nodo di lavoro.
È possibile bloccare l'accesso ai metadati dell'istanza richiedendo che l'istanza utilizzi IMDSv2 solo l'istanza e aggiornando il conteggio degli hop a 1, come nell'esempio seguente. Puoi anche includere queste impostazioni nel modello di avvio del gruppo di nodi. Non disabilitate i metadati dell'istanza poiché ciò impedirà il corretto funzionamento di componenti come il gestore di terminazione dei nodi e altri elementi che si basano sui metadati dell'istanza.
$ aws ec2 modify-instance-metadata-options --instance-id <value> --http-tokens required --http-put-response-hop-limit 1 ...
Se utilizzi Terraform per creare modelli di avvio da utilizzare con Managed Node Groups, aggiungi il blocco di metadati per configurare il conteggio degli hop come mostrato in questo frammento di codice:
tf hl_lines="7" resource "aws_launch_template" "foo" { name = "foo" … metadata_options { http_endpoint = "enabled" http_tokens = "required" http_put_response_hop_limit = 1 instance_metadata_tags = "enabled" } …
Puoi anche bloccare l'accesso di un pod ai EC2 metadati manipolando iptables sul nodo. Per ulteriori informazioni su questo metodo, consulta Limitazione dell'accesso al servizio di metadati dell'istanza.
Se hai un'applicazione che utilizza una versione precedente dell'SDK AWS che non supporta IRSA o EKS Pod Identities, devi aggiornare la versione SDK.
Ambita la policy di fiducia di IAM Role per IRSA Roles in base al nome dell'account di servizio, allo spazio dei nomi e al cluster
La policy di fiducia può essere estesa a un Namespace o a un account di servizio specifico all'interno di un Namespace. Quando si utilizza IRSA, è meglio rendere la policy di fiducia del ruolo il più esplicita possibile includendo il nome dell'account del servizio. Ciò impedirà efficacemente che altri Pod all'interno dello stesso Namespace assumano il ruolo. La CLI lo eksctl
farà automaticamente quando la utilizzerai per creare ruoli di servizio accounts/IAM . Vedi https://eksctl. io/usage/iamserviceaccounts
Quando si lavora direttamente con IAM, si aggiunge una condizione alla politica di fiducia del ruolo, che utilizza condizioni per garantire che il :sub
claim corrisponda allo spazio dei nomi e all'account di servizio previsti. Ad esempio, prima avevamo un token IRSA con un'affermazione secondaria di «system:serviceaccount:default:s3-read-only». Questo è lo spazio s3-read-only
dei nomi e l'account del servizio è. default
Dovresti utilizzare una condizione come la seguente per assicurarti che solo il tuo account di servizio in un determinato namespace del tuo cluster possa assumere quel ruolo:
"Condition": { "StringEquals": { "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:aud": "sts.amazonaws.com", "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:sub": "system:serviceaccount:default:s3-read-only" } }
Utilizza un ruolo IAM per applicazione
Sia con IRSA che con EKS Pod Identity, è consigliabile assegnare a ciascuna applicazione il proprio ruolo IAM. Ciò offre un migliore isolamento in quanto è possibile modificare un'applicazione senza influire su un'altra e consente di applicare il principio del privilegio minimo concedendo a un'applicazione solo le autorizzazioni necessarie.
Quando si utilizza ABAC con EKS Pod Identity, è possibile utilizzare un ruolo IAM comune su più account di servizio e fare affidamento sui relativi attributi di sessione per il controllo degli accessi. Ciò è particolarmente utile quando si opera su larga scala, poiché ABAC consente di operare con un minor numero di ruoli IAM.
Quando l'applicazione necessita dell'accesso a IMDS, utilizza IMDSv2 e aumenta il limite di hop per le EC2 istanze a 2
IMDSv2richiede l'utilizzo di una richiesta PUT per ottenere un token di sessione. La richiesta PUT iniziale deve includere un TTL per il token di sessione. Le versioni più recenti di AWS SDKs gestiranno automaticamente questo e il rinnovo di detto token. È anche importante tenere presente che il limite di hop predefinito per EC2 le istanze è intenzionalmente impostato su 1 per impedire l'inoltro IP. Di conseguenza, i Pod che richiedono un token di sessione eseguito su EC2 istanze potrebbero alla fine scadere e tornare a utilizzare il flusso di dati. IMDSv1 EKS aggiunge il supporto IMDSv2 abilitando sia la v1 che la v2 e modificando il limite di hop a 2 sui nodi forniti da eksctl o con i modelli ufficiali. CloudFormation
Disattiva il montaggio automatico dei token degli account di servizio
Se la tua applicazione non ha bisogno di chiamare l'API Kubernetes, imposta l'automountServiceAccountToken
attributo su false
in PodSpec for your application o applica una patch all'account di servizio predefinito in ogni namespace in modo che non venga più montato automaticamente sui pod. Per esempio:
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
Utilizza account di servizio dedicati per ogni applicazione
Ogni applicazione deve avere un proprio account di servizio dedicato. Questo vale per gli account di servizio per l'API Kubernetes, nonché per IRSA ed EKS Pod Identity.
Importante
Se si utilizza un blue/green approccio agli aggiornamenti del cluster anziché eseguire un aggiornamento del cluster sul posto quando si utilizza IRSA, sarà necessario aggiornare la policy di fiducia di ciascuno dei ruoli IRSA IAM con l'endpoint OIDC del nuovo cluster. Un aggiornamento del blue/green cluster consiste nella creazione di un cluster che esegue una versione più recente di Kubernetes insieme al vecchio cluster e nell'utilizzo di un sistema di bilanciamento del carico o di una service mesh per spostare senza problemi il traffico dai servizi in esecuzione sul vecchio cluster al nuovo cluster. Quando si utilizzano gli aggiornamenti blue/green del cluster con EKS Pod Identity, è necessario creare associazioni di identità dei pod tra i ruoli IAM e gli account di servizio nel nuovo cluster. E aggiorna la policy di fiducia dei ruoli IAM se hai una sourceArn
condizione.
Esegui l'applicazione come utente non root
Per impostazione predefinita, i contenitori vengono eseguiti come root. Sebbene ciò consenta loro di leggere il file del token di identità Web, l'esecuzione di un contenitore come root non è considerata una buona pratica. In alternativa, valuta la possibilità di aggiungere l'spec.securityContext.runAsUser
attributo a PodSpec. Il valore di runAsUser
è un valore arbitrario.
Nell'esempio seguente, tutti i processi all'interno del Pod verranno eseguiti con l'ID utente specificato nel runAsUser
campo.
apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 runAsGroup: 3000 containers: - name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ]
Quando si esegue un contenitore come utente non root, si impedisce al contenitore di leggere il token dell'account del servizio IRSA perché al token vengono assegnate le autorizzazioni 0600 [root] per impostazione predefinita. Se aggiorni SecurityContext per il tuo contenitore in modo da includere fsgroup=65534 [Nobody], consentirà al contenitore di leggere il token.
spec: securityContext: fsGroup: 65534
In Kubernetes 1.19 e versioni successive, questa modifica non è più necessaria e le applicazioni possono leggere il token dell'account del servizio IRSA senza aggiungerle al gruppo Nobody.
Concedi l'accesso meno privilegiato alle applicazioni
Action Hero
Valuta la possibilità di impostare un limite di autorizzazioni per i ruoli IAM utilizzati con IRSA e Pod Identities. Puoi utilizzare il limite delle autorizzazioni per garantire che i ruoli utilizzati da IRSA o Pod Identities non possano superare il livello massimo di autorizzazioni. Per una guida di esempio su come iniziare con i limiti delle autorizzazioni con un esempio di politica sui limiti delle autorizzazioni, consulta questo repository su github.
Rivedi e revoca l'accesso anonimo non necessario al tuo cluster EKS
Idealmente, l'accesso anonimo dovrebbe essere disabilitato per tutte le azioni API. L'accesso anonimo viene concesso creando un RoleBinding or ClusterRoleBinding per il sistema utente integrato di Kubernetes: anonymous. Puoi utilizzare lo strumento rbac-lookup
./rbac-lookup | grep -P 'system:(anonymous)|(unauthenticated)' system:anonymous cluster-wide ClusterRole/system:discovery system:unauthenticated cluster-wide ClusterRole/system:discovery system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer
Qualsiasi ruolo o ClusterRole diverso da system: non public-info-viewer deve essere associato a system:anonymous user o system:unauthenticated group.
Potrebbero esserci alcuni motivi legittimi per abilitare l'accesso anonimo a determinati utenti. APIs Se questo è il caso del tuo cluster, assicurati che solo quelli specifici APIs siano accessibili agli utenti anonimi e l'esposizione di quelli APIs senza autenticazione non rende il cluster vulnerabile.
Prima della Kubernetes/EKS versione 1.14, system:unauthenticated group era associato a system:discovery e system:basic-user per impostazione predefinita. ClusterRoles Tieni presente che anche se hai aggiornato il cluster alla versione 1.14 o successiva, queste autorizzazioni potrebbero essere ancora abilitate sul cluster, poiché gli aggiornamenti del cluster non revocano queste autorizzazioni. Per verificare quali ClusterRoles hanno «system:unauthenticated» tranne system: public-info-viewer puoi eseguire il seguente comando (richiede jq util):
kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | .metadata.name'
E «system:unauthenticated» può essere rimosso da tutti i ruoli tranne «system:" usando: public-info-viewer
kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | del(.subjects[] | select(.name =="system:unauthenticated"))' | kubectl apply -f -
In alternativa, puoi controllarlo e rimuoverlo manualmente con kubectl describe e kubectl edit. Per verificare se system:unauthenticated group ha i permessi system:discovery sul tuo cluster, esegui il seguente comando:
kubectl describe clusterrolebindings system:discovery Name: system:discovery Labels: kubernetes.io/bootstrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true Role: Kind: ClusterRole Name: system:discovery Subjects: Kind Name Namespace ---- ---- --------- Group system:authenticated Group system:unauthenticated
Per verificare se system:unauthenticated group dispone dell'autorizzazione system:basic-user sul tuo cluster, esegui il seguente comando:
kubectl describe clusterrolebindings system:basic-user Name: system:basic-user Labels: kubernetes.io/bootstrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true Role: Kind: ClusterRole Name: system:basic-user Subjects: Kind Name Namespace ---- ---- --------- Group system:authenticated Group system:unauthenticated
Se system:unauthenticated group è associato a system:discovery e/o system:basic-user sul tuo cluster, dovresti dissociare questi ruoli dal gruppo system:unauthenticated. ClusterRoles Modifica ClusterRoleBinding system:discovery usando il seguente comando:
kubectl edit clusterrolebindings system:discovery
Il comando precedente aprirà la definizione corrente di system:discovery ClusterRoleBinding in un editor come mostrato di seguito:
# Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: "2021-06-17T20:50:49Z" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:discovery resourceVersion: "24502985" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery uid: b7936268-5043-431a-a0e1-171a423abeb6 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:discovery subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated - apiGroup: rbac.authorization.k8s.io kind: Group name: system:unauthenticated
Eliminate la voce relativa al gruppo system:unauthenticated dalla sezione «topics» nella schermata precedente dell'editor.
Ripeti gli stessi passaggi per system:basic-user. ClusterRoleBinding
Riutilizza le sessioni SDK AWS con IRSA
Quando usi IRSA, le applicazioni scritte con l'SDK AWS utilizzano il token distribuito ai tuoi pod per effettuare chiamate sts:AssumeRoleWithWebIdentity
per generare credenziali AWS temporanee. Questo è diverso dagli altri servizi di calcolo AWS, in cui il servizio di elaborazione fornisce credenziali AWS temporanee direttamente alla risorsa di calcolo AWS, come una funzione lambda. Ciò significa che ogni volta che viene inizializzata una sessione SDK AWS, viene effettuata una chiamata ad AWS AssumeRoleWithWebIdentity
STS for. Se la tua applicazione si ridimensiona rapidamente e inizializza molte sessioni SDK AWS, potresti riscontrare una limitazione da parte di AWS STS poiché il tuo codice effettuerà molte chiamate. AssumeRoleWithWebIdentity
Per evitare questo scenario, consigliamo di riutilizzare le sessioni SDK AWS all'interno dell'applicazione in modo da non effettuare chiamate non AssumeRoleWithWebIdentity
necessarie.
Nel codice di esempio seguente, viene creata una sessione utilizzando l'SDK python boto3 e quella stessa sessione viene utilizzata per creare client e interagire con Amazon S3 e Amazon SQS. AssumeRoleWithWebIdentity
viene chiamato solo una volta e l'SDK AWS aggiornerà automaticamente le credenziali my_session
quando scadono.
import boto3 = Create your own session my_session = boto3.session.Session() = Now we can create low-level clients from our session sqs = my_session.client('`sqs`') s3 = my_session.client('`s3`') s3response = s3.list_buckets() sqsresponse = sqs.list_queues() #print the response from the S3 and SQS APIs print("`s3 response:`") print(s3response) print("`—`") print("`sqs response:`") print(sqsresponse) ```
Se stai migrando un'applicazione da un altro servizio di elaborazione AWS, ad esempio a EKS EC2 con IRSA, questo è un dettaglio particolarmente importante. Su altri servizi di elaborazione, l'inizializzazione di una sessione SDK AWS non richiama AWS STS a meno che tu non lo richieda.
Approcci alternativi
Sebbene le identità dei pod IRSA e EKS siano i metodi preferiti per assegnare un'identità AWS a un pod, richiedono l'inclusione di una versione recente di AWS SDKs nell'applicazione. Per un elenco completo di quelle SDKs che attualmente supportano IRSA, consulta https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -minimum-sdk.html, per EKS Pod Identities, consulta - .html. https://docs.aws.amazon.com/eks/ latest/userguide/pod id-minimum-sdk Se disponi di un'applicazione che non puoi aggiornare immediatamente con un SDK compatibile, sono disponibili diverse soluzioni create dalla community per assegnare ruoli IAM ai pod Kubernetes, tra cui kube2iam e kiam.
Se hai bisogno di utilizzare una di queste soluzioni non fornite da AWS, esercita la dovuta diligenza e assicurati di comprendere le implicazioni di sicurezza che ciò comporta.
Strumenti e risorse
-
Workshop di immersione nella sicurezza di Amazon EKS - Identity and Access Management
-
Modello Terraform EKS Blueprints - Cluster Amazon EKS completamente privato
-
Modello di progetti Terraform EKS - Single Sign-On di IAM Identity Center per Amazon EKS Cluster
-
Modello Terraform EKS Blueprints - Okta Single Sign-On per Amazon EKS Cluster
-
rbac.dev
Un elenco di risorse aggiuntive, inclusi blog e strumenti, per Kubernetes RBAC