Aiutaci a migliorare questa pagina

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

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

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

Prevenzione della confusione tra diversi servizi in Amazon EKS

Il problema della confusione secondaria è un problema di sicurezza in cui un'entità che non dispone dell'autorizzazione per eseguire un'azione può costringere un'entità con maggiori privilegi a eseguire l'azione. In effetti AWS, l'impersonificazione tra diversi servizi può portare alla confusione del vicesceriffo. La rappresentazione tra servizi può verificarsi quando un servizio (il servizio chiamante) effettua una chiamata a un altro servizio (il servizio chiamato). Il servizio di chiamata può essere manipolato in modo da utilizzare le sue autorizzazioni per agire sulle risorse di un altro cliente in un modo a cui altrimenti non dovrebbe avere l'autorizzazione di accesso. Per evitare che ciò accada, AWS mette a disposizione strumenti che consentono di proteggere i dati relativi a tutti i servizi con responsabili del servizio a cui è stato concesso l'accesso alle risorse del vostro account.

Consigliamo di utilizzare le aws:SourceArnchiavi di contesto della condizione aws:SourceAccountglobale nelle politiche delle risorse per limitare le autorizzazioni che Amazon Elastic Kubernetes Service (Amazon EKS) fornisce a un altro servizio alla risorsa.

Il modo più efficace per proteggersi dal problema "confused deputy" è quello di usare la chiave di contesto della condizione globale aws:SourceArncon l'ARN completo della risorsa. Se non conosci l'ARN completo della risorsa o se stai specificando più risorse, usa la chiave di condizione di contesto aws:SourceArn globale con caratteri jolly (*) per le parti sconosciute dell'ARN. Ad esempio, arn:aws:<servicename>:*:<123456789012>:*.

Se il valore aws:SourceArn non contiene l'ID account, ad esempio un ARN di un bucket Amazon S3, è necessario utilizzare sia aws:SourceAccount che aws:SourceArn per limitare le autorizzazioni.

Prevenzione alternativa confusa del ruolo del cluster Amazon EKS tra diversi servizi

È richiesto un ruolo IAM del cluster Amazon EKS per ogni cluster. I cluster Kubernetes gestiti da Amazon EKS utilizzano questo ruolo per gestire i nodi e il Cloud Provider legacy utilizza questo ruolo per creare bilanciatori di carico con Elastic Load Balancing for services. Queste azioni del cluster possono influire solo sullo stesso account, quindi ti consigliamo di limitare ogni ruolo del cluster a quel cluster e a quell'account. Questa è un'applicazione specifica della AWS raccomandazione di seguire il principio del privilegio minimo nel proprio account.

Formato ARN di origine

Il valore di aws:SourceArn deve essere l'ARN di un cluster EKS nel formato. arn:aws: eks:region:account:cluster/cluster-name Ad esempio, arn:aws: eks:us-west-2:123456789012:cluster/my-cluster.

Formato della politica di fiducia per i ruoli del cluster EKS

L'esempio seguente mostra come utilizzare le chiavi di contesto aws:SourceArn e aws:SourceAccount global condition in Amazon EKS per prevenire il problema del confuso vice.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
          },
        "StringEquals": {
            "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}