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 コンポーネントは、イメージ署名検証ホワイトリストの設定をサポートしています。これにより、サードパーティコンポーネントによって自動的にインジェクトされた Sidecar コンテナイメージがイメージ署名検証に合格できず、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 システムイメージをホワイトリストに追加するには、次の手順で設定します。

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 の両方に一致します。

   一般的なホワイトリストエントリは次のとおりです。実際のニーズに応じて追加できます。

   # Container Service ACK で使用されるイメージ
   - namePattern: 'registry*.*.aliyuncs.com/acs/*'
   - namePattern: 'registry-*.ack.aliyuncs.com/acs/*'
   
   # Container Service 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