Contribuisci 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 del problema “confused deputy” tra servizi in Amazon EKS

Con “confused deputy” si intende un problema di sicurezza in cui un’entità che non dispone dell’autorizzazione per eseguire una certa operazione può costringere un’entità con più privilegi a eseguire tale operazione. Nel AWS, l'impersonificazione tra servizi può portare al confuso problema del vice. La rappresentazione tra servizi può verificarsi quando un servizio (il servizio chiamante) effettua una chiamata a un altro servizio (il servizio chiamato). Il servizio chiamante può essere manipolato per utilizzare le proprie autorizzazioni e agire sulle risorse di un altro cliente, a cui normalmente non avrebbe 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 chiavi di contesto delle condizioni globali aws:SourceArn e aws:SourceAccount nelle policy delle risorse per limitare le autorizzazioni con cui Amazon Elastic Kubernetes Service (Amazon EKS) fornisce 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:SourceArn con l’ARN completo della risorsa. Se l’ARN completo della risorsa non è noto o si scelgono più risorse, utilizzare la chiave di contesto della condizione globale aws:SourceArn 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 del problema “confused deputy” tra servizi nei cluster Amazon EKS

Ѐ 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 provider cloud legacy utilizza questo ruolo per creare bilanciatori del carico con Elastic Load Balancing per i servizi. Queste operazioni del cluster possono influire solo sullo stesso account, quindi 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 dell’ARN dell’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 policy di attendibilità per i ruoli del cluster EKS

L’esempio seguente mostra il modo in cui è possibile utilizzare le chiavi di contesto aws:SourceArn e aws:SourceAccount delle condizioni globali in Amazon EKS per prevenire il problema “confused deputy”.

{
  "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"
        }
      }
    }
  ]
}