翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 直接 SSH
**セキュリティ通知**
Direct SSH は、クラスターポッドでインバウンド TCP ポートを開きます。オープンなインバウンドポートは必要ない[SSM 経由の SSH を使用したリモートアクセス](vscode-access.md)ので、お勧めします。SSM を介したリモートアクセスがニーズを満たせない (インターネットアクセスがない、標準の SSH ツールが必要など) 場合にのみ、Direct SSH を有効にします。
有効にする前に、以下を確認してください。
クラスター全体の影響
`directSSH.enabled: true` は、選択したワークスペースやユーザーだけでなく、クラスター全体ですべてのワークスペースポッドの設定済みポートを開きます。
セキュリティグループスコープ
インバウンドルールを、可能な限り最も狭いソース Classless Inter-Domain Routing (CIDR) ブロックに制限します。は使用しないでください`0.0.0.0/0`。Config restricted-ssh AWS マネージドルールを使用して定期的に監査します。 [https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html](https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html)
SSH キーのライフサイクル
SSH キーのライフサイクルを管理します。SSH キーは存続期間の長い認証情報です。ローテーションポリシーがない場合、侵害されたキーは永続的なアクセスを許可します。チームにロールアウトする前に、SSH キーローテーションポリシーを確立し、定期的にキーをローテーションします。
VPC ネットワークの分離
VPC ネットワークの分離を管理します。Direct SSH を有効にすると、sshd はポッドで開始され、VPC セキュリティグループとルーティングコントロールはポッドに到達できるユーザーを制御します。信頼できるネットワークソース (VPN サブネット、Direct Connect CIDR、または企業ネットワーク範囲) のみが設定されたポートに到達できることを確認します。Direct SSH は、VPC 内のポッドのプライベート IP アドレスの SSH ポートを公開します。クライアントは、同じ VPC、VPC ピアリング、VPN、または Direct Connect を介して、その VPC へのネットワーク接続がある場合にのみアクセスできます。
## 前提条件
Direct SSH には、ExternalDNS、Amazon Route 53 プライベートホストゾーン、クライアントマシンからの VPC 接続、および (オプションで) AWS Load Balancerコントローラーが必要です。前提条件の完全なリストについては、「」を参照してください[Direct SSH の前提条件](permission-setup.md#permission-direct-ssh)。
クラスターでウェブブラウザアクセスが既に有効になっている場合、すべての前提条件が設定されています。続行する前に、ExternalDNS が で設定されていることを確認します`--policy=sync`。詳細については、「[ExternalDNS 設定](#direct-ssh-appendix-externaldns)」を参照してください。
ウェブブラウザへのアクセスがまだ設定されていない場合は、「」を参照してください[(オプション) 前提条件の設定](#direct-ssh-appendix)。ウェブブラウザアクセスの有効化の詳細については、「」を参照してください[EKS アドオンのインストール - WebUI を使用した Jupyter K8s](operator-install.md#webui-install)。
## クラスターの Direct SSH を設定する
**クラスター全体のスコープ**
`directSSH.enabled: true` は、クラスター全体のすべてのワークスペースポッドの設定済みポートで sshd を開始します。SSH は JupyterLab ターミナルと同じアクセスを提供します。同じユーザー (`sagemaker-user`)、同じファイルシステムです。
### ステップ 1: SSH のセキュリティグループルールを追加する
ウェブブラウザアクセスは、Application Load Balancer (ALB) を介して HTTPS (443) を使用します。Direct SSH は設定されたポートのポッド IPs に直接接続するため、セキュリティグループのインバウンドルールを追加する必要があります。
**VPC 設定はお客様の責任となります。**
セキュリティグループ、ルーティング、ネットワークアクセスコントロールなど、VPC を正しく設定する必要があります。Direct SSH はポッドで sshd を開始します。VPC は、到達できるユーザーを決定します。ワークスペースに SSH 接続できる CIDRs (企業ネットワーク範囲、VPN トンネルサブネット、Direct Connect CIDR など) にのみアクセスを制限します。`0.0.0.0/0` を使用しないでください。
**変更する前に正しいセキュリティグループを確認する**
HyperPod インスタンスグループは、セキュリティグループを含む を通じて`OverrideVpcConfig`グループレベルで VPC 設定を上書きできます。変更する正しいセキュリティグループは、ワークスペースインスタンスグループにオーバーライドがあるかどうかによって異なります。ルールを間違ったセキュリティグループに追加すると、サイレント`Connection timed out`エラーが発生します。
ワークスペースインスタンスグループに SG オーバーライドがあるかどうかを確認します。
```
aws sagemaker describe-cluster \
--cluster-name \
--region \
--query 'InstanceGroups[*].{Name:InstanceGroupName, OverrideSGs:OverrideVpcConfig.SecurityGroupIds}'
```
#### オプション A: インスタンスグループにセキュリティグループのオーバーライドがある
`OverrideSGs` が null 以外の場合は、そのセキュリティグループにルールを追加します。
```
SG_ID=
aws ec2 authorize-security-group-ingress \
--group-id $SG_ID \
--protocol tcp \
--port \
--cidr \
--region
```
#### オプション B: インスタンスグループにセキュリティグループのオーバーライドがない
`OverrideSGs` が null の場合、SageMaker HyperPod クラスター VPC 設定からクラスターレベルのセキュリティグループを使用します。
```
SG_ID=$(aws sagemaker describe-cluster --cluster-name --region \
--query 'VpcConfig.SecurityGroupIds[0]' --output text)
aws ec2 authorize-security-group-ingress \
--group-id $SG_ID \
--protocol tcp \
--port \
--cidr \
--region
```
次の表は、各プレースホルダー値の場所を示しています。
| Placeholder | 入手先 |
| --- | --- |
| | SageMaker AWS マネジメントコンソールで、HyperPod クラスターを選択します。または、 を実行しますaws sagemaker list-clusters。 |
| | で設定したポート directSSH.port (デフォルトは 22)。セキュリティグループのインバウンドルールと一致する必要があります。 |
| | HyperPod クラスターと EKS クラスターがデプロイされる AWS リージョン。 |
| | 信頼されたネットワークの CIDR: VPN トンネルサブネット、Direct Connect CIDR、または企業ネットワーク範囲 (10.192.16.0/24 など）。0.0.0.0/0 にすることはできません。 |
### ステップ 2: Direct SSH を有効にする
アドオン設定`directSSH`に を とともに追加します`clusterWebUI`。
```
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
traefik:
shouldInstall: true
directSSH:
enabled: true
port: # default: 22
domain: ""
```
次の表は、各プレースホルダー値の場所を示しています。
| Placeholder | 入手先 |
| --- | --- |
| | ウェブブラウザアクセスを有効にしたときに設定したドメイン (spaces.example.com など）。詳細については、「[EKS アドオンのインストール - WebUI を使用した Jupyter K8s](operator-install.md#webui-install)」を参照してください。 |
| | AWS Certificate Manager (ACM) AWS マネジメントコンソールで Certificates を選択し、ワイルドカード証明書 ARN を選択します。 |
| | Route 53 AWS マネジメントコンソールで、ホストゾーンを選択し、ExternalDNS に使用されるプライベートホストゾーン名 (workspaces.internal など) を選択します。 |
| | ポート sshd はワークスペースポッド内でリッスンします。デフォルトは 22 です。セキュリティグループまたは企業ポリシーでポート 22 が制限されている場合は、非特権ポート (2222 など) を使用します。SG インバウンドルールはこの値と一致する必要があります。 |
**directSSH と remoteAccess は相互に排他的です**
`directSSH` と `remoteAccess`は相互に排他的です。両方の を有効にすると`helm upgrade`、directSSH と remoteAccess は相互に排他的です。1 つだけ有効にします。」 を有効にする`remoteAccess`前に を無効にします`directSSH`。
アドオンを更新します。
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
Direct SSH を無効にするには、「」を参照してください[直接 SSH アクセスの取り消し](#direct-ssh-revoke)。
### ステップ 3: Direct SSH がアクティブであることを確認する
```
# Check addon status
aws eks describe-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--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 ..
```
## Direct SSH を使用してワークスペースに接続する
次の手順を使用して、Direct SSH を使用してワークスペースに接続し、SSH キーを管理し、接続の問題をトラブルシューティングします。
### SSH 認証の仕組み
Direct SSH は、標準のパブリックキー認証を使用します。各ユーザーは独自の SSH キーペアを生成し、パブリックキーをワークスペースに追加します。プライベートキーがユーザーのマシンから出ることはありません。
以下は、SSH アクセスに関する重要な事実です。
+ SSH は JupyterLab ターミナルと同じアクセス権を付与します。同じユーザー (`sagemaker-user`)、同じファイルシステム、同じツール。
+ キーはワークスペースごとです。1 つのワークスペースのキーは、他のワークスペースへのアクセスを許可しません。
+ SageMaker AI Spaces 起動スクリプトは、正しいアクセス許可を持つ`.ssh/`ディレクトリを自動的に作成します。
+ キーはワークスペースの再起動 (PVC に保存) 後も保持され、ワークスペースが削除されると削除されます。
**現在の制限**
SSH ユーザー名は、接続するユーザー`sagemaker-user`に関係なく常に です。個人用ユーザー名を使用することはできません。すべてのセッションは、同じワークスペースユーザーとして実行されます。シェルプロンプトと監査ログのユーザーごとの ID は、現在のリリースでは利用できません。
### ステップ 1: クライアントマシンで SSH キーを生成する
このコマンドを 1 回実行してキーペアを作成します。
```
ssh-keygen -t ed25519 -f ~/.ssh/my-workspace-key
```
これにより、以下が作成されます。
+ `~/.ssh/my-workspace-key` — プライベートキー (シークレットを保持し、共有しない)
+ `~/.ssh/my-workspace-key.pub` — パブリックキー (ワークスペースに追加)
### ステップ 2: パブリックキーをワークスペースに追加する
パブリックキーを追加するには、****次のいずれかの方法を使用します。両方を行う必要はありません。
#### ウェブブラウザアクセスを使用してキーを追加する
1. ブラウザでワークスペースを開きます (「」を参照[ウェブブラウザアクセス](browser-access.md))。
1. ターミナルを開きます。JupyterLab で、**ファイル**、**新規**、**ターミナル**を選択します。コードエディタで、**ターミナル**、**新しいターミナル**を選択します。
1. ローカルマシンからパブリックキーをコピーします。 `cat ~/.ssh/my-workspace-key.pub`
1. ワークスペースターミナルに貼り付けます。
```
echo "ssh-ed25519 AAAA...your-key... user@machine" >> ~/.ssh/authorized_keys
```
#### kubectl を使用してキーを追加する
```
POD=$(kubectl get pods -n -l workspace.jupyter.org/workspace-name= \
-o jsonpath='{.items[0].metadata.name}')
cat ~/.ssh/my-workspace-key.pub | kubectl exec -n -i $POD -c workspace -- \
bash -c "cat >> /home/sagemaker-user/.ssh/authorized_keys"
```
### ステップ 3: SSH を使用してワークスペースに接続する
```
ssh -p -i ~/.ssh/my-workspace-key sagemaker-user@..
```
**SSH ポート**
管理者が Direct SSH 用に設定した SSH ポートを使用します。管理者がデフォルトのポート (22) を保持している場合は、 `-p`オプションを省略できます。デフォルト以外のポート (2222 など) を設定した場合は、 を含める必要があります。そうしないと、 で接続`-p `が失敗します`Connection refused`。使用するポートが不明な場合は、管理者にお問い合わせください。
例:
```
ssh -p 2222 -i ~/.ssh/my-workspace-key sagemaker-user@my-space.default.spaces.example.com
```
### ステップ 4: 簡単にアクセスできるように SSH を設定する
このオプションのステップは、将来の接続を簡素化します。以下を `~/.ssh/config` に追加します。
```
Host my-space
HostName ..
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 | 拡張機能 |
| --- | --- |
| VS Code | 拡張機能、「リモート - SSH」を検索し、インストール (Microsoft による) を選択します。 |
| Kiro | 拡張機能、「リモート - SSH」を検索し、インストールを選択します |
| カーソル | 拡張機能、「リモート - SSH」を検索し、インストールを選択します |
#### IDE から接続する
1. **コマンドパレットを開き**、「リモート SSH: ホストに接続する」を選択します。
1. リストからワークスペースを選択します (ステップ 4 `~/.ssh/config`で使用）。
1. IDE はサーバーコンポーネントをワークスペースにインストールします (1 回、約 30 秒）。
1. リモートウィンドウが開き、IntelliSense、ターミナル、ファイルエクスプローラーなどのエディタ機能がすべて表示されます。
**VS Code でワークスペースファイルを開く**
VS Code で接続後、**ファイル**、**Open Folder** `/home/sagemaker-user` を選択してワークスペースファイルを直接開きます。
### キーの管理と取り消し
SSH キーを管理します。SSH キーは、自動有効期限のない存続期間の長い認証情報です。のキーは、明示的に削除するまでワークスペースへのアクセス`authorized_keys`を許可します。
#### キーをローテーションするには
キーを定期的にローテーションすることをお勧めします。
1. クライアントマシンで新しいキーペアを生成します。 `ssh-keygen -t ed25519 -f ~/.ssh/my-workspace-key-new`
1. ワークスペースに新しいパブリックキーを追加します (ステップ 2)。古いキーと新しいキーの両方が同時に機能します。
1. 新しいキーが機能することを確認します。 `ssh -p -i ~/.ssh/my-workspace-key-new sagemaker-user@`
1. ワークスペースターミナル`authorized_keys`の から古いキーを削除します。
```
# List current keys with line numbers
cat -n ~/.ssh/authorized_keys
# Remove a specific line (for example, line 1)
sed -i '1d' ~/.ssh/authorized_keys
```
#### プライベートキーが侵害された場合
すぐに行動してください。侵害されたキーは、 から削除するまでワークスペースへのフルアクセスを許可します`authorized_keys`。
1. ウェブブラウザアクセス (JupyterLab またはコードエディタ) を使用してワークスペースを開きます。手順については、「[ウェブブラウザアクセス](browser-access.md)」を参照してください。
1. 侵害されたキーを から削除します`authorized_keys`。
```
# View all authorized keys
cat ~/.ssh/authorized_keys
# Option A: Edit directly
nano ~/.ssh/authorized_keys
# Option B: Remove all keys and re-add only trusted ones
> ~/.ssh/authorized_keys
echo "ssh-ed25519 AAAA...new-trusted-key..." >> ~/.ssh/authorized_keys
```
1. 接続を試みて、侵害されたキーが機能しなくなったことを確認します。を受け取ります`Permission denied (publickey)`。
1. ウェブブラウザからのアクセスでワークスペースにアクセスできない場合は、クラスター管理者に連絡してポッドにエグゼクトし、`authorized_keys`直接クリアします。
#### ベストプラクティス
| 練習 | なぜ |
| --- | --- |
| ed25519 キーを使用する | RSA よりも短く、速く、安全 |
| プライベートキーでパスフレーズを使用する | キーの盗難から保護します。盗まれた場合でも、パスフレーズなしでキーを使用することはできません。 |
| デバイスごとに 1 つのキー | 他のデバイスに影響を与えずに単一のデバイスのアクセスを取り消しやすい |
| プライベートキーを共有しない | 各ユーザーとデバイスには独自のキーペアが必要です |
| authorized\_keys 定期的に確認する | 使用しなくなったデバイスのキーを削除する |
## 直接 SSH アクセスの取り消し
Direct SSH を無効にした後にオープンセキュリティグループルールを離れないようにするには、3 つのステップをすべて順番に実行します。ステップ 2 はスキップしないでください。
**アクセスを取り消す前にユーザーに通知する**
アクセスを取り消す前にユーザーに通知します。ExternalDNS は、ステップ 3 から約 30 秒以内に DNS レコードを削除し、新しい接続をブロックします。
### ステップ 1: Helm チャートで を無効にする
アドオン設定ファイルから `directSSH`セクションを完全に削除します。キーがない場合、Helm はデフォルトで `false` `directSSH.enabled`になります。
```
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
...
# directSSH section removed
```
または、明示的に を設定します`enabled: false`。
```
directSSH:
enabled: false
```
### ステップ 2: セキュリティグループのインバウンドルールを削除する
```
# Find the rule ID
aws ec2 describe-security-group-rules \
--filters Name=group-id,Values= \
--query 'SecurityGroupRules[?IpProtocol==`tcp` && FromPort==``].[SecurityGroupRuleId,CidrIpv4]' \
--output table \
--region
# Remove the rule
aws ec2 revoke-security-group-ingress \
--group-id \
--security-group-rule-ids \
--region
```
### ステップ 3: クラスターに適用する
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
このコマンドを実行すると、すべてのワークスペースのヘッドレスサービスが削除されます。ExternalDNS は、約 30 秒以内に Route 53 A レコードを削除します。ExternalDNS がレコードを削除すると、新しい SSH 接続はワークスペースのホスト名を解決できなくなります。
### 失効後にどうなるか
| コンポーネント | 失効後の状態 |
| --- | --- |
| DNS レコード | ExternalDNS は、約 30 秒以内にそれらを削除します。新しい接続ではワークスペースのホスト名を解決できません。 |
| SG インバウンドルール | ステップ 2 の後に閉じます。ポートに到達するネットワークパスはありません。 |
| 新しい SSH 接続 | ブロックされました。ホスト名は解決されなくなり、SG ルールはポートを閉じます。 |
| ワークスペースデータ (PVC) | 影響を受けません。PVC は、ファイル、 authorized\_keys、ホストキーを保持します。 |
## トラブルシューティング
| 症状 | 原因 | Fix |
| --- | --- | --- |
| NXDOMAIN | DNS が解決されない | ホストゾーンが存在すること、VPC が関連付けられていること、ExternalDNS が実行されていることを確認する |
| Connection timed out | SG ブロック: ルールが間違った SG に追加されているか、完全に欠落しています | インスタンスグループOverrideVpcConfigを確認します (管理者ステップ 1)。TCP インバウンドルールがソース CIDR をカバーしていることを確認します。 |
| Connection refused | sshd が実行されていない | チェックスペースが実行中状態であり、有効directSSHになっている |
| Permission denied (publickey) | キーが にありません authorized\_keys | ウェブブラウザアクセスまたは kubectl を使用してパブリックキーを追加する (エンドユーザーステップ 2) |
| Host key changed 警告 | スペースが再作成されました (新しいポッド、新しいホストキー) | クライアントマシンで: ssh-keygen -R 再接続する |
| Stale DNS records after space deletion | で実行される ExternalDNS --policy=upsert-only | ExternalDNS デプロイを に更新--policy=syncし、 を追加します--txt-owner-id=。既存の古いレコードを手動でクリーンアップします。 aws route53 list-resource-record-sets --hosted-zone-id |
| IDE:「接続を確立できませんでした」 | sshd はまだ準備ができていません | ワークスペースの作成後 60～90 秒待ってから再試行する |
| IDE: 「VS Code Server のインストール」でハングします | WorkSpace にインターネットアクセスがない | ワークスペースは、最初の接続時に外部ホストから VS Code サーバーバイナリをダウンロードします。ワークスペースがエアギャップの場合は、管理者にお問い合わせください。 |
| IDE: Permission denied | IdentityFile パスの不一致 | ターミナル SSH が最初に機能することを確認し、 で IdentityFile を確認します。 \~/.ssh/config |
| IDE: アイドル状態の後に接続が切断される | キープアライブが設定されていません | ServerAliveCountMax 3 に ServerAliveInterval 15と を追加する \~/.ssh/config |
## (オプション) 前提条件の設定
このセクションは、ウェブブラウザアクセスがまだ有効になっていない場合、または ExternalDNS 設定を確認または更新する場合にのみ使用します。
### ゼロからのインストール
ウェブブラウザへのアクセスがまだ設定されていない場合は、Direct SSH を有効にする前に以下が必要です。
1. **Route 53 ホストゾーン** — 所有しているドメインまたはサブドメインで、Route 53 に登録されている
1. **外部 DNS** — EKS アドオンを介してデプロイされ、Route 53 アクセス許可を持つ IAM ロール
1. **AWS Load Balancer Controller** — ウェブブラウザアクセス (ALB 進入) を使用する場合に必要です。HyperPod 固有のインストールに関する注意事項については、「」を参照してください[AWS Load Balancer Controller: HyperPod vpcId の要件](#direct-ssh-appendix-lbc)。
1. **VPC 接続** — クライアントマシンから VPC への VPN または Direct Connect
その他の依存関係とウェブブラウザのアクセス設定手順については、「」を参照してください[SageMaker AI Spaces アドオンをインストールする](operator-install.md)。
### AWS Load Balancer Controller: HyperPod vpcId の要件
standard AWS Load Balancer Controller のインストールドキュメントには、 `vpcId`パラメータは記載されていません。HyperPod クラスターで を省略`vpcId`すると、インストールが失敗します。明示的に指定する必要があります。
VPC ID を取得します。
```
aws sagemaker describe-cluster \
--cluster-name \
--region \
--query 'VpcConfig.VpcId' \
--output text
```
必要な HyperPod パラメータを使用して をインストールします。
```
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName= \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set enableServiceMutatorWebhook=false \
--set vpcId=
```
| パラメータ | HyperPod で が必要な理由 |
| --- | --- |
| vpcId | HyperPod VPC はコントローラーによって自動検出できません。インストールは失敗します。 |
| enableServiceMutatorWebhook=false | ウェブフックの変更が HyperPod のサービス設定と競合する |
| serviceAccount.create=false | サービスアカウントは、インストール前に正しい IRSA または Pod Identity 注釈で事前に作成する必要があります |
このコマンドを実行する前に、適切な IAM ロール注釈を使用してサービスアカウント (aws-load-balancer-controller) を作成します。IAM ポリシーとサービスアカウントの作成手順の詳細については、[「Amazon EKS ユーザーガイド」の「Amazon EKS Load Balancer Controller IRSA のセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html)」を参照してください。
### ExternalDNS 設定
ExternalDNS は、Kubernetes サービスと DNS プロバイダーを同期します。本番環境で Amazon Route 53 で使用する場合は、次の設定で ExternalDNS を設定します。
**ExternalDNS には同期ポリシーが必要です**
ExternalDNS は で設定する必要があります`--policy=sync`。
デフォルトでは、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= # restricts ExternalDNS to your hosted zone only
--policy=sync # enables deletion of stale records on space deletion
--txt-owner-id= # identifies which records this ExternalDNS instance owns
```
上記の引数で、次の値を置き換えます。
+ `` — Amazon Route 53 プライベートホストゾーンドメイン (例: `workspaces.internal`)
+ `` — EKS クラスター名 (例: `my-hyperpod-cluster`)
現在の 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'
```