Configuration d’un cluster Amazon EKS dans Studio

Sur la page Gérer l'accès, sélectionnez un domaine existant. L'accès de Studio à un HyperPod cluster passe par un domaine, et le rôle d'exécution du domaine est le principal IAM que Studio utilise pour agir sur votre cluster. Pour en savoir plus sur la création d’un domaine, consultez Guide pour configurer Amazon SageMaker AI.

Associez les autorisations suivantes à votre rôle d'exécution depuis la console IAM.

Pour plus d'informations sur les rôles d'exécution de l' SageMaker IA et sur la manière de les modifier, consultezComprendre les autorisations d’espace de domaine et les rôles d’exécution.

Pour découvrir comment attacher des politiques à un utilisateur ou à un groupe IAM, consultez Ajout et suppression d’autorisations basées sur l’identité IAM.

Avant de joindre la politique, remplacez les deux exemples d'ARN par les vôtres :

Il s'agit de deux ressources différentes avec deux ARN différents. Recherchez l'ARN du HyperPod cluster dans la console SageMaker AI et l'ARN du cluster Amazon EKS dans la console Amazon EKS. Si vous laissez les exemples de valeurs en place, Studio ne peut pas décrire votre cluster et l'onglet Tâches ne se charge pas.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DescribeHyperpodClusterPermissions",
            "Effect": "Allow",
            "Action": [
                "sagemaker:DescribeCluster"
            ],
            "Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/hyperpod-cluster-name"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:Describe*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ecr:CompleteLayerUpload",
                "ecr:GetAuthorizationToken",
                "ecr:UploadLayerPart",
                "ecr:InitiateLayerUpload",
                "ecr:BatchCheckLayerAvailability",
                "ecr:PutImage"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricData",
                "cloudwatch:GetMetricData"
            ],
            "Resource": "*"
        },
        {
            "Sid": "UseEksClusterPermissions",
            "Effect": "Allow",
            "Action": [
                "eks:DescribeCluster",
                "eks:AccessKubernetesApi",
                "eks:MutateViaKubernetesApi"
            ],
            "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/eks-cluster-name"
        },
        {
            "Sid": "DescribeSpacesAddon",
            "Effect": "Allow",
            "Action": "eks:DescribeAddon",
            "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/eks-cluster-name/*"
        },
        {
            "Sid": "ListClustersPermission",
            "Effect": "Allow",
            "Action": [
                "sagemaker:ListClusters"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession",
                "ssm:TerminateSession"
            ],
            "Resource": "*"
        }
    ]
}

Attachez des politiques d'accès au cluster au rôle d'exécution. La politique IAM de l'étape précédente permet au rôle d'exécution d'appeler les AWS API. Il ne donne aucune autorisation au rôle dans le cluster Kubernetes. Cluster-access c'est ce que font les politiques, et seul un rôle auquel sont rattachés les bons rôles atteint le cluster. Joignez-les depuis Gérer l'accès, sur le domaine ou sur le profil utilisateur.

Sélectionnez le rôle d'exécution pour le domaine ou le profil utilisateur auquel vous accordez l'accès, puis sélectionnez les politiques dont vos utilisateurs ont besoin. Choisissez si vous souhaitez limiter l'accès à un espace de noms ou à l'ensemble du cluster, en limitant la portée à un espace de noms lorsque les équipes partagent un cluster, puis enregistrez. L'étendue d'un espace de noms limite également les tâches que ces utilisateurs peuvent voir dans Studio. Pour savoir ce que chaque politique permet, comment définir l'accès et comment accorder un ensemble personnalisé d'autorisations à la place, consultezRestriction de l’affichage des tâches dans Studio pour les clusters EKS.

Si vous accordez l'accès de cette manière, vous créez l'entrée d'accès Amazon EKS pour le rôle d'exécution. Il n'y a donc pas d'étape distincte dans la console Amazon EKS. Pour les concepts qui sous-tendent le modèle d'accès, voir Autoriser les utilisateurs IAM à accéder à Kubernetes avec des entrées d'accès EKS.

(Facultatif) Pour garantir une expérience plus fluide, nous vous recommandons d’ajouter des balises à vos clusters. Pour plus d'informations sur la façon d'ajouter des balises, consultez la section Mise Modifier un SageMaker HyperPod cluster à jour de votre cluster à l'aide de la console SageMaker AI.

Balisez votre espace de travail Amazon Managed Grafana par rapport à votre domaine Studio. Utilisez cette balise pour créer un lien vers votre espace de travail Grafana directement depuis votre cluster dans Studio. Ajoutez la balise suivante à votre cluster pour l'identifier à l'aide de votre identifiant d'espace de travail Grafana,ws-id.

Clé de balise = « grafana-workspace », Valeur de balise = « ws-id ».

Enregistrez la configuration YAML à un fichier nommé cluster-role.yaml.

Appliquez la configuration à l'aide kubectl du site Web de Kubernetes :

kubectl apply -f cluster-role.yaml

Vérifiez la configuration :

kubectl get clusterrole pods-events-crd-cluster-role
kubectl get clusterrolebinding pods-events-crd-cluster-role-binding

Affectez des utilisateurs au groupe pods-events-crd-cluster-level via votre fournisseur d’identité ou IAM.