For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

AWS Bedrock AgentCore のサポート付きで、Amazon EKS クラスターに Solo Enterprise for agentregistry をインストールします。

Amazon EKS クラスターに Solo Enterprise for agentregistry をインストールします。このガイドでは、標準の Kubernetes インストールと比べて EKS インストールで追加に必要となる AWS インフラストラクチャを扱います。これには、OTel コレクター NLB 用の AWS Load Balancer Controller と、レジストリサーバーがユーザーのアカウントに到達するために使用する AWS ID が含まれます。

このガイドではインストールのみをセットアップします。AWS Bedrock AgentCore など特定のランタイムに対する権限は、インストール後にそのランタイムを接続するときに付与されます。そのため、再インストールせずにランタイムを追加、変更、削除できます。AgentCore の場合は、このガイドを完了した後に AWS Bedrock AgentCore に接続する に進みます。

始める前に

1. 次の CLI をインストールします。

   • helm: Install Helm charts。

• kubectl: Kubernetes クラスターを操作します。
  • aws: Interact とともに AWS。
  • eksctl: EKS で IAM サービスアカウントを作成します。

2. OIDC プロバイダーとして Keycloak または Microsoft Entra ID をセットアップします。次の環境変数が設定されていることを確認します。

   echo "KEYCLOAK_ISSUER: $KEYCLOAK_ISSUER"
   echo "AR_BACKEND_SECRET: $AR_BACKEND_SECRET"

   echo "OIDC_ISSUER: $OIDC_ISSUER"
   echo "AR_APP_ID: $AR_APP_ID"
   echo "AR_SCOPE: $AR_SCOPE"
   echo "AR_ADMIN_GROUP_ID: $AR_ADMIN_GROUP_ID"

3. Solo Enterprise for agentregistry のライセンスキーを環境変数に保存します。キーを取得するには、アカウント担当者にお問い合わせください。シークレットでキーを指定するなど、その他のオプションについては、ライセンスを参照してください。

   echo "KEYCLOAK_ISSUER: $KEYCLOAK_ISSUER"
   echo "AR_BACKEND_SECRET: $AR_BACKEND_SECRET"

4. Amazon EKS クラスターを作成するか、既存のクラスターを使用します。クラスターの作成方法について詳しくは、EKS のドキュメントを参照してください。クラスターの詳細を環境変数として保存します。

   echo "OIDC_ISSUER: $OIDC_ISSUER"
   echo "AR_APP_ID: $AR_APP_ID"
   echo "AR_SCOPE: $AR_SCOPE"
   echo "AR_ADMIN_GROUP_ID: $AR_ADMIN_GROUP_ID"

Step 1: Install the AWS Load Balancer Controller

Solo Enterprise for agentregistry は、OpenTelemetry コレクターを内部 Network Load Balancer (NLB) として公開します。これにより、VPC 内の AgentCore ランタイムにデプロイされたエージェントが、テレメトリーをレジストリに送り返せるようになります。この NLB のプロビジョニングと管理は AWS Load Balancer Controller が行います。コントローラーがすでにクラスターにインストールされている場合は、ステップ 2 に進んでください。

1. OIDC プロバイダーをクラスターに関連付けます。これは、コントローラーが AWS API を呼び出すために使用する IAM Roles for Service Accounts (IRSA) を利用するために必要です。

   eksctl utils associate-iam-oidc-provider \
     --region $AWS_REGION \
     --cluster $EKS_CLUSTER_NAME \
     --approve

2. コントローラーに必要な権限を付与する IAM ポリシーをダウンロードし、アカウントにポリシーを作成します。

   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json
   aws iam create-policy \
     --policy-name AWSLoadBalancerControllerIAMPolicy \
     --policy-document file://iam_policy.json

3. IAM サービスアカウントを作成し、ポリシーをアタッチします。

   eksctl create iamserviceaccount \
     --cluster=$EKS_CLUSTER_NAME \
     --namespace=kube-system \
     --name=aws-load-balancer-controller \
     --role-name AmazonEKSLoadBalancerControllerRole \
     --attach-policy-arn=arn:aws:iam::${AWS_ACCOUNT_ID}:policy/AWSLoadBalancerControllerIAMPolicy \
     --approve \
     --region $AWS_REGION

4. Install the controller。

   helm repo add eks https://aws.github.io/eks-charts
   helm repo update eks
   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

5. コントローラーが実行中であることを確認します。

   kubectl -n kube-system rollout status deployment/aws-load-balancer-controller

ステップ 2: レジストリサーバー用の AWS アクセスをセットアップする

Solo Enterprise for agentregistry サーバーは、2 段階で Bedrock AgentCore に到達します。まず、このステップで作成する ID として AWS に認証します。次に、その ID を使用して別の IAM ロール AgentRegistryAccessRole-<suffix> を引き受けます。このロールには AgentCore のすべての権限が含まれます。このロールは、後で Solo Enterprise for agentregistry を AWS Bedrock AgentCore ランタイムに接続する ときに作成します。サーバーは、このロールから返された一時認証情報を使用してすべての AgentCore 呼び出しを行います。

ロールを引き受けて AgentCore 環境にアクセスするための認証情報を取得する ID 形式として、次のいずれかを選択できます。

• IAM ユーザー認証情報: 静的なアクセスキーとシークレットを持つ専用 IAM ユーザーを作成し、インストール時に Helm チャートへ渡します。チャートはキーを Kubernetes シークレットに保存し、サーバーは起動時にそれを読み取ります。この設定は簡単ですが、本番環境には推奨されません。
• EKS Pod Identity: EKS Pod Identity エージェントが、短期間でローテーションされる認証情報としてレジストリサーバー Pod に注入する IAM ロールです。AWS 認証情報はクラスター内のシークレットとして保存されないため、本番環境に推奨される設定です。

この時点では AgentCore ロールの正確な名前はまだ分かりません。CloudFormation テンプレートは、テンプレート作成時に生成される 6 桁のランダムな 16 進文字からなるサフィックスを付けて、AgentRegistryAccessRole-<suffix> という名前を付けます。そのため、次のポリシーでは、AgentRegistryAccessRole-* という命名パターンに一致するアカウント内の任意のロールをレジストリサーバーが引き受けられるようにします。--role-name オプションでカスタム名を付ける予定がある場合は、代わりにその名前に一致するよう Resource フィールドを変更してください。

1. レジストリサーバーが AgentRegistryAccessRole-<suffix> ロールを引き受けられるようにするポリシードキュメントを作成します。

   sts:TagSession 権限は EKS Pod Identity オプションに必要です。Pod Identity エージェントは、クラスター名や Kubernetes ネームスペースなどの セッションタグを、Pod に注入する認証情報へ自動的に付与します。これらのタグは推移的であるため、レジストリサーバーが AgentCore ロールを引き受けるときに AWS がタグを引き継ぎます。この権限がないと assume-role 呼び出しは拒否されます。静的アクセスキーにはセッションタグがないため、この権限は IAM ユーザー認証情報 オプションには影響しません。

   export AGENTREGISTRY_LICENSE_KEY=<license_key>

2. AWS IAM でマネージドポリシーを作成します。

   aws iam create-policy \
     --policy-name AgentRegistryAssumeRoleAccess \
     --policy-document file://agentregistry-assume-role-policy.json

3. ポリシーを IAM プリンシパルにアタッチします。使用する AWS 認証方法を選択してください。

   1. Solo Enterprise for agentregistry 専用の IAM ユーザーを作成します。

      aws iam create-user --user-name agentregistry-deployer

   2. ポリシーをユーザーにアタッチします。

      aws iam attach-user-policy \
        --user-name agentregistry-deployer \
        --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/AgentRegistryAssumeRoleAccess

   3. ユーザーのアクセスキーを作成し、認証情報を環境変数として保存します。

      ACCESS_KEY_OUTPUT=$(aws iam create-access-key --user-name agentregistry-deployer)
      export AWS_ACCESS_KEY_ID=$(echo $ACCESS_KEY_OUTPUT | jq -r '.AccessKey.AccessKeyId')
      export AWS_SECRET_ACCESS_KEY=$(echo $ACCESS_KEY_OUTPUT | jq -r '.AccessKey.SecretAccessKey')
      echo "AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID"

   1. EKS Pod Identity エージェントのアドオンをインストールします。

      aws eks create-addon \
        --cluster-name $EKS_CLUSTER_NAME \
        --addon-name eks-pod-identity-agent \
        --region $AWS_REGION

   2. EKS Pod がロールを引き受けることを許可する信頼ポリシードキュメントを保存します。

   export EKS_CLUSTER_NAME= export AWS_REGION= export AWS_ACCOUNT_ID=$(aws sts get-caller-identity –query Account –output text) echo “EKS_CLUSTER_NAME: $EKS_CLUSTER_NAME” echo “AWS_REGION: $AWS_REGION” echo “AWS_ACCOUNT_ID: $AWS_ACCOUNT_ID”

   3. Create the IAM role。
   
      ```sh
   export AGENTREGISTRY_ROLE_NAME="agentregistry-pod-identity-role"
   aws iam create-role \
     --role-name "$AGENTREGISTRY_ROLE_NAME" \
     --assume-role-policy-document file://agentregistry-trust-policy.json
   export AGENTREGISTRY_ROLE_ARN=$(aws iam get-role \
     --role-name "$AGENTREGISTRY_ROLE_NAME" \
     --query 'Role.Arn' --output text)
   echo "AGENTREGISTRY_ROLE_ARN: $AGENTREGISTRY_ROLE_ARN"
   ```
   4. ポリシーをロールにアタッチします。
   
      ```sh
   aws iam attach-role-policy \
     --role-name "$AGENTREGISTRY_ROLE_NAME" \
     --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/AgentRegistryAssumeRoleAccess
   ```
   5. ロールを `agentregistry-system` ネームスペースの `agentregistry-enterprise` サービスアカウントに関連付けます。EKS Pod Identity エージェントは、レジストリ Pod の起動時にこの関連付けを使用して認証情報を注入します。
   
      ```sh
   aws eks create-pod-identity-association \
     --cluster-name "$EKS_CLUSTER_NAME" \
     --namespace agentregistry-system \
     --service-account agentregistry-enterprise \
     --role-arn "$AGENTREGISTRY_ROLE_ARN" \
     --region "$AWS_REGION"
   ```

Step 3: Install

Helm を使用して、EKS クラスターに Solo Enterprise for agentregistry をインストールします。OIDC プロバイダーと前のステップで設定した AWS 認証方式に一致するタブを選択してください。

helm upgrade --install agentregistry \
  oci://us-docker.pkg.dev/solo-public/agentregistry-enterprise/helm/agentregistry-enterprise \
  --version 2026.9.0 \
  --namespace agentregistry-system \
  --create-namespace \
  --set licensing.createSecret=true \
  --set licensing.licenseKey=$AGENTREGISTRY_LICENSE_KEY \
  --set oidc.issuer=$KEYCLOAK_ISSUER \
  --set oidc.clientId=ar-backend \
  --set oidc.clientSecret=$AR_BACKEND_SECRET \
  --set oidc.publicClientId=ar-ui \
  --set oidc.roleClaim=Groups \
  --set oidc.superuserRole=admins \
  --set aws.enabled=true \
  --set-string aws.region="${AWS_REGION}" \
  --set-string aws.accessKeyId="${AWS_ACCESS_KEY_ID}" \
  --set-string aws.secretAccessKey="${AWS_SECRET_ACCESS_KEY}" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-nlb-target-type=ip" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-scheme=internal" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-type=external" \
  --set telemetry.service.type=LoadBalancer

helm upgrade --install agentregistry \
  oci://us-docker.pkg.dev/solo-public/agentregistry-enterprise/helm/agentregistry-enterprise \
  --version 2026.9.0 \
  --namespace agentregistry-system \
  --create-namespace \
  --set licensing.createSecret=true \
  --set licensing.licenseKey=$AGENTREGISTRY_LICENSE_KEY \
  --set oidc.issuer=$KEYCLOAK_ISSUER \
  --set oidc.clientId=ar-backend \
  --set oidc.clientSecret=$AR_BACKEND_SECRET \
  --set oidc.publicClientId=ar-ui \
  --set oidc.roleClaim=Groups \
  --set oidc.superuserRole=admins \
  --set aws.enabled=true \
  --set aws.usePodIdentity=true \
  --set-string aws.region="${AWS_REGION}" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-nlb-target-type=ip" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-scheme=internal" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-type=external" \
  --set telemetry.service.type=LoadBalancer

helm upgrade --install agentregistry \
  oci://us-docker.pkg.dev/solo-public/agentregistry-enterprise/helm/agentregistry-enterprise \
  --version 2026.9.0 \
  --namespace agentregistry-system \
  --create-namespace \
  --set licensing.createSecret=true \
  --set licensing.licenseKey=$AGENTREGISTRY_LICENSE_KEY \
  --set oidc.issuer=$OIDC_ISSUER \
  --set oidc.clientId=$AR_APP_ID \
  --set oidc.publicClientId=$AR_APP_ID \
  --set oidc.additionalScopes=$AR_SCOPE \
  --set oidc.roleClaim=groups \
  --set oidc.superuserRole=$AR_ADMIN_GROUP_ID \
  --set aws.enabled=true \
  --set-string aws.region="${AWS_REGION}" \
  --set-string aws.accessKeyId="${AWS_ACCESS_KEY_ID}" \
  --set-string aws.secretAccessKey="${AWS_SECRET_ACCESS_KEY}" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-nlb-target-type=ip" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-scheme=internal" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-type=external" \
  --set telemetry.service.type=LoadBalancer

helm upgrade --install agentregistry \
  oci://us-docker.pkg.dev/solo-public/agentregistry-enterprise/helm/agentregistry-enterprise \
  --version 2026.9.0 \
  --namespace agentregistry-system \
  --create-namespace \
  --set licensing.createSecret=true \
  --set licensing.licenseKey=$AGENTREGISTRY_LICENSE_KEY \
  --set oidc.issuer=$OIDC_ISSUER \
  --set oidc.clientId=$AR_APP_ID \
  --set oidc.publicClientId=$AR_APP_ID \
  --set oidc.additionalScopes=$AR_SCOPE \
  --set oidc.roleClaim=groups \
  --set oidc.superuserRole=$AR_ADMIN_GROUP_ID \
  --set aws.enabled=true \
  --set aws.usePodIdentity=true \
  --set-string aws.region="${AWS_REGION}" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-nlb-target-type=ip" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-scheme=internal" \
  --set-string "telemetry.service.annotations.service\.beta\.kubernetes\.io/aws-load-balancer-type=external" \
  --set telemetry.service.type=LoadBalancer

Step 4: Verify

Solo Enterprise for agentregistry の Pod が起動して実行中であることを確認します。

kubectl get pods -n agentregistry-system

出力例:

NAME                                                            READY   STATUS    RESTARTS   AGE
agentregistry-clickhouse-shard0-0                               1/1     Running   0          51s
agentregistry-enterprise-postgresql-764898cbff-l8477            1/1     Running   0          51s
agentregistry-enterprise-server-7d56d5b698-zxj8k                1/1     Running   0          51s
agentregistry-enterprise-telemetry-collector-6ff77cbc4f-fgzwk   1/1     Running   0          51s

レジストリにアクセスする

Solo Enterprise for agentregistry サーバーをポート 12121 でポートフォワードします。レジストリサービスはデフォルトでは外部に公開されないため、ローカルマシンから接続するにはポートフォワードが必要です。arctl CLI と UI はどちらも、レジストリのエンドポイントとしてデフォルトで http://localhost:12121 を使用します。

kubectl -n agentregistry-system port-forward svc/agentregistry-enterprise-server 12121:12121

Solo Enterprise for agentregistry UI を開き、ユーザー名 admin-user、パスワード password でログインします。ダッシュボードが表示されることを確認します。

Solo Enterprise for agentregistry UI を開き、Entra ガイドの割り当てステップで割り当てた管理者グループのメンバーとしてログインします。login.microsoftonline.com にリダイレクトされた後、http://localhost:12121/callback に戻ります。ダッシュボードが表示されることを確認します。

Step 6: Install the arctl CLI

arctl CLI は、Solo Enterprise for agentregistry で AI アーティファクトを管理するための主要なツールです。AI アーティファクトの作成、公開、デプロイに使用します。arctl コマンドを実行する前に、有効なアクセストークンを取得するために、CLI を OIDC プロバイダーで認証する必要があります。

1. arctl CLI をダウンロードしてインストールします。

   curl -sSL https://storage.googleapis.com/agentregistry-enterprise/install.sh | ARCTL_VERSION=v2026.9.0 sh
   export PATH=$HOME/.arctl/bin:$PATH

2. OIDC プロバイダーに一致するフローでレジストリにログインします。

   対話型のデバイス認可フローと、CI/CD 用のユーザー名とパスワード認証情報フローのどちらかを選択します。

   ターミナルからの対話型ログインには、このフローを使用します。CLI は ar-cli-interactive パブリッククライアントを使用して、デバイス認可付与フロー を開始します。このフローでは、ブラウザーで承認するための URL とワンタイムコードが出力されます。

   1. Keycloak の発行者と ar-cli-interactive クライアントを使用するように CLI を設定します。その後、Solo Enterprise for agentregistry にログインします。

      export OIDC_ISSUER=$KEYCLOAK_ISSUER
      export OIDC_CLIENT_ID=ar-cli-interactive
      arctl user login

      出力例:

      To complete the login process, please:
       1. Open: http://172.18.0.13:8080/realms/agentregistry/device
       2. Enter the code: SYSQ-SNSP
       - or go to: http://172.18.0.13:8080/realms/agentregistry/device?user_code=SYSQ-SNSP
      

   2. Web ブラウザーで URL を開き、admin-user ユーザー名と password パスワードで Keycloak にログインします。ブラウザーでコードを確認すると、Keycloak は CLI セッション用のアクセストークンを発行します。認可が完了すると、CLI はトークンをシステムのキーチェーンに保存するため、トークンが期限切れになるまで再度ログインする必要はありません。

   CI/CD パイプラインなど、特定のユーザー ID が必要なスクリプト化されたログインには、このフローを使用します。CLI は ar-cli-password パブリッククライアントを使用し、ユーザー名とパスワードを直接アクセストークンと交換します。

   1. admin-user/password の認証情報で Solo Enterprise for agentregistry にログインします。

      export OIDC_ISSUER=$KEYCLOAK_ISSUER
      arctl user login \
        --oidc-flow=password-credentials \
        --oidc-client-id=ar-cli-password \
        --oidc-username=admin-user \
        --oidc-password=password

   2. アクセストークンを ARCTL_API_TOKEN 環境変数に保存します。

      export ARCTL_API_TOKEN=$(arctl user info --show-tokens | jq -r .access_token)

   ターミナルからの対話型ログインには、このフローを使用します。CLI は Entra アプリ登録のクライアント ID を使用し、ブラウザーで承認するための URL と 1 回限りのコードを出力する デバイス認可グラントフローを開始します。Microsoft はこのグラントタイプを推奨していないため、Entra にはユーザー名とパスワード認証情報フローに相当するものがないことに注意してください。

   1. Entra アプリ登録のクライアント ID と発行者を使用するよう CLI を設定します。Entra は要求されたスコープでトークンのオーディエンスをスコープするため、--oidc-scope フラグでアプリ所有のスコープを渡す必要があります。

      export OIDC_ISSUER=$OIDC_ISSUER
      export OIDC_CLIENT_ID=$AR_APP_ID
      arctl user login --oidc-scope "${AR_SCOPE}"

   2. Web ブラウザーで URL を開き、Entra のセットアップ時に割り当てた管理者グループのメンバーとしてサインインします。認可が完了すると、CLI はトークンをシステムキーチェーンに保存するため、有効期限が切れるまで再ログインする必要はありません。

3. 次のことを確認します you できます run arctl commands。

   arctl user whoami

   出力例:

   FIELD       VALUE
   Subject     8d7ffd9c-1f75-459a-b900-bfa4f5e3b492
   Email       admin-user@example.com
   Issuer      http://172.18.0.10:8080/realms/agentregistry
   Superuser   true (overrides role-based permission checks)
   
   ROLE     STATUS
   admins   no explicit permissions configured
   

   Note

CLI で 401 エラーが表示される場合は、以前に ARCTL_API_TOKEN 環境変数にトークンを保存している可能性があります。この環境変数は、CLI のログインフローで取得したトークンよりも優先されます。unset ARCTL_API_TOKEN を実行してから、CLI のログインフローをやり直してください。

次のステップ