Strategia multi-account

AWS consiglia di utilizzare una strategia con più account e organizzazioni AWS per isolare e gestire applicazioni e dati aziendali. L'utilizzo di una strategia con più account offre molti vantaggi:

• Quote di servizi API AWS aumentate. Le quote vengono applicate agli account AWS e l'utilizzo di più account per i carichi di lavoro aumenta la quota complessiva disponibile per i carichi di lavoro.

• Policy di Identity and Access Management (IAM) più semplici. Concedere ai carichi di lavoro e agli operatori che li supportano l'accesso solo ai propri account AWS significa meno tempo per la creazione di policy IAM granulari per raggiungere il principio del privilegio minimo.

• Isolamento migliorato delle risorse AWS. In base alla progettazione, tutte le risorse fornite all'interno di un account sono logicamente isolate dalle risorse fornite in altri account. Questo limite di isolamento consente di limitare i rischi di problemi relativi all'applicazione, di errori di configurazione o di azioni dannose. Se si verifica un problema all'interno di un account, è possibile ridurre o eliminare l'impatto sui carichi di lavoro contenuti in altri account.

• Altri vantaggi, come descritto nel white paper AWS Multi Account Strategy

Le seguenti sezioni spiegheranno come implementare una strategia multiaccount per i carichi di lavoro EKS utilizzando un approccio di cluster EKS centralizzato o decentralizzato.

Pianificazione di una strategia di account con più carichi di lavoro per cluster multi-tenant

In una strategia AWS con più account, le risorse che appartengono a un determinato carico di lavoro come bucket S3, cluster ElastiCache e tabelle DynamoDB vengono tutte create in un account AWS che contiene tutte le risorse per quel carico di lavoro. Questi vengono definiti account di carico di lavoro e il cluster EKS viene distribuito in un account denominato account cluster. Gli account del cluster verranno esaminati nella prossima sezione. La distribuzione delle risorse in un account di carico di lavoro dedicato è simile alla distribuzione delle risorse Kubernetes in un namespace dedicato.

Gli account del carico di lavoro possono quindi essere ulteriormente suddivisi per ciclo di vita di sviluppo del software o per altri requisiti, se necessario. Ad esempio, un determinato carico di lavoro può avere un account di produzione, un account di sviluppo o account per ospitare istanze di quel carico di lavoro in una regione specifica. Ulteriori informazioni sono disponibili in questo white paper di AWS.

È possibile adottare i seguenti approcci quando si implementa la strategia EKS per più account:

Cluster EKS centralizzato

In questo approccio, il cluster EKS verrà distribuito in un unico account AWS chiamato. Cluster Account Utilizzando i ruoli IAM for Service Accounts (IRSA) o EKS Pod Identities per fornire credenziali AWS temporanee e AWS Resource Access Manager (RAM) per semplificare l'accesso alla rete, puoi adottare una strategia multi-account per il tuo cluster EKS multi-tenant. L'account del cluster conterrà il VPC, le sottoreti, il cluster EKS, le risorse di calcolo EC2 /Fargate (nodi di lavoro) e tutte le configurazioni di rete aggiuntive necessarie per eseguire il cluster EKS.

In una strategia di account con più carichi di lavoro per cluster multi-tenant, gli account AWS in genere si allineano ai namespace Kubernetes come meccanismo per isolare i gruppi di risorse. Le migliori pratiche per l'isolamento dei tenant all'interno di un cluster EKS devono comunque essere seguite quando si implementa una strategia multi-account per cluster EKS multi-tenant.

È possibile averne più di uno Cluster Accounts nella propria organizzazione AWS ed è consigliabile averne più di uno in linea con le Cluster Accounts esigenze del ciclo di vita dello sviluppo del software. Per carichi di lavoro che operano su larga scala, potresti averne bisogno di più Cluster Accounts per garantire che ci siano abbastanza quote di servizio Kubernetes e AWS disponibili per tutti i tuoi carichi di lavoro.

|Nel diagramma precedente, la RAM AWS viene utilizzata per condividere sottoreti da un account cluster a un account di carico di lavoro. Quindi i carichi di lavoro in esecuzione nei pod EKS utilizzano IRSA o EKS Pod Identities e il concatenamento dei ruoli per assumere un ruolo nel proprio account di carico di lavoro e accedere alle proprie risorse AWS.

Implementazione di una strategia di account con carichi di lavoro multipli per cluster multi-tenant

Condivisione di sottoreti con AWS Resource Access Manager

AWS Resource Access Manager (RAM) consente di condividere risorse tra account AWS.

Se la RAM è abilitata per la tua AWS Organization, puoi condividere le sottoreti VPC dall'account Cluster ai tuoi account di carico di lavoro. Ciò consentirà alle risorse AWS di proprietà dei tuoi account di carico di lavoro, come i database Amazon ElastiCache Clusters o Amazon Relational Database Service (RDS), di essere distribuite nello stesso VPC del cluster EKS e di essere consumabili dai carichi di lavoro in esecuzione sul tuo cluster EKS.

Per condividere una risorsa tramite RAM, apri la RAM nella console AWS dell'account del cluster e seleziona «Resource Shares» e «Create Resource Share». Assegna un nome a Resource Share e seleziona le sottoreti che desideri condividere. Seleziona nuovamente Avanti e inserisci l'account a 12 cifre IDs per gli account di carico di lavoro con cui desideri condividere le sottoreti, seleziona nuovamente Avanti e fai clic su Crea condivisione di risorse per terminare. Dopo questo passaggio, l'account del carico di lavoro può distribuire risorse in tali sottoreti.

Le condivisioni RAM possono anche essere create a livello di codice o utilizzando l'infrastruttura come codice.

Scelta tra EKS Pod Identities e IRSA

Al re:Invent 2023, AWS ha lanciato EKS Pod Identities come un modo più semplice per fornire credenziali AWS temporanee ai tuoi pod su EKS. Sia IRSA che EKS Pod Identities sono metodi validi per fornire credenziali AWS temporanee ai tuoi pod EKS e continueranno a essere supportate. Dovresti considerare quale metodo di distribuzione soddisfa meglio le tue esigenze.

Quando si lavora con un cluster EKS e più account AWS, IRSA può assumere direttamente ruoli in account AWS diversi dall'account in cui è ospitato direttamente il cluster EKS, mentre le identità EKS Pod richiedono la configurazione del concatenamento dei ruoli. Consulta la documentazione EKS per un confronto approfondito.

Accesso alle risorse API AWS con IAM Roles For Service Accounts

IAM Roles for Service Accounts (IRSA) ti consente di fornire credenziali AWS temporanee ai tuoi carichi di lavoro in esecuzione su EKS. IRSA può essere utilizzato per ottenere credenziali temporanee per i ruoli IAM negli account del carico di lavoro dall'account del cluster. Ciò consente ai carichi di lavoro in esecuzione sui cluster EKS nell'account cluster di consumare senza problemi le risorse dell'API AWS, come i bucket S3 ospitati nell'account del carico di lavoro, e di utilizzare l'autenticazione IAM per risorse come Amazon RDS Databases o Amazon EFS. FileSystems

È possibile accedere alle risorse API AWS e ad altre risorse che utilizzano l'autenticazione IAM in un account di carico di lavoro solo tramite credenziali per i ruoli IAM nello stesso account di carico di lavoro, tranne nei casi in cui l'accesso tra account è possibile ed è stato abilitato esplicitamente.

Abilitazione di IRSA per l'accesso a più account

Per consentire a IRSA per i carichi di lavoro nel tuo account cluster di accedere alle risorse nei tuoi account di carico di lavoro, devi prima creare un provider di identità IAM OIDC nel tuo account di carico di lavoro. Questa operazione può essere eseguita con la stessa procedura per la configurazione di IRSA, ad eccezione del fatto che l'Identity Provider verrà creato nell'account del carico di lavoro.

Quindi, quando configuri IRSA per i tuoi carichi di lavoro su EKS, puoi seguire gli stessi passaggi della documentazione, ma utilizzare l'ID account a 12 cifre dell'account di carico di lavoro, come indicato nella sezione «Esempio: creare un provider di identità dal cluster di un altro account».

Una volta configurato, l'applicazione in esecuzione in EKS sarà in grado di utilizzare direttamente il proprio account di servizio per assumere un ruolo nell'account del carico di lavoro e utilizzare le risorse al suo interno.

Accesso alle risorse API AWS con le identità dei pod EKS

EKS Pod Identities è un nuovo modo di fornire credenziali AWS ai carichi di lavoro in esecuzione su EKS. Le identità dei pod EKS semplificano la configurazione delle risorse AWS in quanto non è più necessario gestire le configurazioni OIDC per fornire le credenziali AWS ai pod su EKS.

Abilitazione di EKS Pod Identities per l'accesso da più account

A differenza di IRSA, EKS Pod Identities può essere utilizzato solo per concedere l'accesso diretto a un ruolo nello stesso account del cluster EKS. Per accedere a un ruolo in un altro account AWS, i pod che utilizzano EKS Pod Identities devono eseguire il Role Chaining.

Il concatenamento dei ruoli può essere configurato in un profilo di applicazione con il relativo file di configurazione aws utilizzando il Process Credentials Provider disponibile in vari AWS. SDKs credential_processpuò essere utilizzato come fonte di credenziali durante la configurazione di un profilo, ad esempio:

# Content of the AWS Config file
[profile account_b_role]
source_profile = account_a_role
role_arn = arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
credential_process = /eks-credential-processrole.sh

L'origine dello script chiamato da credential_process:

#!/bin/bash
# Content of the eks-credential-processrole.sh
# This will retreive the credential from the pod identities agent,
# and return it to the AWS SDK when referenced in a profile
curl -H "Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)" $AWS_CONTAINER_CREDENTIALS_FULL_URI | jq -c '{AccessKeyId: .AccessKeyId, SecretAccessKey: .SecretAccessKey, SessionToken: .Token, Expiration: .Expiration, Version: 1}'

Puoi creare un file di configurazione aws come mostrato sopra con entrambi i ruoli Account A e B e specificare le variabili AWS_CONFIG_FILE e AWS_PROFILE env nelle specifiche del tuo pod. Il webhook EKS Pod identity non ha la precedenza se le variabili env esistono già nelle specifiche del pod.

# Snippet of the PodSpec
containers:
  - name: container-name
    image: container-image:version
    env:
    - name: AWS_CONFIG_FILE
      value: path-to-customer-provided-aws-config-file
    - name: AWS_PROFILE
      value: account_b_role

Quando si configurano le politiche di trust dei ruoli per il concatenamento dei ruoli con le identità dei pod EKS, è possibile fare riferimento agli attributi specifici EKS come tag di sessione e utilizzare il controllo degli accessi basato sugli attributi (ABAC) per limitare l'accesso ai ruoli IAM solo a sessioni di identità EKS Pod specifiche, come l'account di servizio Kubernetes a cui appartiene un pod.

Tieni presente che alcuni di questi attributi potrebbero non essere universalmente univoci, ad esempio due cluster EKS possono avere namespace identici e un cluster può avere account di servizio con nomi identici in tutti i namespace. Pertanto, quando si concede l'accesso tramite EKS Pod Identities e ABAC, è consigliabile considerare sempre l'arn e lo spazio dei nomi del cluster quando si concede l'accesso a un account di servizio.

ABAC ed EKS Pod Identities per l'accesso su più account

Quando utilizzi EKS Pod Identities per assumere ruoli (concatenamento di ruoli) in altri account nell'ambito di una strategia multiaccount, hai la possibilità di assegnare un ruolo IAM unico per ogni account di servizio che deve accedere a un altro account, oppure utilizzare un ruolo IAM comune su più account di servizio e utilizzare ABAC per controllare a quali account può accedere.

Per utilizzare ABAC per controllare quali account di servizio possono assumere un ruolo in un altro account con il concatenamento dei ruoli, si crea una dichiarazione sulla politica di fiducia dei ruoli che consente l'assunzione di un ruolo da parte di una sessione di ruolo solo quando sono presenti i valori previsti. La seguente politica di fiducia dei ruoli consentirà a un ruolo dell'account del cluster EKS (ID account 111122223333) di assumere un ruolo solo se i kubernetes-namespace tag eks-cluster-arn e i tag hanno tutti il kubernetes-service-account valore previsto.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "PayrollApplication",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

Quando si utilizza questa strategia, è consigliabile garantire che il ruolo IAM comune disponga solo di sts:AssumeRole autorizzazioni e nessun altro accesso AWS.

Quando si utilizza ABAC, è importante controllare chi ha la possibilità di etichettare i ruoli e gli utenti IAM solo a coloro che ne hanno la stretta necessità. Qualcuno con la capacità di taggare un ruolo o un utente IAM sarebbe in grado di impostare tag roles/users identici a quelli impostati da EKS Pod Identities e potrebbe essere in grado di aumentare i propri privilegi. Puoi limitare chi ha l'accesso per impostare i tag e i tag sul ruolo kubernetes- e eks- sugli utenti IAM utilizzando la policy IAM o la Service Control Policy (SCP).

Cluster EKS decentralizzati

In questo approccio, i cluster EKS vengono distribuiti nei rispettivi account AWS per carichi di lavoro e convivono con altre risorse AWS come bucket Amazon S3 VPCs, tabelle Amazon DynamoDB, ecc. Ogni account di carico di lavoro è indipendente, autosufficiente e gestito dai rispettivi cluster di Unit/Application teams. This model allows the creation of reusuable blueprints for various cluster capabilities — AI/ML business, elaborazione in batch, scopi generali, ecc. e vende i cluster in base ai requisiti del team applicativo. Sia i team delle applicazioni che quelli della piattaforma operano dai rispettivi GitOpsrepository per gestire le implementazioni nei cluster di carichi di lavoro.

Nel diagramma precedente, i cluster Amazon EKS e altre risorse AWS vengono distribuiti nei rispettivi account di carico di lavoro. Quindi i carichi di lavoro in esecuzione nei pod EKS utilizzano IRSA o EKS Pod Identities per accedere alle proprie risorse AWS.

GitOps è un modo per gestire la distribuzione di applicazioni e infrastrutture in modo che l'intero sistema sia descritto in modo dichiarativo in un repository Git. È un modello operativo che offre la possibilità di gestire lo stato di più cluster Kubernetes utilizzando le migliori pratiche di controllo delle versioni, artefatti immutabili e automazione. In questo modello multicluster, ogni cluster di carico di lavoro viene avviato con più repository Git, che consentono a ciascun team (applicazione, piattaforma, sicurezza, ecc.) di implementare le rispettive modifiche sul cluster.

Utilizzerai i ruoli IAM for Service Accounts (IRSA) o EKS Pod Identities in ogni account per consentire ai tuoi carichi di lavoro EKS di ottenere credenziali aws temporanee per accedere in modo sicuro ad altre risorse AWS. I ruoli IAM vengono creati nei rispettivi account AWS per carichi di lavoro e li mappano agli account di servizio k8s per fornire un accesso IAM temporaneo. Pertanto, in questo approccio non è richiesto l'accesso a più account. Segui la documentazione sui ruoli IAM per gli account di servizio su come configurare ogni carico di lavoro per IRSA e la documentazione di EKS Pod Identities su come configurare le identità dei pod EKS in ogni account.

Rete centralizzata

Puoi anche utilizzare la RAM AWS per condividere le sottoreti VPC con gli account di carico di lavoro e avviare cluster Amazon EKS e altre risorse AWS al loro interno. Ciò consente la gestione/amministrazione centralizzata della rete, una connettività di rete semplificata e cluster EKS decentralizzati. Consulta questo blog di AWS per una guida dettagliata e considerazioni su questo approccio.

Nel diagramma precedente, la RAM AWS viene utilizzata per condividere sottoreti da un account di rete centrale a un account di carico di lavoro. Quindi il cluster EKS e altre risorse AWS vengono lanciati in quelle sottoreti nei rispettivi account di carico di lavoro. I pod EKS utilizzano IRSA o EKS Pod Identities per accedere alle proprie risorse AWS.

Cluster EKS centralizzati e non centralizzati

La decisione di utilizzare un sistema centralizzato o decentralizzato dipenderà dai requisiti dell'utente. Questa tabella illustra le principali differenze tra ciascuna strategia.

#	Cluster EKS centralizzato	Cluster EKS decentralizzati
Gestione dei cluster:	La gestione di un singolo cluster EKS è più semplice dell'amministrazione di più cluster	Un'automazione efficiente della gestione dei cluster è necessaria per ridurre il sovraccarico operativo legato alla gestione di più cluster EKS
Efficienza dei costi:	Consente il riutilizzo del cluster EKS e delle risorse di rete, promuovendo l'efficienza dei costi	Richiede configurazioni di rete e cluster per carico di lavoro, il che richiede risorse aggiuntive
Resilienza:	La compromissione di un cluster può influire su più carichi di lavoro sul cluster centralizzato	Se un cluster viene danneggiato, il danno è limitato ai soli carichi di lavoro in esecuzione su quel cluster. Tutti gli altri carichi di lavoro non sono interessati
Isolamento e sicurezza:	Isolation/Soft Multi-tenancy si ottiene utilizzando costrutti nativi di k8s come. Namespaces I carichi di lavoro possono condividere le risorse sottostanti come CPU, memoria, ecc. Le risorse AWS sono isolate nei propri account di carico di lavoro che per impostazione predefinita non sono accessibili da altri account AWS.	Maggiore isolamento delle risorse di elaborazione poiché i carichi di lavoro vengono eseguiti in singoli cluster e nodi che non condividono alcuna risorsa. Le risorse AWS sono isolate nei propri account di carico di lavoro che per impostazione predefinita non sono accessibili da altri account AWS.
Prestazioni e scalabità:	Man mano che i carichi di lavoro raggiungono dimensioni molto elevate, è possibile che nell'account del cluster si verifichino quote di servizio Kubernetes e AWS. Puoi implementare account cluster aggiuntivi per scalare ulteriormente	Man mano che VPCs sono presenti più cluster, ogni carico di lavoro ha una maggiore quota di servizi k8s e AWS disponibili
Rete:	Viene utilizzato un singolo VPC per cluster, che consente una connettività più semplice per le applicazioni su quel cluster	Il routing deve essere stabilito tra il cluster EKS decentralizzato VPCs
Gestione degli accessi Kubernetes:	È necessario mantenere molti ruoli e utenti diversi nel cluster per fornire l'accesso a tutti i team addetti ai carichi di lavoro e garantire che le risorse Kubernetes siano adeguatamente separate	Gestione semplificata degli accessi in quanto ogni cluster è dedicato a un carico di lavoro/team
Gestione degli accessi AWS:	Le risorse AWS vengono distribuite nel proprio account a cui è possibile accedere per impostazione predefinita solo con ruoli IAM nell'account del carico di lavoro. I ruoli IAM negli account di carico di lavoro si presuppongono su più account con IRSA o EKS Pod Identities.	Le risorse AWS vengono distribuite nel proprio account a cui è possibile accedere per impostazione predefinita solo con ruoli IAM nell'account del carico di lavoro. I ruoli IAM negli account di carico di lavoro vengono assegnati direttamente ai pod con IRSA o EKS Pod Identities