Container Service for Kubernetes:Use kritis-validation-hook to verify container image signatures

Configure resource access permissions

For the kritis-validation-hook component to function properly, ensure that the RAM role used by the cluster has the following resource access permissions:

"cr:ListInstance",
"cr:ListMetadataOccurrences"

If the RAM role used by your cluster lacks these permissions, add them as follows.

1. You can create a custom policy with the following content. For more information, see Step 1: Create a custom policy.

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

2. You can grant permissions to the cluster's Worker RAM role. For more information, see Step 2: Grant permissions to the Worker RAM role of the cluster.

   Note

   For an ACK dedicated cluster, you must also grant these permissions to the Master RAM role.

Example: Enable image signature verification

1. You can configure an AttestationAuthority to declare the trusted authority.

   1. You can create a file named AttestationAuthority.yaml with the following content.

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

   2. You can run the following command to configure the trusted authority.

      kubectl apply -f AttestationAuthority.yaml

2. You can configure a GenericAttestationPolicy to declare the signature verification policy and use the trusted authority's information to verify signatures.

   1. You can create a file named GenericAttestationPolicy.yaml with the following content.

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

   2. You can run the following command to configure the signature verification policy.

      kubectl apply -f GenericAttestationPolicy.yaml

3. You can test the image signature verification feature by deploying an image that is not signed by the trusted authority.

   You can run the following command to test the image signature verification feature.

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

   Expected output:

   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:****

   The output indicates that the image signature verification feature denies the deployment of images not signed by the trusted authority.

4. You can test the image signature verification feature by deploying an image signed by the trusted authority.

   You can run the following command to test the image signature verification feature.

   Replace the following image address with your actual signed image.

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

   Expected output:

   deployment.apps/test-allow created

   The output indicates that the image signature verification feature allows the deployment of images signed by the trusted authority.

Configure an image signature verification whitelist

The kritis-validation-hook component supports configuring an image signature verification whitelist for middleware or service mesh scenarios. This resolves issues where pods fail to deploy because images of sidecar containers automatically injected by third-party components cannot pass signature verification. The component does not verify signatures of images on the whitelist. It only verifies images not on the whitelist.

apiVersion: kritis.grafeas.io/v1beta1   # Default value. Do not modify.
kind: AdmissionAllowlist                # Default value. Do not modify.
metadata:
  name: kritis-allowlist                # Resource name, which must be unique within the cluster.
spec:
  patterns:                             # Whitelist configuration. You can define multiple whitelists.
  - namePattern: 'registry*.*.aliyuncs.com/acs/*' # The name of the image to ignore. For more information about the format, see the description below.
  - namePattern: 'registry-vpc.cn-beijing.aliyuncs.com/arms-docker-repo/*'
    namespace: 'default'    # [Optional] The namespace to which the whitelist applies. If not specified, it applies to all namespaces.

To add ACK OS images to the whitelist, perform these steps.

1. You can create a file named kritis-admission-allowlist-acs.yaml with the following content to configure the whitelist.

   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/*'

   The namePattern configuration item supports exact matches and simple wildcard matches using the asterisk (*) character. Details are provided below:

   • If the value does not contain an asterisk (*), it performs an exact match. For example, nginx:v0.1.0 matches only nginx:v0.1.0.

   • If you use an asterisk (*) for wildcard matching, the following limitations apply:

     • If the asterisk (*) is at the end, it matches any character except a forward slash (/). For example, a.com/nginx* matches a.com/nginx:v0.1.0 but not a.com/nginx/test:v0.1.0.

     • If the asterisk (*) is not at the end, it matches letters, digits, hyphens (-), or underscores (_). For example, registry-vpc.cn-*.aliyuncs.com/acs/pause:3.2 matches both registry-vpc.cn-hangzhou.aliyuncs.com/acs/pause:3.2 and registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.2.

   The following are common whitelists. You can add them as needed.

   # Images used by ACK
   - namePattern: 'registry*.*.aliyuncs.com/acs/*'
   - namePattern: 'registry-*.ack.aliyuncs.com/acs/*'
   
   # Images used by ACK (China regions only)
   - namePattern: 'registry*.cn-*.aliyuncs.com/acs/*'
   - namePattern: 'registry-cn-*.ack.aliyuncs.com/acs/*'
   
   # Images used by ARMS
   - namePattern: 'registry*.*.aliyuncs.com/arms-docker-repo/*'
   
   # Images used by ARMS (China regions only)
   - namePattern: 'registry*.cn-*.aliyuncs.com/arms-docker-repo/*'

2. You can run the following command to configure the whitelist.

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

   Expected output:

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

3. You can run the following command to verify that the whitelist is configured.

   kubectl get admissionallowlists.kritis.grafeas.io

   Expected output:

   NAME               AGE
   allow-acs-images   2m22s