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.

SSH direct

Avant d'activer, vérifiez les points suivants :

Conditions préalables

Le SSH direct nécessite ExternalDNS, une zone hébergée privée Amazon Route 53, une connectivité VPC depuis les machines clientes et (éventuellement) le AWS Load Balancer Controller. Pour la liste complète des prérequis, voirPrérequis pour le protocole SSH direct.

Si l'accès au navigateur Web est déjà activé sur votre cluster, tous les prérequis sont en place. Avant de continuer, vérifiez que votre ExternalDNS est configuré avec. --policy=sync Pour en savoir plus, consultez Configuration DNS externe.

Si l'accès au navigateur Web n'est pas encore configuré, consultez(Facultatif) Configuration des prérequis. Pour plus d'informations sur l'activation de l'accès au navigateur Web, consultezInstallation de l'extension EKS - Jupyter K8s avec WebUI.

Configurer Direct SSH pour votre cluster

Étape 1 : Ajouter une règle de groupe de sécurité pour SSH

L'accès au navigateur Web utilise le protocole HTTPS (443) via un équilibreur de charge d'application (ALB). Étant donné que Direct SSH se connecte directement aux adresses IP des pods sur le port configuré, vous devez ajouter une règle entrante de groupe de sécurité.

Vérifiez si votre groupe d'instances d'espace de travail dispose d'une dérogation SG :

aws sagemaker describe-cluster \
  --cluster-name <HYPERPOD_CLUSTER_NAME> \
  --region <AWS_REGION> \
  --query 'InstanceGroups[*].{Name:InstanceGroupName, OverrideSGs:OverrideVpcConfig.SecurityGroupIds}'

Option A : le groupe d'instances est remplacé par un groupe de sécurité

Si la valeur OverrideSGs n'est pas nulle, ajoutez la règle à ce groupe de sécurité :

SG_ID=<SG_ID_FROM_OVERRIDE_VPC_CONFIG>
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol tcp \
  --port <SSH_PORT> \
  --cidr <SOURCE_CIDR> \
  --region <AWS_REGION>

Option B : le groupe d'instances n'a aucune dérogation de groupe de sécurité

Si la valeur OverrideSGs est nulle, utilisez le groupe de sécurité au niveau du cluster à partir de la configuration VPC du SageMaker HyperPod cluster :

SG_ID=$(aws sagemaker describe-cluster --cluster-name <HYPERPOD_CLUSTER_NAME> --region <AWS_REGION> \
  --query 'VpcConfig.SecurityGroupIds[0]' --output text)
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol tcp \
  --port <SSH_PORT> \
  --cidr <SOURCE_CIDR> \
  --region <AWS_REGION>

Le tableau suivant indique où trouver chaque valeur d'espace réservé.

Étape 2 : activer le SSH direct

Ajoutez directSSH à la configuration de votre module complémentaire : clusterWebUI

jupyter-k8s-aws-hyperpod:
  clusterWebUI:
    enabled: true
    domain: "<DOMAIN_NAME>"
    awsCertificateArn: "<ACM_CERTIFICATE_ARN>"
    traefik:
      shouldInstall: true
  directSSH:
    enabled: true
    port: <SSH_PORT>          # default: 22
    domain: "<ROUTE53_HOSTED_ZONE_DOMAIN>"

Le tableau suivant indique où trouver chaque valeur d'espace réservé.

Mettez à jour l'addon :

aws eks update-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --configuration-values file://addon-config.yaml \
  --resolve-conflicts OVERWRITE \
  --region <AWS_REGION>

Pour désactiver le SSH direct, consultezRévocation de l'accès SSH direct.

Étape 3 : Vérifiez que Direct SSH est actif

# Check addon status
aws eks describe-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --region <AWS_REGION>

# Check headless services created for workspaces
kubectl get svc -l app.kubernetes.io/component=direct-ssh

# Verify DNS record resolves (from within VPC)
dig <workspace-name>.<namespace>.<ROUTE53_HOSTED_ZONE_DOMAIN>

Connectez-vous à votre espace de travail via Direct SSH

Suivez les procédures suivantes pour vous connecter à votre espace de travail à l'aide de Direct SSH, gérer vos clés SSH et résoudre les problèmes de connexion.

Comment fonctionne l'authentification SSH

Le SSH direct utilise l'authentification par clé publique standard. Chaque utilisateur génère sa propre paire de clés SSH et ajoute la clé publique à son espace de travail. Les clés privées ne quittent jamais la machine de l'utilisateur.

Voici quelques informations essentielles concernant l'accès SSH :

Étape 1 : Générez une clé SSH sur votre machine cliente

Exécutez cette commande une fois pour créer votre paire de clés :

ssh-keygen -t ed25519 -f ~/.ssh/my-workspace-key

Cela crée :

Étape 2 : ajoutez votre clé publique à votre espace de travail

Utilisez l'une des méthodes suivantes pour ajouter votre clé publique. Il n'est pas nécessaire de faire les deux.

Ajoutez votre clé via l'accès au navigateur Web

Ajoutez votre clé via kubectl

POD=$(kubectl get pods -n <namespace> -l workspace.jupyter.org/workspace-name=<space-name> \
  -o jsonpath='{.items[0].metadata.name}')
cat ~/.ssh/my-workspace-key.pub | kubectl exec -n <namespace> -i $POD -c workspace -- \
  bash -c "cat >> /home/sagemaker-user/.ssh/authorized_keys"

Étape 3 : Connectez-vous à votre espace de travail via SSH

ssh -p <SSH_PORT> -i ~/.ssh/my-workspace-key sagemaker-user@<space-name>.<namespace>.<domain>

Exemple :

ssh -p 2222 -i ~/.ssh/my-workspace-key sagemaker-user@my-space.default.spaces.example.com

Étape 4 : configurer SSH pour un accès facile

Cette étape facultative simplifie les connexions futures. Ajoutez ce qui suit à ~/.ssh/config :

Host my-space
    HostName <space-name>.<namespace>.<domain>
    Port <SSH_PORT>
    User sagemaker-user
    IdentityFile ~/.ssh/my-workspace-key
    ServerAliveInterval 15
    ServerAliveCountMax 3

Définissez Port le port configuré par votre administrateur. Vous pouvez omettre cette ligne si Direct SSH utilise le port par défaut (22). Connectez-vous ensuite à : ssh my-space

Étape 5 : connecter un IDE distant

Une fois que Direct SSH fonctionne depuis votre terminal (étape 3), tout IDE Remote-SSH compatible se connecte en utilisant la même ~/.ssh/config entrée. Vous n'avez pas besoin AWS de configuration supplémentaire pour cette connexion.

Installez l' Remote-SSH extension

Connectez-vous depuis l'IDE

Gestion des clés et révocation

Vous gérez vos clés SSH. Les clés SSH sont des informations d'identification durables qui n'expirent pas automatiquement. Une clé permet d'accéder authorized_keys à votre espace de travail jusqu'à ce que vous le supprimiez explicitement.

Pour faire pivoter votre clé

Nous vous recommandons de changer régulièrement vos clés.

Si votre clé privée est compromise

Agissez immédiatement. Une clé compromise permet d'accéder à l'intégralité de l'espace de travail jusqu'à ce que vous la supprimiezauthorized_keys.

Bonnes pratiques

Révocation de l'accès SSH direct

Pour éviter de laisser une règle de groupe de sécurité ouverte après avoir désactivé Direct SSH, effectuez les trois étapes dans l'ordre. Ne sautez pas l'étape 2.

Étape 1 : Désactiver dans le graphique Helm

Supprimez complètement directSSH cette section du fichier de configuration de votre module complémentaire. Par défaut, Helm est directSSH.enabled activé false lorsque la clé est absente :

jupyter-k8s-aws-hyperpod:
  clusterWebUI:
    enabled: true
    domain: "<DOMAIN_NAME>"
    ...
  # directSSH section removed

Vous pouvez également définir explicitement enabled: false :

directSSH:
  enabled: false

Étape 2 : supprimer la règle entrante du groupe de sécurité

# Find the rule ID
aws ec2 describe-security-group-rules \
  --filters Name=group-id,Values=<SG_ID> \
  --query 'SecurityGroupRules[?IpProtocol==`tcp` && FromPort==`<SSH_PORT>`].[SecurityGroupRuleId,CidrIpv4]' \
  --output table \
  --region <AWS_REGION>

# Remove the rule
aws ec2 revoke-security-group-ingress \
  --group-id <SG_ID> \
  --security-group-rule-ids <RULE_ID> \
  --region <AWS_REGION>

Étape 3 : Appliquer au cluster

aws eks update-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --configuration-values file://addon-config.yaml \
  --resolve-conflicts OVERWRITE \
  --region <AWS_REGION>

L'exécution de cette commande supprime les services headless pour tous les espaces de travail. ExternalDNS supprime ensuite les enregistrements de la Route 53 A dans un délai d'environ 30 secondes. Une fois qu'ExternalDNS a supprimé les enregistrements, les nouvelles connexions SSH ne peuvent plus résoudre le nom d'hôte de l'espace de travail.

Que se passe-t-il après la révocation

Résolution des problèmes

(Facultatif) Configuration des prérequis

Utilisez cette section uniquement si l'accès au navigateur Web n'est pas déjà activé, ou pour vérifier ou mettre à jour votre configuration ExternalDNS.

Installation à partir de zéro

Si l'accès au navigateur Web n'est pas encore configuré, vous devez disposer des éléments suivants avant d'activer Direct SSH :

Pour les dépendances supplémentaires et les étapes de configuration de l'accès au navigateur Web, consultezInstallez SageMaker AI Spaces Add-on.

AWS Contrôleur d'équilibrage de charge : exigence HyperPod vPCID

La documentation d'installation standard du AWS Load Balancer Controller ne mentionne pas le vpcId paramètre. Sur les HyperPod clusters, l'omission vpcId entraîne l'échec de l'installation. Vous devez le fournir explicitement.

Obtenez votre identifiant VPC :

aws sagemaker describe-cluster \
  --cluster-name <HYPERPOD_CLUSTER_NAME> \
  --region <AWS_REGION> \
  --query 'VpcConfig.VpcId' \
  --output text

Installation avec les HyperPod paramètres requis :

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=<EKS_CLUSTER_NAME> \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set enableServiceMutatorWebhook=false \
  --set vpcId=<VPC_ID>

Créez le compte de service (aws-load-balancer-controller) avec l'annotation de rôle IAM appropriée avant d'exécuter cette commande. Pour plus d'informations sur la politique IAM et les étapes de création de comptes de service, consultez la section Configuration de l'Amazon EKS Load Balancer Controller IRSA dans le guide de l'utilisateur Amazon EKS.

Configuration DNS externe

ExternalDNS synchronise les services Kubernetes avec les fournisseurs DNS. Configurez ExternalDNS avec les paramètres suivants lorsque vous l'utilisez avec Amazon Route 53 dans un environnement de production.

Par défaut, ExternalDNS utilise. --policy=upsert-only Cela crée et met à jour des enregistrements DNS mais ne les supprime jamais. Lorsque vous supprimez un espace de travail, les enregistrements A et TXT d'Amazon Route 53 restent obsolètes.

--policy=upsert-onlyUtilisez-le uniquement pour les tests et remplacez-le par --policy=sync pour la production. Vous devez également définir le --txt-owner-id drapeau, qui indique à ExternalDNS quels enregistrements il possède et quels enregistrements supprimer lors du nettoyage.

Configurez votre déploiement ExternalDNS avec les arguments suivants :

--provider=aws
--source=service                          # watches Services (required for headless Services)
--domain-filter=<ROUTE53_HOSTED_ZONE>     # restricts ExternalDNS to your hosted zone only
--policy=sync                             # enables deletion of stale records on space deletion
--txt-owner-id=<CLUSTER_NAME>             # identifies which records this ExternalDNS instance owns

Dans les arguments précédents, remplacez les valeurs suivantes :

Pour vérifier votre politique ExternalDNS actuelle, exécutez la commande suivante :

kubectl get deployment -n kube-system external-dns \
  -o jsonpath='{.spec.template.spec.containers[0].args}' | tr ',' '\n' | grep -E 'policy|owner|source|domain'