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 degli account di servizio e, dal 21 febbraio 2021, l'autenticazione OIDC.

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-authenticatorclient quando esegui i comandi. kubectl 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:

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:

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.

$ 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-authConfigMap.

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.

È anche possibile mappare le autorizzazioni per gli utenti di AWS IAM, definendo un nuovo blocco di configurazione permapUsers, data in the aws-authConfigMap, 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 maggiori dettagli.

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:

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-adminautorizzazione 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-adminautorizzazione.

$ 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.

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 per generare automaticamente ruoli e associazioni in base alle chiamate API osservate nel Kubernetes Audit Log.

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-canrbac-lookup per esaminare i ruoli associati a un particolare account, utente o gruppo di servizio. Esploreremo ulteriormente questo argomento quando arriveremo alla sezione sull'auditing. Altre idee sono disponibili in questo articolo di NCC Group.

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 eksctldocumenti

aws-auth di keikoproj

aws-authby 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 per kubectl.

$ kubectl krew install aws-auth
...
$ kubectl aws-auth
...

Consulta i documenti aws-auth su GitHub per ulteriori informazioni, inclusa la libreria go.

CLI AWS IAM Authenticator

Il aws-iam-authenticator progetto include una CLI per l'aggiornamento di. ConfigMap

Scarica una versione su. GitHub

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. I post relativi a due di queste soluzioni sono stati pubblicati sul blog Open Source di AWS:

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 deve essere in grado di elencare gli endpoint di un servizio. Il controller deve inoltre essere in grado di richiamare AWS per APIs effettuare il provisioning e configurare un ALB. In questa sezione esploreremo le migliori pratiche per l'assegnazione di diritti e privilegi ai Pods.

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

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. Quando i Pod sono configurati con un account di servizio che fa riferimento a un ruolo IAM, il server API Kubernetes chiamerà l'endpoint di rilevamento OIDC pubblico per il cluster all'avvio. L'endpoint firma crittograficamente il token OIDC emesso da Kubernetes e il token risultante montato come volume. Questo token firmato consente al Pod di chiamare il ruolo IAM APIs associato ad AWS. Quando viene richiamata un'API AWS, AWS SDKs chiamasts: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

{
  "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:

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-accountkubernetes-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à.

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.

È 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/per ulteriori informazioni.

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'automountServiceAccountTokenattributo 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.

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.runAsUserattributo 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 è un'utilità che puoi eseguire insieme all'applicazione per identificare le chiamate API AWS e le autorizzazioni IAM corrispondenti di cui l'applicazione ha bisogno per funzionare correttamente. È simile a IAM Access Advisor in quanto consente di limitare gradualmente l'ambito dei ruoli IAM assegnati alle applicazioni. Consulta la documentazione sulla concessione dell'accesso con privilegi minimi alle risorse AWS per ulteriori informazioni.

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 per identificare le autorizzazioni che system:anonymous user ha sul tuo cluster:

./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. AssumeRoleWithWebIdentityviene 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. Sebbene AWS non approvi, approvi o supporti l'uso di queste soluzioni, esse vengono spesso utilizzate dalla comunità in generale per ottenere risultati simili a quelli di IRSA ed EKS Pod Identities.

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