Container Service for Kubernetes:kritis-validation-hook を使用したコンテナイメージ署名の検証

リソースアクセス権限の設定

kritis-validation-hook コンポーネントが正常に機能するためには、クラスターで使用される RAM ロールに次のリソースアクセス権限があることを確認してください：

"cr:ListInstance",
"cr:ListMetadataOccurrences"

ご利用のクラスターで使用されている RAM ロールにこれらの権限がない場合は、次のように追加してください。

1. 次の内容でカスタムポリシーを作成できます。詳細については、「ステップ 1：カスタムポリシーの作成」をご参照ください。

   {
       "Statement": [
           {
               "Action": [
                   "cr:ListInstance",
                   "cr:ListMetadataOccurrences"
               ],
               "Effect": "Allow",
               "Resource": "*"
           }
       ],
       "Version": "1"
   }

2. クラスターの Worker RAM ロールに権限を付与できます。詳細については、「ステップ 2：クラスターの Worker RAM ロールへの権限付与」をご参照ください。

   説明

   ACK 専用クラスターの場合、Master RAM ロールにもこれらの権限を付与する必要があります。

例：イメージ署名検証の有効化

1. AttestationAuthority を設定して、信頼できる認証局を宣言できます。

   1. AttestationAuthority.yaml という名前のファイルを次の内容で作成できます。

      apiVersion: kritis.grafeas.io/v1beta1
      kind: AttestationAuthority
      metadata:
        name: demo-aa
      spec:
        noteReference: namespaces/demo-aa
        publicKeyData: LS0tLS1CRUdJTiBQ***
        publicKeyId: key-4a2ef103-5aa3-4220-****

   2. 次のコマンドを実行して、信頼できる認証局を設定できます。

      kubectl apply -f AttestationAuthority.yaml

2. GenericAttestationPolicy を設定して、署名検証ポリシーを宣言し、信頼できる認証局の情報を使用して署名を検証できます。

   1. GenericAttestationPolicy.yaml という名前のファイルを次の内容で作成できます。

      apiVersion: kritis.grafeas.io/v1beta1
      kind: GenericAttestationPolicy
      metadata:
        name: demo-gap
      spec:
        attestationAuthorityNames:
        - demo-aa

   2. 次のコマンドを実行して、署名検証ポリシーを設定できます。

      kubectl apply -f GenericAttestationPolicy.yaml

3. 信頼できる認証局によって署名されていないイメージをデプロイして、イメージ署名検証機能をテストできます。

   次のコマンドを実行して、イメージ署名検証機能をテストできます。

   kubectl create deployment test-denied --image=anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6

   想定される出力：

   error: failed to create deployment: admission webhook "kritis-validation-hook-deployments.grafeas.io" denied the request: "ACROpenAPIError detail: <image anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 is not attested because of get resource url for anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6: ListInstance failed, instanceName: "anolis", regionId: "cn-zhangjiakou", requstURL:error:****

   この出力は、イメージ署名検証機能が、信頼できる認証局によって署名されていないイメージのデプロイを拒否することを示しています。

4. 信頼できる認証局によって署名されたイメージをデプロイして、イメージ署名検証機能をテストできます。

   次のコマンドを実行して、イメージ署名検証機能をテストできます。

   次のイメージアドレスを、実際の署名済みイメージに置き換えてください。

   kubectl create deployment test-allow --image=kritis-demo***.cn-hangzhou.cr.aliyuncs.com/kritis-demo***/alpine@sha256:ddba4d27a7ffc3f86dd6c2f92041af252a1f23a8e742c90e6e1297bfa1bc0c45

   想定される出力：

   deployment.apps/test-allow created

   この出力は、イメージ署名検証機能が、信頼できる認証局によって署名されたイメージのデプロイを許可することを示しています。

イメージ署名検証ホワイトリストの設定

kritis-validation-hook コンポーネントは、ミドルウェアやサービスメッシュのシナリオ向けに、イメージ署名検証ホワイトリストの設定をサポートしています。これにより、サードパーティコンポーネントによって自動的に注入されるサイドカーコンテナのイメージが署名検証を通過できず、Pod のデプロイに失敗する問題を解決します。コンポーネントは、ホワイトリスト上のイメージの署名を検証しません。ホワイトリストにないイメージのみを検証します。

apiVersion: kritis.grafeas.io/v1beta1   # デフォルト値。変更しないでください。
kind: AdmissionAllowlist                # デフォルト値。変更しないでください。
metadata:
  name: kritis-allowlist                # リソース名。クラスター内で一意である必要があります。
spec:
  patterns:                             # ホワイトリストの設定。複数のホワイトリストを定義できます。
  - namePattern: 'registry*.*.aliyuncs.com/acs/*' # 無視するイメージの名前。フォーマットの詳細については、以下の説明をご参照ください。
  - namePattern: 'registry-vpc.cn-beijing.aliyuncs.com/arms-docker-repo/*'
    namespace: 'default'    # [オプション] ホワイトリストが適用される名前空間。指定しない場合、すべての名前空間に適用されます。

ACK OS イメージをホワイトリストに追加するには、次の手順を実行します。

1. kritis-admission-allowlist-acs.yaml という名前のファイルを次の内容で作成して、ホワイトリストを設定できます。

   apiVersion: kritis.grafeas.io/v1beta1
   kind: AdmissionAllowlist
   metadata:
     name: allow-acs-images
   spec:
     patterns:
     - namePattern: 'registry*.*.aliyuncs.com/acs/*'
     - namePattern: 'registry-*.ack.aliyuncs.com/acs/*'

   namePattern 設定項目は、完全一致とアスタリスク (*) 文字を使用した単純なワイルドカード一致をサポートしています。詳細は以下の通りです：

   • 値にアスタリスク (*) が含まれていない場合、完全一致を実行します。たとえば、nginx:v0.1.0 は nginx:v0.1.0 にのみ一致します。

   • ワイルドカード一致にアスタリスク (*) を使用する場合、次の制限が適用されます：

     • アスタリスク (*) が末尾にある場合、スラッシュ (/) を除く任意の文字に一致します。たとえば、a.com/nginx* は a.com/nginx:v0.1.0 に一致しますが、a.com/nginx/test:v0.1.0 には一致しません。

     • アスタリスク (*) が末尾にない場合、文字、数字、ハイフン (-)、またはアンダースコア (_) に一致します。たとえば、registry-vpc.cn-*.aliyuncs.com/acs/pause:3.2 は registry-vpc.cn-hangzhou.aliyuncs.com/acs/pause:3.2 と registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.2 の両方に一致します。

   以下は一般的なホワイトリストです。必要に応じて追加できます。

   # ACK で使用されるイメージ
   - namePattern: 'registry*.*.aliyuncs.com/acs/*'
   - namePattern: 'registry-*.ack.aliyuncs.com/acs/*'
   
   # ACK で使用されるイメージ (中国リージョンのみ)
   - namePattern: 'registry*.cn-*.aliyuncs.com/acs/*'
   - namePattern: 'registry-cn-*.ack.aliyuncs.com/acs/*'
   
   # ARMS で使用されるイメージ
   - namePattern: 'registry*.*.aliyuncs.com/arms-docker-repo/*'
   
   # ARMS で使用されるイメージ (中国リージョンのみ)
   - namePattern: 'registry*.cn-*.aliyuncs.com/arms-docker-repo/*'

2. 次のコマンドを実行して、ホワイトリストを設定できます。

   kubectl apply -f kritis-admission-allowlist-acs.yaml 

   想定される出力：

   admissionallowlist.kritis.grafeas.io/allow-acs-images created

3. 次のコマンドを実行して、ホワイトリストが設定されていることを確認できます。

   kubectl get admissionallowlists.kritis.grafeas.io

   想定される出力：

   NAME               AGE
   allow-acs-images   2m22s