Container Service for Kubernetes:Verify container image signatures using kritis-validation-hook

Configure resource access permissions

To ensure the normal operation of the kritis-validation-hook component, you need to make sure 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 does not have the above access permissions, you can add the required resource access permissions through the following methods.

1. 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. Grant permissions to the Worker RAM role of the cluster. For more information, see Step 2: Grant permissions to the Worker RAM role of the cluster.

   Note

   For ACK dedicated clusters, you also need to grant the above permissions to the Master RAM role of the cluster.

Example of enabling image signature verification

1. Configure AttestationAuthority to declare the trusted authority.

   1. Create an AttestationAuthority.yaml file 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. Run the following command to configure the trusted authority information.

      kubectl apply -f AttestationAuthority.yaml

2. Configure GenericAttestationPolicy to declare the signature verification policy and use the trusted authority information to verify signatures.

   1. Create a GenericAttestationPolicy.yaml file with the following content.

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

   2. Run the following command to configure the signature verification policy.

      kubectl apply -f GenericAttestationPolicy.yaml

3. Test the image signature verification functionality by deploying an image that has not been signed by a trusted authority.

   Run the following command to test the image signature verification functionality.

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

   From the expected output, you can see that the image signature verification functionality rejects the deployment of images that have not been signed by a trusted authority.

4. Test the image signature verification functionality by deploying an image that has been signed by a trusted authority.

   Run the following command to test the image signature verification functionality.

   Replace the following image address with the 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

   From the expected output, you can see that the image signature verification functionality allows the deployment of images that have been signed by a trusted authority.

Configure image signature verification whitelist

In middleware or service mesh scenarios, the kritis-validation-hook component supports configuring an image signature verification whitelist to solve the problem where Sidecar container images automatically injected by third-party components cannot pass image signature verification, resulting in the inability to deploy pods. The component does not verify signatures for images in the whitelist, but only verifies images that are not in the whitelist.

apiVersion: kritis.grafeas.io/v1beta1   # Default value, no need to modify.
kind: AdmissionAllowlist                # Default value, no need to modify.
metadata:
  name: kritis-allowlist                # Resource name, unique within the cluster.
spec:
  patterns:                             # Whitelist configuration, multiple whitelist entries can be defined.
  - namePattern: 'registry*.*.aliyuncs.com/acs/*' # Image name to ignore, see below for specific format.
  - namePattern: 'registry-vpc.cn-beijing.aliyuncs.com/arms-docker-repo/*'
    namespace: 'default'    # [Optional], which namespace the whitelist configuration applies to. When not configured, it applies to all namespaces.

To add ACK system images to the whitelist, you can configure them through the following steps.

1. Create a kritis-admission-allowlist-acs.yaml file 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 value supports exact matching and simple wildcard matching using the asterisk (*) character. The specific explanations are as follows:

   • When the configuration value does not contain an asterisk (*) character, it will perform an exact match based on the configured value. For example, nginx:v0.1.0 will only match nginx:v0.1.0.

   • When using the asterisk (*) character for wildcard matching, the following limitations exist:

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

     • When the asterisk (*) is not at the end, it matches letters, numbers, hyphens (-), and 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.

   Common whitelist entries are as follows. You can add them according to your actual needs.

   # Images used by Container Service ACK
   - namePattern: 'registry*.*.aliyuncs.com/acs/*'
   - namePattern: 'registry-*.ack.aliyuncs.com/acs/*'
   
   # Images used by Container Service ACK (limited to China regions)
   - 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 (limited to China regions)
   - namePattern: 'registry*.cn-*.aliyuncs.com/arms-docker-repo/*'

2. 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. Run the following command to verify that the whitelist configuration is successful.

   kubectl get admissionallowlists.kritis.grafeas.io

   Expected output:

   NAME               AGE
   allow-acs-images   2m22s