翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

直接 SSH

有効にする前に、以下を確認してください。

前提条件

Direct SSH には、ExternalDNS、Amazon Route 53 プライベートホストゾーン、クライアントマシンからの VPC 接続、および (オプションで) AWS Load Balancerコントローラーが必要です。前提条件の完全なリストについては、「」を参照してくださいDirect SSH の前提条件。

クラスターでウェブブラウザアクセスが既に有効になっている場合、すべての前提条件が設定されています。続行する前に、ExternalDNS が で設定されていることを確認します--policy=sync。詳細については、「ExternalDNS 設定」を参照してください。

ウェブブラウザへのアクセスがまだ設定されていない場合は、「」を参照してください(オプション) 前提条件の設定。ウェブブラウザアクセスの有効化の詳細については、「」を参照してくださいEKS アドオンのインストール - WebUI を使用した Jupyter K8s。

クラスターの Direct SSH を設定する

ステップ 1: SSH のセキュリティグループルールを追加する

ウェブブラウザアクセスは、Application Load Balancer (ALB) を介して HTTPS (443) を使用します。Direct SSH は設定されたポートのポッド IPs に直接接続するため、セキュリティグループのインバウンドルールを追加する必要があります。

ワークスペースインスタンスグループに SG オーバーライドがあるかどうかを確認します。

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

オプション A: インスタンスグループにセキュリティグループのオーバーライドがある

OverrideSGs が null 以外の場合は、そのセキュリティグループにルールを追加します。

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>

オプション B: インスタンスグループにセキュリティグループのオーバーライドがない

OverrideSGs が null の場合、SageMaker HyperPod クラスター VPC 設定からクラスターレベルのセキュリティグループを使用します。

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>

次の表は、各プレースホルダー値の場所を示しています。

ステップ 2: Direct SSH を有効にする

アドオン設定directSSHに を とともに追加します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>"

次の表は、各プレースホルダー値の場所を示しています。

アドオンを更新します。

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>

Direct SSH を無効にするには、「」を参照してください直接 SSH アクセスの取り消し。

ステップ 3: Direct SSH がアクティブであることを確認する

# 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>

Direct SSH を使用してワークスペースに接続する

次の手順を使用して、Direct SSH を使用してワークスペースに接続し、SSH キーを管理し、接続の問題をトラブルシューティングします。

SSH 認証の仕組み

Direct SSH は、標準のパブリックキー認証を使用します。各ユーザーは独自の SSH キーペアを生成し、パブリックキーをワークスペースに追加します。プライベートキーがユーザーのマシンから出ることはありません。

以下は、SSH アクセスに関する重要な事実です。

ステップ 1: クライアントマシンで SSH キーを生成する

このコマンドを 1 回実行してキーペアを作成します。

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

これにより、以下が作成されます。

ステップ 2: パブリックキーをワークスペースに追加する

パブリックキーを追加するには、次のいずれかの方法を使用します。両方を行う必要はありません。

ウェブブラウザアクセスを使用してキーを追加する

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"

ステップ 3: SSH を使用してワークスペースに接続する

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

例:

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

ステップ 4: 簡単にアクセスできるように SSH を設定する

このオプションのステップは、将来の接続を簡素化します。以下を ~/.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

を、管理者が設定したポートPortに設定します。Direct SSH がデフォルトのポート (22) を使用している場合は、この行を省略できます。次に、以下を使用して接続します。 ssh my-space

ステップ 5: リモート IDE を接続する

Direct SSH がターミナルから動作した後 (ステップ 3)、Remote-SSH 対応 IDE は同じ~/.ssh/configエントリを使用して接続します。この接続には追加の AWS 設定は必要ありません。

Remote-SSH 拡張機能をインストールする

IDE から接続する

キーの管理と取り消し

SSH キーを管理します。SSH キーは、自動有効期限のない存続期間の長い認証情報です。のキーは、明示的に削除するまでワークスペースへのアクセスauthorized_keysを許可します。

キーをローテーションするには

キーを定期的にローテーションすることをお勧めします。

プライベートキーが侵害された場合

すぐに行動してください。侵害されたキーは、 から削除するまでワークスペースへのフルアクセスを許可しますauthorized_keys。

ベストプラクティス

直接 SSH アクセスの取り消し

Direct SSH を無効にした後にオープンセキュリティグループルールを離れないようにするには、3 つのステップをすべて順番に実行します。ステップ 2 はスキップしないでください。

ステップ 1: Helm チャートで を無効にする

アドオン設定ファイルから directSSHセクションを完全に削除します。キーがない場合、Helm はデフォルトで false directSSH.enabledになります。

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

または、明示的に を設定しますenabled: false。

directSSH:
  enabled: false

ステップ 2: セキュリティグループのインバウンドルールを削除する

# 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>

ステップ 3: クラスターに適用する

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>

このコマンドを実行すると、すべてのワークスペースのヘッドレスサービスが削除されます。ExternalDNS は、約 30 秒以内に Route 53 A レコードを削除します。ExternalDNS がレコードを削除すると、新しい SSH 接続はワークスペースのホスト名を解決できなくなります。

失効後にどうなるか

トラブルシューティング

(オプション) 前提条件の設定

このセクションは、ウェブブラウザアクセスがまだ有効になっていない場合、または ExternalDNS 設定を確認または更新する場合にのみ使用します。

ゼロからのインストール

ウェブブラウザへのアクセスがまだ設定されていない場合は、Direct SSH を有効にする前に以下が必要です。

その他の依存関係とウェブブラウザのアクセス設定手順については、「」を参照してくださいSageMaker AI Spaces アドオンをインストールする。

AWS Load Balancer Controller: HyperPod vpcId の要件

standard AWS Load Balancer Controller のインストールドキュメントには、 vpcIdパラメータは記載されていません。HyperPod クラスターで を省略vpcIdすると、インストールが失敗します。明示的に指定する必要があります。

VPC ID を取得します。

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

必要な HyperPod パラメータを使用して をインストールします。

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>

このコマンドを実行する前に、適切な IAM ロール注釈を使用してサービスアカウント (aws-load-balancer-controller) を作成します。IAM ポリシーとサービスアカウントの作成手順の詳細については、「Amazon EKS ユーザーガイド」の「Amazon EKS Load Balancer Controller IRSA のセットアップ」を参照してください。

ExternalDNS 設定

ExternalDNS は、Kubernetes サービスと DNS プロバイダーを同期します。本番環境で Amazon Route 53 で使用する場合は、次の設定で ExternalDNS を設定します。

デフォルトでは、ExternalDNS は を使用します--policy=upsert-only。これにより、DNS レコードは作成および更新されますが、削除されることはありません。ワークスペースを削除すると、Amazon Route 53 の A レコードと TXT レコードは古いエントリのままになります。

テスト--policy=upsert-onlyにのみ使用し、本番環境--policy=syncの場合は に変更します。また、 --txt-owner-idフラグを設定する必要があります。フラグは、所有するレコードとクリーンアップ時に削除するレコードを ExternalDNS に指示します。

ExternalDNS デプロイを次の引数で設定します。

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

上記の引数で、次の値を置き換えます。

現在の ExternalDNS ポリシーを確認するには、次のコマンドを実行します。

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