Associer les stratégies d'accès aux entrées d'accès et les dissocier des entrées d'accès - Amazon EKS

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Associer les stratégies d'accès aux entrées d'accès et les dissocier des entrées d'accès

Vous pouvez attribuer une ou plusieurs stratégies d'accès à des entrées d'accès de type STANDARD. Amazon EKS accorde automatiquement aux autres types d'entrées d'accès les autorisations nécessaires pour fonctionner correctement dans votre cluster. Les stratégies d'accès d'Amazon EKS incluent des autorisations Kubernetes, et non des autorisations IAM. Avant d'associer une stratégie d'accès à une entrée d'accès, assurez-vous que vous connaissez bien les autorisations Kubernetes incluses dans chaque stratégie d'accès. Pour plus d’informations, consultez Autorisations des stratégies d'accès. Si aucune des stratégies d'accès ne répond à vos exigences, n'associez aucune stratégie d'accès à une entrée d'accès. Spécifiez plutôt un ou plusieurs noms de groupe pour l'entrée d'accès et créez et gérez des objets de contrôle d'accès basés sur des rôles Kubernetes. Pour plus d’informations, consultez Création d'entrées d'accès.

Prérequis
  • Une entrée d'accès existante. Pour en créer un, consultez Création d'entrées d'accès.

  • Un AWS Identity and Access Management rôle ou un utilisateur disposant des autorisations suivantes : ListAccessEntriesDescribeAccessEntry,UpdateAccessEntry,ListAccessPolicies,AssociateAccessPolicy, etDisassociateAccessPolicy. Pour plus d'informations, consultez la rubrique Actions définies par Amazon Elastic Kubernetes Service dans la Référence des autorisations de service.

Avant d'associer des stratégies d'accès à des entrées d'accès, tenez compte des exigences suivantes :

  • Vous pouvez associer plusieurs stratégies d'accès à chaque entrée d'accès, mais vous ne pouvez associer chaque politique à une entrée d'accès qu'une seule fois. Si vous associez plusieurs stratégies d'accès, le principal IAM de l'entrée d'accès dispose de toutes les autorisations incluses dans toutes les stratégies d'accès associées.

  • Vous pouvez étendre une stratégie d'accès à toutes les ressources d'un cluster ou en spécifiant le nom d'un ou de plusieurs espaces de noms Kubernetes. Vous pouvez utiliser des caractères génériques pour le nom d'un espace de noms. Par exemple, si vous souhaitez étendre une stratégie d'accès à tous les espaces de noms commençant par dev-, vous pouvez spécifier dev-* sous forme de nom d'espace de noms. Assurez-vous que les espaces de noms existent sur votre cluster et que votre orthographe correspond au nom réel de l'espace de noms du cluster. Amazon EKS ne confirme ni l'orthographe ni l'existence des espaces de noms de votre cluster.

  • Vous pouvez modifier la portée d'accès d'une stratégie d'accès après l'avoir associée à une entrée d'accès. Si vous avez défini la stratégie d'accès aux espaces de noms Kubernetes, vous pouvez ajouter et supprimer des espaces de noms pour l'association, si nécessaire.

  • Si vous associez une stratégie d'accès à une entrée d'accès dont les noms de groupe sont également spécifiés, le principal IAM dispose alors de toutes les autorisations dans toutes les stratégies d'accès associées. Il dispose également de toutes les autorisations dans n'importe quel objet Kubernetes Role ou ClusterRole spécifié dans n'importe quels objets Kubernetes Role et RoleBinding qui spécifient les noms de groupes.

  • Si vous exécutez la commande kubectl auth can-i --list, vous ne verrez aucune autorisation Kubernetes attribuée par les stratégies d'accès associées à une entrée d'accès pour le principal IAM que vous utilisez lorsque vous exécutez la commande. La commande affiche les autorisations Kubernetes uniquement si vous les avez accordées dans les objets Kubernetes Role ou ClusterRole que vous avez liés aux noms de groupe ou au nom d'utilisateur que vous avez spécifiés pour une entrée d'accès.

  • Si vous vous faites passer pour un utilisateur ou un groupe Kubernetes lorsque vous interagissez avec des objets Kubernetes de votre cluster, par exemple en utilisant la commande kubectl avec --as username ou --as-group group-name, vous forcez l'utilisation de l'autorisation Kubernetes RBAC. Par conséquent, le principal IAM ne dispose d'aucune autorisation attribuée par les stratégies d'accès associées à l'entrée d'accès. Les seules autorisations Kubernetes dont dispose l'utilisateur ou le groupe, pour lequel le principal IAM se fait passer, sont les autorisations Kubernetes que vous lui avez accordées dans les objets Kubernetes Role ou ClusterRole que vous avez liés aux noms de groupe ou au nom d'utilisateur. Pour que votre principal IAM dispose des autorisations définies dans les stratégies d'accès associées, ne vous faites pas passer pour un utilisateur ou un groupe Kubernetes. Le principal IAM disposera également encore de toutes les autorisations que vous lui avez octroyées dans les objets Kubernetes Role ou ClusterRole que vous avez liés aux noms de groupe ou au nom d'utilisateur que vous avez spécifiés pour l'entrée d'accès. Pour plus d'informations, consultez Emprunt de l'identité de l'utilisateur dans la documentation Kubernetes.

Vous pouvez associer une politique d'accès à une entrée d'accès à l'aide du AWS Management Console ou du AWS CLI.

AWS Management Console
Pour associer une stratégie d'accès à une entrée d'accès à l'aide de la AWS Management Console
  1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home#/clusters.

  2. Choisissez le nom du cluster qui possède une entrée d'accès à laquelle associer une stratégie d'accès.

  3. Choisissez l'onglet Access.

  4. Si le type d'entrée d'accès est Standard, vous pouvez associer ou dissocier les stratégies d'accès Amazon EKS. Si le type de votre entrée d'accès est autre que Standard, cette option n'est pas disponible.

  5. Choisissez Associer la stratégie d'accès.

  6. Dans Nom de la stratégie, sélectionnez la stratégie avec les autorisations que vous souhaitez attribuer au principal IAM. Pour consulter les autorisations incluses dans chaque stratégie, consultez Autorisations des stratégies d'accès.

  7. Pour Portée d'accès, choisissez une portée d'accès. Si vous choisissez Cluster, les autorisations définies dans la stratégie d'accès sont accordées au principal IAM pour les ressources de tous les espaces de noms Kubernetes. Si vous choisissez un espace de noms Kubernetes, vous pouvez ensuite choisir Ajouter un espace de noms. Dans le champ Espace de noms qui apparaît, vous pouvez saisir le nom d'un espace de noms Kubernetes sur votre cluster. Si vous souhaitez que le principal IAM dispose d'autorisations sur plusieurs espaces de noms, vous pouvez saisir plusieurs espaces de noms.

  8. Choisissez Ajouter une stratégie d'accès.

AWS CLI
Prérequis

Version 2.12.3 ou version ultérieure 1.27.160 ou version ou ultérieure du AWS Command Line Interface (AWS CLI) installé et configuré sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez aws --version | cut -d / -f2 | cut -d ' ' -f1. Les gestionnaires de package, par exemple yum, apt-get, Homebrew ou macOS, sont souvent antérieurs de plusieurs versions à la AWS CLI. Pour installer la dernière version, consultez Installation, mise à jour et désinstallation de l’ AWS CLI et Configuration rapide avec aws configure dans le Guide de l’utilisateur AWS Command Line Interface . La AWS CLI version installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section Installation AWS CLI dans votre répertoire personnel dans le guide de AWS CloudShell l'utilisateur.

Pour associer une stratégie d'accès à une entrée d'accès
  1. Affichez les stratégies d'accès disponibles.

    aws eks list-access-policies --output table

    L'exemple qui suit illustre un résultat.

    ---------------------------------------------------------------------------------------------------------
    |                                          ListAccessPolicies                                           |
    +-------------------------------------------------------------------------------------------------------+
    ||                                           accessPolicies                                            ||
    |+---------------------------------------------------------------------+-------------------------------+|
    ||                                 arn                                 |             name              ||
    |+---------------------------------------------------------------------+-------------------------------+|
    ||  arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy        |  AmazonEKSAdminPolicy         ||
    ||  arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy |  AmazonEKSClusterAdminPolicy  ||
    ||  arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy         |  AmazonEKSEditPolicy          ||
    ||  arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy         |  AmazonEKSViewPolicy          ||
    |+---------------------------------------------------------------------+-------------------------------+|

    Pour consulter les autorisations incluses dans chaque stratégie, consultez Autorisations des stratégies d'accès.

  2. Consultez vos entrées d'accès existantes. Remplacez my-cluster par le nom de votre cluster.

    aws eks list-access-entries --cluster-name my-cluster

    L'exemple qui suit illustre un résultat.

    {
        "accessEntries": [
            "arn:aws:iam::111122223333:role/my-role",
            "arn:aws:iam::111122223333:user/my-user"
        ]
    }
  3. Associez une stratégie d'accès à une entrée d'accès. L'exemple suivant associe la stratégie d'accès AmazonEKSViewPolicy à une entrée d'accès. Chaque fois que le rôle IAM my-role tente d'accéder aux objets Kubernetes du cluster, Amazon EKS autorise le rôle à utiliser les autorisations définies dans la stratégie pour accéder aux objets Kubernetes des espaces de noms Kubernetes my-namespace1 et my-namespace2 uniquement. Remplacez my-cluster par le nom de votre cluster, 111122223333 par l'identifiant de votre Compte AWS et my-role par le nom du rôle IAM pour lequel vous souhaitez qu'Amazon EKS autorise l'accès aux objets du cluster Kubernetes.

    aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \ --access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy

    Si vous souhaitez que le principal IAM dispose des autorisations à l'échelle du cluster, remplacez type=namespace,namespaces=my-namespace1,my-namespace2 par type=cluster. Si vous souhaitez associer plusieurs stratégies d'accès à l'entrée d'accès, exécutez la commande plusieurs fois, chaque fois avec une stratégie d'accès unique. Chaque stratégie d'accès associée possède sa propre portée.

    Note

    Si vous souhaitez ultérieurement modifier la portée d'une stratégie d'accès associée, réexécutez la commande précédente avec la nouvelle portée. Par exemple, si vous souhaitez supprimer my-namespace2, vous devez réexécuter la commande en utilisant uniquement type=namespace,namespaces=my-namespace1. Si vous souhaitez modifier la portée de namespace à cluster, vous devez exécuter à nouveau la commande en utilisant type=cluster, ce qui supprime type=namespace,namespaces=my-namespace1,my-namespace2.

Pour dissocier une stratégie d'accès d'une entrée d'accès
  1. Déterminez les stratégies d'accès associées à une entrée d'accès.

    aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role

    L'exemple qui suit illustre un résultat.

    {
        "clusterName": "my-cluster",
        "principalArn": "arn:aws:iam::111122223333",
        "associatedAccessPolicies": [
            {
                "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
                "accessScope": {
                    "type": "cluster",
                    "namespaces": []
                },
                "associatedAt": "2023-04-17T15:25:21.675000-04:00",
                "modifiedAt": "2023-04-17T15:25:21.675000-04:00"
            },
            {
                "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
                "accessScope": {
                    "type": "namespace",
                    "namespaces": [
                        "my-namespace1",
                        "my-namespace2"
                    ]
                },
                "associatedAt": "2023-04-17T15:02:06.511000-04:00",
                "modifiedAt": "2023-04-17T15:02:06.511000-04:00"
            }
        ]
    }

    Dans l'exemple précédent, le principal IAM pour cette entrée d'accès dispose d'autorisations d'affichage sur tous les espaces de noms du cluster et d'autorisations d'administrateur pour deux espaces de noms Kubernetes.

  2. Dissociez une stratégie d'accès d'une entrée d'accès. Dans cet exemple, la stratégie AmazonEKSAdminPolicy est dissociée d'une entrée d'accès. Le principal IAM conserve toutefois les autorisations définies dans la stratégie d'accès AmazonEKSViewPolicy pour les objets des espaces de noms my-namespace1 et my-namespace2, car cette stratégie d'accès n'est pas dissociée de l'entrée d'accès.

    aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy

Autorisations des stratégies d'accès

Les stratégies d'accès incluent rules qui contiennent Kubernetes verbs (autorisations) et resources. Les stratégies d'accès n'incluent pas les autorisations ou les ressources IAM. Similaires aux objets Kubernetes Role etClusterRole, les stratégies d'accès incluent uniquement allow rules. Vous ne pouvez pas modifier le contenu d'une stratégie d'accès. Vous ne pouvez pas créer vos propres stratégies d'accès. Si les autorisations définies dans les stratégies d'accès ne répondent pas à vos besoins, créez alors des objets Kubernetes RBAC et spécifiez les noms de groupe pour vos entrées d'accès. Pour plus d’informations, consultez Création d'entrées d'accès. Les autorisations contenues dans les stratégies d'accès sont similaires à celles des rôles de cluster destinés aux utilisateurs Kubernetes. Pour plus d'informations, consultez la section Rôles destinés aux utilisateurs dans la documentation Kubernetes.

Choisissez n'importe quelle stratégie d'accès pour voir son contenu. Chaque ligne de chaque table dans chaque stratégie d'accès est une règle distincte.

Cette stratégie d'accès inclut des autorisations qui accordent à un principal IAM le plus grand nombre d'autorisations sur les ressources. Lorsqu'elle est associée à une entrée d'accès, sa portée d'accès est généralement constituée d'un ou de plusieurs espaces de noms Kubernetes. Si vous souhaitez qu'un principal IAM dispose d'un accès administrateur à toutes les ressources de votre cluster, associez plutôt la stratégie d'accès Amazon Eks ClusterAdminPolicy à votre entrée d'accès.

ARN – arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy

Groupes d'API Kubernetes Ressources Kubernetes Verbes (autorisations) Kubernetes
apps daemonsets, deployments, deployments/rollback, deployments/scale, replicasets, replicasets/scale, statefulsets, statefulsets/scale create, delete, deletecollection, patch, update
apps controllerrevisions, daemonsets, daemonsets/status, deployments, deployments/scale, deployments/status, replicasets, replicasets/scale, replicasets/status, statefulsets, statefulsets/scale, statefulsets/status get, list, watch
authorization.k8s.io localsubjectaccessreviews create
autoscaling horizontalpodautoscalers create, delete, deletecollection, patch, update
autoscaling horizontalpodautoscalers, horizontalpodautoscalers/status get, list, watch
batch cronjobs, jobs create, delete, deletecollection, patch, update
batch cronjobs, cronjobs/status, jobs, jobs/status get, list, watch
discovery.k8s.io endpointslices get, list, watch
extensions daemonsets, deployments, deployments/rollback, deployments/scale, ingresses, networkpolicies, replicasets, replicasets/scale, replicationcontrollers/scale create, delete, deletecollection, patch, update
extensions daemonsets, daemonsets/status, deployments, deployments/scale, deployments/status, ingresses, ingresses/status, networkpolicies, replicasets, replicasets/scale, replicasets/status, replicationcontrollers/scale get, list, watch
networking.k8s.io ingresses, ingresses/status, networkpolicies get, list, watch
networking.k8s.io ingresses, networkpolicies create, delete, deletecollection, patch, update
policy poddisruptionbudgets create, delete, deletecollection, patch, update
policy poddisruptionbudgets, poddisruptionbudgets/status get, list, watch
rbac.authorization.k8s.io rolebindings, roles create, delete, deletecollection, get, list, patch, update, watch
configmaps, endpoints, persistentvolumeclaims, persistentvolumeclaims/status, pods, replicationcontrollers, replicationcontrollers/scale, serviceaccounts, services, services/status get,list, watch
pods/attach, pods/exec, pods/portforward, pods/proxy, secrets, services/proxy get, list, watch
configmaps, events, persistentvolumeclaims, replicationcontrollers, replicationcontrollers/scale, secrets, serviceaccounts, services, services/proxy create, delete, deletecollection, patch, update
pods, pods/attach, pods/exec, pods/portforward, pods/proxy create, delete, deletecollection, patch, update
serviceaccounts impersonate
bindings, events, limitranges, namespaces/status, pods/log, pods/status, replicationcontrollers/status, resourcequotas, resourcequotas/status get, list, watch
namespaces get,list, watch

Cette stratégie d'accès inclut des autorisations qui accordent à un administrateur principal IAM l'accès à un cluster. Lorsqu'elle est associée à une entrée d'accès, sa portée d'accès est généralement le cluster, plutôt qu'un espace de noms Kubernetes. Si vous souhaitez qu'un principal IAM ait une portée administrative plus limitée, pensez plutôt à associer la stratégie d'accès Amazon Eks AdminPolicy à votre entrée d'accès.

ARN – arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

Groupes d'API Kubernetes Kubernetes nonResourceURLs Ressources Kubernetes Verbes (autorisations) Kubernetes
* * *
* *

Cette politique d'accès inclut des autorisations qui accordent à un IAM principal l'accès à la liste/à l'affichage de toutes les ressources d'un cluster. Notez que cela inclut Kubernetesles secrets.

ARN – arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy

Groupes d'API Kubernetes Ressources Kubernetes Verbes (autorisations) Kubernetes
* * get, list, watch

Cette stratégie d'accès inclut des autorisations qui permettent au principal IAM de modifier la plupart des ressources Kubernetes.

ARN – arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy

Groupes d'API Kubernetes Ressources Kubernetes Verbes (autorisations) Kubernetes
apps daemonsets, deployments, deployments/rollback, deployments/scale, replicasets, replicasets/scale, statefulsets, statefulsets/scale create, delete, deletecollection, patch, update
apps controllerrevisions, daemonsets, daemonsets/status, deployments, deployments/scale, deployments/status, replicasets, replicasets/scale, replicasets/status, statefulsets, statefulsets/scale, statefulsets/status get, list, watch
autoscaling horizontalpodautoscalers, horizontalpodautoscalers/status get, list, watch
autoscaling horizontalpodautoscalers create, delete, deletecollection, patch, update
batch cronjobs, jobs create, delete, deletecollection, patch, update
batch cronjobs, cronjobs/status, jobs, jobs/status get, list, watch
discovery.k8s.io endpointslices get, list, watch
extensions daemonsets, deployments, deployments/rollback, deployments/scale, ingresses, networkpolicies, replicasets, replicasets/scale, replicationcontrollers/scale create, delete, deletecollection, patch, update
extensions daemonsets, daemonsets/status, deployments, deployments/scale, deployments/status, ingresses, ingresses/status, networkpolicies, replicasets, replicasets/scale, replicasets/status, replicationcontrollers/scale get, list, watch
networking.k8s.io ingresses, networkpolicies create, delete, deletecollection, patch, update
networking.k8s.io ingresses, ingresses/status, networkpolicies get, list, watch
policy poddisruptionbudgets create, delete, deletecollection, patch, update
policy poddisruptionbudgets, poddisruptionbudgets/status get, list, watch
namespaces get, list, watch
pods/attach, pods/exec, pods/portforward, pods/proxy, secrets, services/proxy get, list, watch
serviceaccounts impersonate
pods, pods/attach, pods/exec, pods/portforward, pods/proxy create, delete, deletecollection, patch, update
configmaps, events, persistentvolumeclaims, replicationcontrollers, replicationcontrollers/scale, secrets, serviceaccounts, services, services/proxy create, delete, deletecollection, patch, update
configmaps, endpoints, persistentvolumeclaims, persistentvolumeclaims/status, pods, replicationcontrollers, replicationcontrollers/scale, serviceaccounts, services, services/status get, list, watch
bindings, events, limitranges, namespaces/status, pods/log, pods/status, replicationcontrollers/status, resourcequotas, resourcequotas/status get, list, watch

Cette stratégie d'accès inclut des autorisations qui permettent à un principal IAM de consulter la plupart des ressources Kubernetes.

ARN – arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy

Groupes d'API Kubernetes Ressources Kubernetes Verbes (autorisations) Kubernetes
apps controllerrevisions, daemonsets, daemonsets/status, deployments, deployments/scale, deployments/status, replicasets, replicasets/scale, replicasets/status, statefulsets, statefulsets/scale, statefulsets/status get, list, watch
autoscaling horizontalpodautoscalers, horizontalpodautoscalers/status get, list, watch
batch cronjobs, cronjobs/status, jobs, jobs/status get, list, watch
discovery.k8s.io endpointslices get, list, watch
extensions daemonsets, daemonsets/status, deployments, deployments/scale, deployments/status, ingresses, ingresses/status, networkpolicies, replicasets, replicasets/scale, replicasets/status, replicationcontrollers/scale get, list, watch
networking.k8s.io ingresses, ingresses/status, networkpolicies get, list, watch
policy poddisruptionbudgets, poddisruptionbudgets/status get, list, watch
configmaps, endpoints, persistentvolumeclaims, persistentvolumeclaims/status, pods, replicationcontrollers, replicationcontrollers/scale, serviceaccounts, services, services/status get, list, watch
bindings, events, limitranges, namespaces/status, pods/log, pods/status, replicationcontrollers/status, resourcequotas, resourcequotas/status get, list, watch
namespaces get, list, watch

Mises à jour des stratégies d'accès

Affichez les détails sur les mises à jour des stratégies d'accès depuis leur introduction. Pour recevoir des alertes automatiques sur les modifications apportées à cette page, abonnez-vous au flux RSS dans la page de l'historique des documents Amazon EKS.

Modification Description Date
Addition AmazonEKSAdminViewPolicy Ajoutez une nouvelle politique pour un accès étendu aux vues, y compris à des ressources telles que les secrets. 23 avril 2024

Stratégies d'accès introduites.

Amazon EKS a introduit des stratégies d'accès.

29 mai 2023