セキュリティポリシー顧客情報の要件製品の使用要件アーキテクチャの要件 Helm チャート構造の要件コンテナ製品の使用手順 Amazon EKS アドオン製品の要件

のコンテナベースの製品要件 AWS Marketplace

AWS Marketplace は、のすべてのコンテナベースの製品とサービスについて、次の要件を維持します AWS Marketplace。これらの要件は、お客様に安全、安心、および信頼できるカタログを提供するのに役立ちます。また、販売者には、特定の商品のニーズを満たすために、必要に応じて追加の規制やプロトコルの導入を検討するよう奨励しています。

すべての製品とその関連メタデータは、送信時にレビューされ、現在の AWS Marketplace ポリシーを満たしているか超えているかが確認されます。これらのポリシーは、進化するセキュリティガイドラインに合わせて定期的に更新されます。 AWS Marketplace は製品を継続的にスキャンして、既存の出品がこれらの要件に対する変更を引き続き満たしていることを確認します。製品がコンプライアンス違反になった場合、 AWS Marketplace は販売者に連絡して、新しい基準を満たすように製品を更新します。場合によっては、問題が解決されるまで、新しいサブスクライバーが製品を一時的に使用できなくなることがあります。このプロセスは、すべてのユーザーの AWS Marketplace プラットフォームのセキュリティと信頼性を維持するのに役立ちます。

セキュリティポリシー

すべてのコンテナベースの製品は、以下の要件を満たしている必要があります。

コンテナイメージには、既知の脆弱性、マルウェア、またはEnd-of-Life (EoL) ソフトウェアパッケージとオペレーティングシステムを含めることはできません。
コンテナは、 AWS サービスにアクセスするための AWS 認証情報をリクエストしてはいけません。製品が AWS サービスにアクセスする必要がある場合は、次のいずれかを使用する必要があります。
- Amazon Elastic Kubernetes Service (Amazon EKS) ワークロード用のサービスアカウントの IAM ロール。
- Amazon Elastic Container Service (Amazon ECS) ワークロード用のタスクの IAM ロール。
コンテナベースの製品の実行には最小特権のみが必要です。詳細については、「Amazon Elastic Container Service のセキュリティ」および「Amazon EKS のセキュリティ」を参照してください。
コンテナイメージは、デフォルトで非ルートの権限で実行するように設定する必要があります。
コンテナには、システムユーザーとサービス、プライベートキー、認証情報などのパスワード (ハッシュ化も含む) などのハードコードされたシークレットを含めることはできません。
コンテナ内で実行されているサービスの認証では、起動時にユーザーがパスワードを生成、リセット、定義しても、パスワードベースの認証を使用しないでください。null および空白のパスワードも許可されません。
コンテナイメージには、サポートされていないアーキテクチャ (in-to-Attestation Framework メタデータなど) を持つレイヤーを含めることはできません。

顧客情報の要件

すべてのコンテナベースの製品は、次の顧客情報の要件に従う必要があります。

ソフトウェアは、所有しているライセンスの持ち込み (BYOL) で要求される場合を除き、顧客の知識と明示的な同意なしに顧客データを収集、またはエクスポートしてはなりません。顧客データを収集またはエクスポートするアプリケーションは、以下のガイドラインに従う必要があります。
- 顧客データの収集は、セルフサービスで、自動化され、安全である必要があります。購入者は、販売者がソフトウェアの導入を承認するのを待つ必要はありません。
- 顧客データの収集は、 AWS Marketplace の利用規約 AWS、AWS サービス条件、AWS プライバシー通知、AWS カスタマーアグリーメントなど、との契約と一致する必要があります。
- 支払情報は収集してはなりません。

製品の使用要件

すべてのコンテナベースの製品は、次の製品使用の要件に従う必要があります。

販売者は完全に機能する商品のみを出品できます。トライアルまたは評価を目的としたベータ版またはプレリリース版の製品は許可されていません。商用ソフトウェアの開発者エディション、コミュニティエディション、BYOL エディションは、販売者が無料エディションの提供から 90 AWS Marketplace 日以内に同等の有料バージョンをに提供した場合、サポートされます。
コンテナベースの製品のすべての使用説明書には、コンテナベースの製品をデプロイするためのすべての手順が記載されている必要があります。使用説明書には、上の対応するコンテナイメージを指すコマンドとデプロイリソースが記載されている必要があります。 AWS Marketplace
コンテナベースの製品には、サブスクライバーがソフトウェアを使用するために必要なすべてのコンテナイメージが含まれている必要があります。さらに、コンテナベースの製品では、ユーザーが外部からのイメージ AWS Marketplace （サードパーティーリポジトリからのコンテナイメージなど) を使用して製品を起動する必要はありません。
コンテナとそのソフトウェアはセルフサービス方式でデプロイ可能である必要があり、追加の支払い方法や費用を必要としないものでなければなりません。デプロイ時に外部に依存する必要のあるアプリケーションは、以下のガイドラインに従う必要があります。
- 要件は、リストの説明または使用説明書に明記する必要があります。例えば、この製品を正しくデプロイするにはインターネット接続が必要です。デプロイ時に以下のパッケージがダウンロードされます。<パッケージのリスト>。
- 販売者は、すべての外部依存関係を使用し、その可用性とセキュリティを確保する責任を負います。
- 外部依存関係が使用できなくなった場合は、製品 AWS Marketplace もから削除する必要があります。
- 外部依存関係によって追加の支払い方法や費用が必要になってはいけません。
購入者の直接の管理下にない外部リソース (外部 API、販売者または第三者が管理する AWS のサービスなど) への継続的な接続を必要とするコンテナは、以下のガイドラインに従う必要があります。
- 要件は、リストの説明または使用説明書に明記する必要があります。例えば、この製品には継続的なインターネット接続が必要です。正しく機能するには、以下の継続的な外部サービスが必要です。<リソースのリスト>。
- 販売者は、すべての外部リソースを使用し、その可用性とセキュリティを確保する責任を負います。
- 外部リソースが使用できなくなった場合は、製品 AWS Marketplace もから削除する必要があります。
- 外部リソースは追加の支払い方法や費用を必要とせず、接続の設定を自動化する必要があります。
製品ソフトウェアとメタデータには、 AWS Marketplaceでは利用できない他のクラウドプラットフォーム、追加の製品、またはアップセルサービスにユーザーをリダイレクトする言葉を含めてはいけません。
製品が別の製品または別の ISV 製品のアドオンである場合、製品の説明には、それが他の製品の機能を拡張するものであり、これがないと製品の有用性が非常に限られることを明記する必要があります。例えば、この製品は <製品名> の機能を拡張するものであり、それがなければ、この製品の実用性は非常に限られています。<製品名> は、このリストのすべての機能を利用するには、独自のライセンスが必要な場合がありますのでご注意ください。

アーキテクチャの要件

すべてのコンテナベースの製品は、次のアーキテクチャの要件に従う必要があります。

のソースコンテナイメージは、が所有する Amazon Elastic Container Registry (Amazon ECR) リポジトリにプッシュ AWS Marketplace する必要があります AWS Marketplace。これらのリポジトリは、コンテナ製品リストごとにサーバー製品の下の AWS Marketplace 管理ポータルに作成できます。
コンテナイメージは Linux ベースである必要があります。
有料のコンテナベースの製品は Amazon ECS、Amazon EKS、または AWS Fargate にデプロイできる必要があります。
契約料金でと統合されている有料コンテナベースの製品は、Amazon EKS、Amazon ECS、Amazon EKS Anywhere AWS Fargate、Amazon ECS Anywhere、Red Hat OpenShift Service on AWS (ROSA)、オンプレミスのセルフマネージド Kubernetes クラスター、または Amazon Elastic Compute Cloud にデプロイ AWS License Manager する必要があります。
Helm チャート製品の場合、コンテナイメージリファレンスは、クロスリージョンデプロイをサポートするためにHelm チャート構造の要件、に従って構造化する必要があります。

Helm チャート構造の要件

に送信されるすべての Helm チャート製品は、 AWS リージョン間で適切なリージョン化とデプロイを確保するために、次の構造要件 AWS Marketplace に従う必要があります。

コンテナイメージリファレンスはvalues.yaml、ファイル内でのみ定義する必要があり、Helm チャート内の他のファイルではハードコードされません。これにより AWS Marketplace 、は製品を異なるリージョンにレプリケートするときに、これらのリファレンスを自動的に置き換えることができます。
values.yaml ファイルは、以下を含むすべてのコンテナイメージ参照に変数を使用する必要があります。
- Repository URI
- Image name
- 必要に応じて、リポジトリと同じレベルのフィールドregistryと tagフィールドを含めて、イメージリファレンスを構築できます。
Helm テンプレートは、標準の Helm テンプレート構文 (例: {{ .Values.image.repository }}:{{ .Values.image.tag }}) を使用してこれらの変数を参照する必要があります。
で定義されているイメージ参照をバイパスするテンプレートで条件付きロジックを使用しないでくださいvalues.yaml。
異なる AWS リージョンで Helm チャートをテストする場合は、でリージョンを変更すると、デプロイされたリソース内のすべてのイメージ参照values.yamlが正しく更新されることを確認します。

AWS Marketplace は、製品送信プロセス中に、すべてのコンテナイメージ参照が values.yaml ファイルで適切に定義されていることを検証します。これらの要件を満たさない製品は拒否されます。

例: Helm チャートでのコンテナイメージ参照のベストプラクティス

次の例は、Helm チャートでコンテナイメージ参照を構造化するアプローチを示しています。

values.yaml (推奨形式):


image:
  registry: "709825985650.dkr.ecr.us-east-1.amazonaws.com"
  repository: "accuknox/kubearmor"
  tag: "v1.1.1"

注記

の構造には上記のアプローチをお勧めしますがvalues.yaml、以下の代替方法も有効です。

values.yaml (代替形式):


image:
  repository: 709825985650.dkr.ecr.us-east-1.amazonaws.com/guance/datakit
  tag: 1.0

values.yaml (代替形式):


image:
  repository: 709825985650.dkr.ecr.us-east-1.amazonaws.com/guance/datakit:1.0

注記

デプロイテンプレートでは、以下の形式のみが有効な形式です。

デプロイテンプレート：


containers:
- name: kubearmor
  image: "{{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}"

アプローチが正しくない (使用しない):


containers:
- name: kubearmor
  image: "709825985650.dkr.ecr.us-east-1.amazonaws.com/accuknox/kubearmor:v1.1.1"

コンテナ製品の使用手順

コンテナ製品の使用説明書を作成するときは、「の AMI およびコンテナ製品の使用手順の作成 AWS Marketplace」の手順とガイダンスに従ってください。

Helm チャートの使用方法

Helm チャート製品の使用手順を作成する場合：

イメージリポジトリ、タグ、レジストリパラメータなど、設定可能なすべてのパラメータをvalues.yamlファイルに明確に文書化します。
Helm チャートのインストール時にこれらのパラメータを上書きする方法の例を示します。
チャートのインストール時に、以外のファイルを変更values.yamlしたり、--setパラメータを使用するようにユーザーに指示しないでください。
製品がコンテナイメージのリージョン化をどのように処理するかに関する情報を含めます。

Amazon EKS アドオン製品の要件

Amazon EKS アドオンは、Kubernetes アプリケーションをサポートする操作機能を提供するソフトウェアですが、アプリケーション固有のものではありません。例えば、Amazon EKS アドオンには、クラスターがネットワーク、コンピューティング、ストレージの基盤となる AWS リソースとやり取りできるようにするオブザーバビリティエージェントまたはKubernetesドライバーが含まれています。

コンテナ製品の販売者は、Amazon EKS を含むいくつかのデプロイオプションから選択できます。製品のバージョンをアドオンとして Amazon EKS AWS Marketplace アドオンカタログに公開できます。アドオンは、 AWS や他のベンダーが管理するアドオンの横に Amazon EKS コンソールに表示されます。購入者は、他のアドオンと同様に簡単にソフトウェアをアドオンとしてデプロイできます。

詳細については、Amazon EKS ユーザーガイドの Amazon EKS アドオンを参照してください。

コンテナ製品を AWS Marketplace アドオンとして準備する

コンテナ製品を AWS Marketplace アドオンとして公開するには、次の要件を満たしている必要があります。

コンテナ製品はで公開する必要があります AWS Marketplace。
コンテナ製品は AMD64 と ARM64 の両方のアーキテクチャに対応するように構築されている必要があります。
コンテナ製品で Bring Your Own License (BYOL) 料金モデルを使用してはなりません。

注記
BYOL は Amazon EKS アドオン配信ではサポートされていません。
すべてのコンテナイメージとチャートをマネージド Amazon ECR リポジトリにプッシュするなど、コンテナベースのすべての製品要件に従う必要があります。 Helm AWS Marketplace この要件には、nginx など、オープンソースイメージなどが含まれます。イメージとチャートは、Amazon ECR Public Gallery、Docker Hub、Quay などを含むがこれらに限定されない他の外部リポジトリではホストできません。
Helm charts - ソフトウェアをHelmグラフとして準備してパッケージ化します。Amazon EKS アドオンフレームワークは、Helmチャートを Kubernetes マニフェストに変換します。一部の Helm 機能は Amazon EKS システムではサポートされていません。次のリストは、Amazon EKS アドオンとしてソフトウェアをオンボーディングする前に満たす必要がある要件を示しています。このリストでは、すべての Helm コマンドが Helm バージョン 3.8.1 を使用します。
- すべての Capabilities オブジェクトがサポートされていますが、.APIVersions は例外です。.APIVersions は、組み込まれていないカスタム Kubernetes API ではサポートされていません。
- Release.Name および Release.Namespace オブジェクトのみがサポートされています。
- Helm はフッキングしますが、lookup 関数はサポートされません。
- すべての依存チャートは、メインの Helm チャート (リポジトリパス file:// で指定) に配置する必要があります。
- Helm チャートは、エラーなしで Helm Lint と Helm テンプレートを正常に渡す必要があります。コマンドは次のとおりです。
  - Helm Lint – helm lint helm-chart
    
    よくある問題には、親チャートのメタデータに宣言されていないグラフが含まれます。例: chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed
  - Helm テンプレート – helm template chart-name chart-location —set k8version=Kubernetes-version —kube-version Kubernetes-version —namespace addon-namespace —include-crds —no-hooks —f any-overriden-values
    
    —f フラグを使用してオーバーライドされた設定を渡します。
- すべてのコンテナバイナリを AWS Marketplace Amazon ECR リポジトリに保存します。マニフェストを作成するには、前述の Helm テンプレートコマンドを使用します。busybox や gcr イメージなどの外部イメージリファレンスのマニフェストを検索します。リクエストドロップダウンのリポジトリの追加オプションを使用して作成された AWS Marketplace Amazon ECR リポジトリに、依存関係とともにすべてのコンテナイメージをアップロードします。
カスタム設定 — デプロイ中にカスタム変数を追加できます。エンドユーザーエクスペリエンスを識別し、ソフトウェア aws_mp_configuration_schema.json に名前を付けて、Helm チャートを使用してラッパーにパッケージ化する方法の詳細については、「Amazon EKS アドオン: 詳細設定」を参照してください。

「$schema」キーワードによると、$schema は、有効なapplication/schema+json リソースを指し URI である必要があります。

このファイルは、パスワード、ライセンスキー、証明書などの機密情報を承認する必要があります。

シークレットと証明書のインストールを処理するには、エンドユーザーにアドオン後のインストール手順またはアドオン前のインストール手順を提供します。製品は、外部ライセンスに依存してはなりません。製品は、 AWS Marketplace エンタイトルメントに基づいて動作する必要があります。

aws_mp_configuration_schema.json の制限事項の詳細については、「アドオンプロバイダーのアドオン設定要件とベストプラクティス」を参照してください。
ソフトウェアがデプロイされる名前空間を特定して作成する – 製品の最初のリリースでは、テンプレート化された名前空間を追加して、ソフトウェアがデプロイされる名前空間を特定する必要があります。
カスタムリソース定義 (CRDs) – Amazon EKS アドオンフレームワークは、同じアドオンで適用された CRDs に基づく CRDs とカスタムリソース宣言のインストールをサポートしていません。アドオンにカスタムリソースがあり、CRDs に依存している場合は、次のいずれかを実行できます。
- CRD 定義を別のアドオン (個別の helm チャート) に分割し、実際のカスタムリソースのインストールを別のアドオンに分割するという 2 つのアドオンを発行します。 https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
- 追加の手動手順を含む単一のアドオンを発行する: CRDsにインストールする単一のアドオンを発行します。エンドユーザーが CRDs に依存するカスタムリソースを設定できるように、kubernetes マニフェストファイルとともに使用手順を提供します。
serviceAccount 該当する場合に を作成する – ソフトウェアがの有料ソフトウェアであるか、他のソフトウェアに接続 AWS Marketplace する必要がある場合は AWS のサービス、serviceAccountデフォルトでHelmグラフが作成されていることを確認してください。serviceAccount の作成が values.yaml ファイルのパラメータで処理された場合、パラメータ値を true に設定します。例えば、serviceAccount.create = true。これは、必要な権限をすでに取得している基本となるノードインスタンスから権限を継承してアドオンをインストールすることを顧客が選択する可能性があるため、必須です。Helm チャートが、serviceAccount を作成しない場合は、serviceAccount に権限を付与できません。
追跡可能なデプロイまたはデーモンセット – Helm チャートにデーモンセットまたはデプロイがあることを確認します。Amazon EKS アドオンフレームワークは、それらを使用して Amazon EKS リソースのデプロイを追跡します。追跡可能なデプロイまたはデーモンセットがない場合、アドオンでデプロイエラーが発生します。アドオンにデプロイやデーモンセットがない場合、例えば、アドオンが追跡不可能なカスタムリソースや Kubernetes ジョブをたくさんデプロイする場合は、ダミーデプロイまたはデーモンセットオブジェクトを追加します。
AMD および ARM アーキテクチャのサポート – 多くの Amazon EKS のお客様は、現在 ARM64 を使用して Graviton AWS インスタンスを使用しています。サードパーティーソフトウェアは両方のアーキテクチャをサポートしている必要があります。
のライセンスまたは計測 APIs と統合 AWS Marketplaceすると、複数の請求モデル AWS Marketplace がサポートされます。詳細については、「コンテナ製品の請求、計測、ライセンスの統合」を参照してください。PAYG メカニズムを使用して製品を販売する場合は、「AWS Marketplace Metering Service を使用したコンテナ製品のカスタム計測の設定」を参照してください。前払いモデルまたは契約モデルを使用して製品を販売する場合は、「を使用したコンテナ製品の契約料金 AWS License Manager」を参照してください。
ソフトウェアとすべてのアーティファクトと依存関係をアップロードする – Helm チャートは自己完結型でなければならず、GitHub などの外部ソースからの依存関係を必要としません。ソフトウェアに外部依存関係が必要な場合は、依存関係を同じ AWS Marketplace リスト内の AWS Marketplace プライベート Amazon ECR リポジトリにプッシュする必要があります。
ウェブサイトでデプロイ手順を提供する – 顧客が create-addon コマンドを使用してソフトウェアをデプロイする方法を特定するためのデプロイガイドをホストすることが推奨されます。

アドオンのアクセス許可/IAM ロール – から公開されたアドオンが AWS サービスにアクセス AWS Marketplace する必要がある場合、ソフトウェアにはサービスにアクセスするための IAM ポリシーで注釈が付けられた Kubernetes AWS サービスアカウントが必要です。サービスアカウントで 2 つのオプションから選択して、 AWS サービスに API リクエストを行うことができます。

IRSA 経由の認証情報: このオプションを使用すると、ソフトウェアは Identity and Access Management (IAM) Role Service (IRSA) から継承認証情報を取得できます。詳細については、「サービスアカウントの IAM ロール」を参照してください。
Amazon EKS ポッドアイデンティティ: このオプションは、ソフトウェアが Amazon EKS ポッドのポッドアイデンティティを使用して AWS サービスに API リクエストを行うことを許可します。詳細については、「EKS Pod Identity がポッドに AWS サービスへのアクセスを許可する方法」を参照してください。

アドオンには、Helm チャートの最上位aws_mp_addon_parameters.jsonにあるという名前の追加設定ファイルが、現在のカスタム設定スキーマ () と同じディレクトリにある必要がありますaws_mp_configuration_schema.json。現在、このファイルはポッド ID 互換のアクセス許可のみを処理します。ファイル形式は次のとおりです。


{
  "permissions": {
      "isPodIdentityCompatible" : true,
      "permissionsList": [
       {
        "serviceAccount" : "String",
        "managedPolicies" : ["Policy Arn"],
       }
     ]
    }
  }

ファイル名: aws_mp_addon_parameters.json

注記

aws_mp_addon_parameters.json ファイルは、Amazon EKS コンソールのアドオン設定ページのアドオンアクセスセクションを有効にします。

フィールド名	タイプ	メモ	値の例
isPodIdentityCompatible	ブール値	現時点では、「true」のみがサポートされています。フィールドには、次の permissionsList リストで説明されているアクセス許可がポッド ID に適しているかどうかが表示されます。	正
serviceAccount	文字列	アドオンがアクセス許可にアクセスするために使用するサービスアカウントの名前	`kpow`
managedPolicies	リスト＜文字列＞	EKS アドオンが引き受ける可能性のある、このサービスアカウントに使用するポリシー ARN のリスト	`["arn:aws:iam::aws:policy/ReadOnlyAccess"]`

注記

のPay-as-you-go制 (PAYG) アドオン製品は Amazon EKS Pod Identity AWS Marketplace を使用できないため、アクセスコントロールにはサービスアカウント (IRSA) の IAM ロールを使用する必要があります。

バージョンを更新 – Amazon EKS は、アップストリームリリースから数週間後に新しい Kubernetes バージョンをリリースします。新しい Amazon EKS クラスターバージョンが一般公開されると、ベンダーは 45 日以内に新しい Amazon EKS クラスターバージョンリリースと互換性があるソフトウェアを認証または更新する必要があります。現在のアドオンバージョンが新しい Kubernetes バージョンをサポートしている場合は、検証して認証することで、バージョンの互換性マトリックスを更新できます。新しい Kubernetes バージョンリリースをサポートするために新しいアドオンバージョンが必要な場合は、オンボーディングのために新しいバージョンを送信してください。
パートナーのソフトウェアは、次のいずれかのタイプに該当するか、Kubernetes または Amazon EKS を強化する運用ソフトウェアである必要があります: Gitops | monitoring | logging | cert-management | policy-management | cost-management | autoscaling | storage | kubernetes-management | service-mesh | etcd-backup | ingress-service-type | load-balancer | local-registry| networking | Security | backup | ingress-controller | observability。
ソフトウェアを Container Network Interface (CNI) にすることはできません。
ソフトウェアは、を通じて販売 AWS Marketplace され、有料製品のライセンスおよび計測 APIs と統合されている必要があります。BYOL 製品は受け付けられません。

アドオンプロバイダーのアドオン設定要件とベストプラクティス

Amazon EKS では、アドオンプロバイダーからの Helm JSON スキーマ文字列としての設定が必要です。必要な設定を必要とするアドオン、またはオプションの設定を許可するアドオンには、Helm チャートが送信されたaws_mp_configuration_schema.jsonファイルを含める必要があります AWS Marketplace。Amazon EKS はこのスキーマを使用して、顧客からの設定入力を検証し、スキーマに準拠しない入力値を持つ API コールを拒否します。アドオン設定は、通常 2 つのカテゴリに分類されます。

ラベル、許容範囲、nodeSelector などの一般的な Kubernetes プロパティの設定。
ライセンスキー、機能有効化、URL など、アドオン固有の設定。

このセクションでは、一般的な Kubernetes プロパティに関連する最初のカテゴリに焦点を当てます。

Amazon EKS では、Amazon EKS アドオンの設定に関するベストプラクティスに従うことが推奨されます。

スキーマ要件
設定で許可される一般的なパラメータ
設定に許可されていない一般的なパラメータ

スキーマ要件

json スキーマを定義するときは、Amazon EKS アドオンでサポートされている jsonschema のバージョンを使用します。

サポートされているスキーマのリスト:

https://json-schema.org/draft-04/schema
https://json-schema.org/draft-06/schema
https://json-schema.org/draft-07/schema
https://json-schema.org/draft/2019-09/schema

他の json スキーマバージョンを使用すると、Amazon EKS アドオンと互換性がとれなくなり、修正されるまでアドオンをリリースできなくなります。

Helm スキーマファイルの例


{
"$schema": "http://json-schema.org/schema#",
  "type": "object",
  "properties": {
"podAnnotations": {
"description": "Pod Annotations"
"type": "object"
    },
    "podLabels": {
"description": "Pod Labels"
"type": "string"
    },
    "resources": {
"type": "object"
"description": "Resources"
    },
    "logLevel": {
"description": "Logging Level"
"type": "string",
      "enum": [
        "info",
        "debug"
      ]
    },
    "config": {
"description": "Custom Configuration"
"type": "object"
    }
  }
}

camelCase

設定パラメータは camelCase である必要があります。この形式に沿っていない場合は、拒否されます。

説明は必須

スキーマプロパティには常に意味のある説明を含めます。この説明は、設定パラメータごとに Amazon EKS コンソールでラベル名をレンダリングするために使用されます。

RBAC 定義

アドオンプロバイダーは、最小権限の原則を使用して、アドオンを正常にインストールするために必要な RBAC アクセス許可を定義して提供する必要があります。RBAC アクセス許可が、新しいバージョンのアドオンまたは CVE に対応するための修正に対して変更する必要がある場合、アドオンプロバイダーはその変更を Amazon EKS チームに通知する必要があります。各 Kubernetes リソースに必要なアクセス許可は、オブジェクトのリソース名に制限する必要があります。


apiGroups: ["apps"]
resources: ["daemonsets"]
resourceNames: ["ebs-csi-node"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]

シークレットの管理

このセクションは、顧客がアプリケーションキー、API キー、パスワードなどのシークレット情報を設定する必要があるアドオンにのみ適用されます。現在、Amazon EKS API では、セキュリティ上の影響により、機密情報をプレーンテキストで渡すことはサポートされていません。ただし、顧客は設定を使用して、アドオンに必要なキーを保持する Kubernetes シークレットの名前を渡すことができます。お客様は、前提条件のステップと同じ名前空間を持つキーを含む Kubernetes Secret オブジェクトを作成し、アドオンの作成時に設定 blob を使用して Secret の名前を渡す必要があります。アドオンプロバイダーは、顧客が誤って実際のキーと間違えないように、スキーマプロパティに名前を付けることをお勧めします。例: appSecretName、connectionSecretName など。

つまり、アドオンプロバイダーはスキーマを活用して、顧客がシークレットの名前を渡すことはできますが、実際にシークレット自体を保持するキーは渡すことはできません。

設定値の例

アドオンの設定で顧客を支援するために、スキーマに設定例を含めることができます。次の例は、 AWS Distro for OpenTelemetry アドオンのスキーマからのものです。


"examples": [
      {
        "admissionWebhooks": {
          "namespaceSelector": {},
          "objectSelector": {}
        },
        "affinity": {},
        "collector": {
          "amp": {
            "enabled": true,
            "remoteWriteEndpoint": "https://aps-workspaces.us-west-2.amazonaws.com/workspaces/ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api/v1/remote_write"
          },
          "cloudwatch": {
            "enabled": true
          },
          "mode": "deployment",
          "replicas": 1,
          "resources": {
            "limits": {
              "cpu": "256m",
              "memory": "512Mi"
            },
            "requests": {
              "cpu": "64m",
              "memory": "128Mi"
            }
          },
          "serviceAccount": {
            "annotations": {},
            "create": true,
            "name": "adot-collector"
          },
          "xray": {
            "enabled": true
          }
        },
        "kubeRBACProxy": {
          "enabled": true,
          "resources": {
            "limits": {
              "cpu": "500m",
              "memory": "128Mi"
            },
            "requests": {
              "cpu": "5m",
              "memory": "64Mi"
            }
          }
        },
        "manager": {
          "env": {},
          "resources": {
            "limits": {
              "cpu": "100m",
              "memory": "128Mi"
            },
            "requests": {
              "cpu": "100m",
              "memory": "64Mi"
            }
          }
        },
        "nodeSelector": {},
        "replicaCount": 1,
        "tolerations": []
      }
    ]

設定で許可される一般的なパラメータ

以下は、顧客向け Helm スキーマファイルで推奨されるパラメータです。

パラメータ	説明	デフォルトの有無
additionalLabels	アドオンが管理するすべての Kubernetes オブジェクトに Kubernetes ラベルを追加します。	なし
additionalAnnotations	アドオンが管理するすべての Kubernetes オブジェクトに Kubernetes 注釈を追加します。	なし
podLabels	アドオンが管理する Pod に Kubernetes ラベルを追加します。	なし
podAnnotations	アドオンが管理する Pod に Kubernetes 注釈を追加します。	なし
logLevel	アドオンが管理するコンポーネントのログレベル。	あり
nodeSelector	ノード選択制約の最も簡単な推奨される形式。nodeSelector フィールドを Pod 仕様に追加すると、ターゲットノードに付けるノードラベルを指定できます。	例えば Linux ノードのみなど。
tolerations	許容値は Pod に適用されます。許容値により、スケジューラはテイントと一致する Pod をスケジュールできます。許容値によってスケジューリングは可能ですが、スケジューリングを保証するものではありません。	おそらく、デーモンセットでより一般的です。
affinity	アフィニティ機能には次の 2 種類があります: Node Affinity は nodeSelector フィールドのように機能しますが、より表現力が豊かで、ソフトルールを指定できます。Inter-Pod Affinity/Anti-Affinity は、他の Pod のラベルに対して Pod を制約できます。	おそらく
topologySpreadConstraints	Topology Spread による制約を使用すると、リージョン、ゾーン、ノード、その他のユーザー定義トポロジードメインなどで障害を起こしたドメイン間で、Pod がクラスター全体に分散される方法を制御できます。これにより、高可用性と効率的なリソース使用率を実現できます。	おそらく
リソースリクエスト/制限	各コンテナに必要な CPU/メモリの量を指定します。リクエストを設定することが強く推奨されます。制限はオプションです。	あり
レプリカ	アドオンによって管理される Pod のレプリカの数。デーモンセットには適用されません。	あり

注記

ワークロードスケジューリング設定パラメータでは、必要に応じてスキーマの最上位のコンポーネントを分離する必要がある場合があります。例えば、Amazon EBS CSI ドライバーには、コントローラーとノードエージェントという 2 つの主要なコンポーネントが含まれています。顧客は、コンポーネントごとに異なるノードセレクタ/許容値を設定する必要があります。

注記

JSON スキーマで定義されているデフォルト値は、ユーザードキュメントのみを目的としており、values.yaml ファイルで適切なデフォルトを使用する必要があります。デフォルトプロパティを使用する場合は、Helm チャートを変更するたびに、values.yaml のデフォルトがスキーマのデフォルトと一致し、values.schema.json と values.yaml の 2 つのアーティファクトが同期されていることを確認します。


"affinity": {
            "default": {
              "affinity": {
                "nodeAffinity": {
                  "preferredDuringSchedulingIgnoredDuringExecution": [
                    {
                      "preference": {
                        "matchExpressions": [
                          {
                            "key": "eks.amazonaws.com/compute-type",
                            "operator": "NotIn",
                            "values": [
                              "fargate"
                            ]
                          }
                        ]
                      },
                      "weight": 1
                    }
                  ]
                },
                "podAntiAffinity": {
                  "preferredDuringSchedulingIgnoredDuringExecution": [
                    {
                      "podAffinityTerm": {
                        "labelSelector": {
                          "matchExpressions": [
                            {
                              "key": "app",
                              "operator": "In",
                              "values": [
                                "ebs-csi-controller"
                              ]
                            }
                          ]
                        },
                        "topologyKey": "kubernetes.io/hostname"
                      },
                      "weight": 100
                    }
                  ]
                }
              }
            },
            "description": "Affinity of the controller pod",
            "type": [
              "object",
              "null"
            ]
          }

設定に許可されていない一般的なパラメータ

clusterName、region、vpcId、accountId などのクラスタメタデータパラメータは、Elastic Load Balancing Controller などのさまざまなアドオンで必要な場合があります。Amazon EKS サービスで知られているこれらに類似するパラメータは、Amazon EKS アドオンによって自動的に挿入されるため、ユーザーが設定オプションとして指定する責任はありません。パラメータには以下が含まれます。

AWS リージョン
Amazon EKS クラスター名
クラスターの VPC ID
コンテナレジストリ (特にネットワークアドオンで使用されるビルドプロッドアカウント用)
DNS クラスター IP (特に coredns アドオン用)
Amazon EKS クラスター API エンドポイント
クラスターで有効になっている IPv4
クラスターで有効になっている IPv6
クラスターで有効になっている IPv6 のプレフィックス委任

アドオンプロバイダーは、該当するパラメータにテンプレートが定義されていることを確認する必要があります。上記の各パラメータには、Amazon EKS で事前定義された parameterType 属性があります。リリースメタデータは、parameterType とテンプレート内のパラメータ名/パス間のマッピングを指定します。これにより、Amazon EKS は、顧客が設定でこれらを指定しなくても、動的に値を渡すことができるため、アドオンプロバイダーは、独自のテンプレート名/パスを柔軟に定義できます。Amazon EKS が動的に注入する必要がある上記のようなパラメータは、スキーマファイルから除外する必要があります。

リリースメタデータからのマッピングの例


"defaultConfiguration": [
       {
            "key": "image.containerRegistry",
            "parameterType": "CONTAINER_REGISTRY"
       }
]

以下は、顧客向け Helm スキーマファイルでの設定が非推奨のパラメータです。パラメータは変更不可能のデフォルトにするか、アドオンテンプレートに一切含めるべきではありません。

パラメータ	説明	デフォルトの有無
画像	Kubernetes クラスターにデプロイされるコンテナイメージ。	いいえ、アドオン定義で管理されます
imagePullSecrets	シークレットを使用してプライベートレジストリからプルするように Pod を設定する。	該当なし
livenessProbe	Kubelet プロセスは、ライブネスプローブを使用して、コンテナを再起動するタイミングを確認します。例えば、ライブネスプローブは、アプリケーションが実行されているが進行できないデッドロックを取得する場合があります。このような状態でコンテナを再起動すると、バグが発生してもアプリケーションを使用できます。	あり
readinessProbe	コンテナの準備状況プローブを用意することが重要です。これにより、データプレーンで実行されている Kubelet プロセスは、コンテナがトラフィックを処理する準備ができたタイミングを知ることができます。Pod は、すべてのコンテナの準備が整った時点で準備完了と見なされます。このシグナルの 1 つの用途は、サービスのバックエンドとして使用される Pod を制御することです。Pod の準備が整っていない場合、Pod はサービスロードバランサーから削除されます。	あり
startupProbe	kubelet はスタートアッププローブを使用して、コンテナアプリケーションの開始時期を把握します。このようなプローブが設定されている場合、成功するまでライブネスと準備状況チェックを無効にし、それらのプローブがアプリケーションの起動に干渉しないことを確認します。これは、起動の遅いコンテナにライブネスチェックを採用するために使用され、起動して実行する前に kubelet による停止を回避できます。	オプションです。
podDisruptionBudget	Pod Discruption Budget (PDB) を定義して、自発的な中断時に最小限の数の PODS が実行され続けるようにします。PDB は、任意の中断によって同時にダウンするレプリケートされたアプリケーションの Pod の数を制限します。例えば、クォーラムベースのアプリケーションは、実行中のレプリカの数がクォーラムに必要な数を下回らないようにします。ウェブフロントエンドは、負荷に対応するレプリカの数が合計の一定割合を下回らないようにします。	はい。デフォルトで 3 つ以上のレプリカに設定されている場合
serviceAccount (名前)	実行されるサービスアカウント Pod の名前。	あり
serviceAccount (注釈)	サービスアカウントに適用される注釈。通常、サービスアカウント機能の IAM ロールに使用されます。	いいえ、IAM サービスアカウントロール ARN は最上位の Amazon EKS アドオン API に設定されています。このルールの例外として、アドオンに複数のデプロイ/コントローラー (Flux など) があり、個別の IRSA ロール ARN が必要な場合が挙げられます。
priorityClassName	Priority は、他の Pod と比較した Pod の重要性を示します。Pod をスケジュールできない場合、スケジューラは優先度の低い Pod を優先 (排除) して、保留中の Pod のスケジューリングを可能にします。	はい。ほとんどのアドオンはクラスター機能にとって重要であり、デフォルトで優先度クラスが設定されている必要があります。
podSecurityContext	セキュリティコンテキストは、Pod とコンテナの権限とアクセス制御設定を定義します。通常、fsGroup の設定に使用されます。これは v1.19 以下のクラスターの IRSA に必要でした。	Amazon EKS が Kubernetes v1.19 をサポートしなくなった場合、可能性は低いです。
SecurityContext	セキュリティコンテキストは、Pod とコンテナの権限とアクセス制御設定を定義します。	あり
updateStrategy	古い Pod を新しい Pod に置き換えるために使用される戦略を指定します。	あり
nameOverride	Pod の名前を上書きします。	なし
podSecurityPolicy	パラメータに制限を適用します。	いいえ - PSP は非推奨です
extraVolumeMounts /extraVolumes	Amazon EKS 以外のクラスターの IRSA に使用されます。	なし

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

製品のテストとリリース

コンテナ製品の料金