Use Notation and Ratify for signing and signature verification - Container Service for Kubernetes

You can use the notation-alibabacloud-secret-manager plug-in with keys from Key Management Service (KMS) to sign Open Container Initiative (OCI) artifacts managed by Container Registry (ACR). After signing, you can install and configure Ratify in your cluster to verify these signatures. This process ensures that only images with valid signatures are deployed, blocking any unsigned images to improve system security.

Related concepts

notation-alibabacloud-secret-manager: A plug-in developed according to the specifications of the open source Notation project. This plug-in lets you use keys managed by Alibaba Cloud Key Management Service (KMS) to sign images managed by ACR.

Ratify: A binary executable verification engine that runs in a Kubernetes cluster. Ratify injects and verifies security metadata, such as image signatures and software bills of materials (SBOMs), for cloud-native artifacts. It allows only artifacts that meet policy requirements to be deployed in the cluster.

Prerequisites

You have created an ACK managed cluster, ACK dedicated cluster, or ACK Serverless cluster that runs Kubernetes 1.20 or later. For more information, see Create an ACK managed cluster, Create an ACK dedicated cluster (discontinued), or Create an ACK Serverless cluster.
You have created a Container Registry Enterprise Edition (Advanced Edition) instance. For more information, see Create a Container Registry Enterprise Edition instance.
You have installed the Notation CLI.
You have purchased and enabled a KMS instance. For more information, see Purchase and enable a KMS instance.

Step 1: Obtain a key managed by a KMS instance

Key Management Service (KMS) is an all-in-one platform for simplified, reliable, secure, and compliant credential management and data encryption. You can use the notation-alibabacloud-secret-manager plug-in to sign artifacts with keys created and managed by KMS or with self-signed keys imported into KMS.

Use a key created and managed by KMS

Log on to the KMS console. In the top navigation bar, select a region. In the navigation pane on the left, choose Resource > Keys.
On the Keys page, click the Customer Master Keys tab, select a software key management instance from the Instance ID drop-down list, and then click Create Key.

In the Create Key panel, configure the settings, and then click OK.

The following table describes the parameters. For more information, see Software-protected keys.

Configuration item	Description	Example
KMS Instance	Select the KMS instance for which you want to create a key.	kst-l***
Key Type	Select Asymmetric Key.	Asymmetric key
Key Specifications	The following asymmetric key specifications are supported: RSA_2048 RSA_3072 EC_P256	RSA-2048
Key Usage	Select SIGN/VERIFY. This indicates that the key is used to generate and verify digital signatures.	SIGN/VERIFY
Key Alias	The alias of the key. The alias can contain letters, digits, underscores (_), hyphens (-), and forward slashes (/).	test-key
Tag	The tag of the key. You can use tags to classify and manage keys. Each tag consists of a key-value pair that contains a tag key and a tag value.	None

Create an application access point (AAP).

In the navigation pane on the left, click Application Access > Multi-Cloud Access (formerly AAP).

On the Application Access tab, click Create AAP. In the Create AAP panel, configure the parameters.

Parameter	Description
Mode	Select Quick Creation.
Scope (KMS Instance)	Select the KMS instance that you want to access.
Application Access Point Name	Enter the name of the AAP.
Authentication Method	The default value is ClientKey, which cannot be changed.
Default Permission Policy	The default value is `key/secret/`, which cannot be changed. Your application can access all keys and secrets in the specified KMS instance.

Click OK. The browser automatically downloads the client key that is created.
The client key contains Application Access Secret(ClientKeyContent) and Password. By default, Application Access Secret(ClientKeyContent) is saved in a file whose name is in the clientKey_****.json format. By default, Password is saved in a file whose name is in the clientKey_****_Password.txt format.

Use a self-signed key imported to KMS

In addition to creating keys in KMS, you can import external key material to use self-signed keys. This section uses OpenSSL to generate a private key and a certificate as an example.

1. Create an asymmetric key

Log on to the KMS console. In the top navigation bar, select a region. In the navigation pane on the left, choose Resource > Keys.
On the Keys page, click the Customer Master Keys tab, select a software key management instance from the Instance ID drop-down list, and then click Create Key.

In the Create Key panel, configure the parameters and click OK.

The following table describes the parameters. For more information, see Step 1: Create an asymmetric key.

Configuration item	Description	Example
Key Type	Select Asymmetric Key.	Asymmetric key
Key Specifications	The following asymmetric key specifications are supported: RSA_2048 RSA_3072 EC_P256	RSA-2048
Key Usage	Select SIGN/VERIFY. This indicates that the key is used to generate and verify digital signatures.	SIGN/VERIFY
Key Alias	The alias of the key. The alias can contain letters, digits, underscores (_), hyphens (-), and forward slashes (/).	test-key
Tag	The tag of the key. You can use tags to classify and manage keys. Each tag consists of a key-value pair that contains a tag key and a tag value.	None

2. Download a wrapping public key and an import token

To import key material into a key, you must obtain a wrapping public key and an import token. The wrapping public key is used to encrypt key material. The import token allows you to import key material.

Find the key into which you want to import key material and click Details in the Actions column. On the Key Material tab, click Obtain Parameters for Import.
In the Obtain Parameters to Import Key Material dialog box, select Public Key Type and Encryption Algorithm and click Next.
Key management type
KMS key specification
Wrapping public key type
Encryption algorithm
Software-protected key
RSA_2048
RSA_3072
EC_P256
EC_P256K
RSA_2048
RSAES_OAEP_SHA_256_AES_256_ECB_PKCS7_PAD
RSAES_OAEP_SHA_256_AES_256_ECB_PKCS7_PAD: For more information about the encryption process, see Example: Use OpenSSL to generate key material for which the RSA_2048 algorithm is used.
Download a wrapping public key and an import token and store them in a secure location.
- Public Key Format
  - If you select DER Format, the name of the public key file is in the publickey_******.bin format.
  - If you select PEM Format, the name of the public key file is in the publickey_******.pem format.
- Import Token: The name of the import token file is in the token_******.txt format.
  Important
  - The import token is valid for 24 hours and can be repeatedly used within the validity period. After 24 hours, you must download a new import token and a new public key.
  - You must use the wrapping public key together with the import token. You cannot mix a wrapping public key and an import token from different downloads.

3. Use the wrapping public key to encrypt the key material

You must generate and encrypt key material in your system environment. The following table describes the keys that are involved during the process.

Key	Purpose	Provider	Description
Target asymmetric key (TAK)	The TAK that you want to import as key material.	Your system environment or tool such as an on-premises key management infrastructure (KMI) or a hardware security module (HSM).	TAKpub: the public key of the TAK TAKpriv: the private key of the TAK
Import wrapping key (IWK)	The key that is used to import the TAK.	KMS.	IWKpub: the public key of the IWK Note IWKpub is the wrapping public key that you downloaded in the KMS console. IWKpriv: the private key of the IWK
Ephemeral symmetric key (ESK)	The temporary key that is used to encrypt the private key of the TAK.	Your system environment or tool. After you export the TAK, you must immediately destroy the ESK.	N/A

Create a private key for the TAK. The specification of the private key must be the same as the specification of the asymmetric key that you created. If you already have a private key for the TAK, skip this step.
Note
Perform the following operations to make sure that the TAKpriv format meets the requirements: Encode a Rivest-Shamir-Adleman (RSA) private key based on RFC 3447 or an elliptic-curve cryptography (ECC) private key based on RFC 5915. Then, convert the RSA or ECC private key into the Public-Key Cryptography Standards (PKCS) #8 format based on RFC 5208.
Create an ESK.
Use the public key of the IWK to encrypt the ESK. The generated ciphertext is recorded as Cipher(ESK).
Use the ESK to encrypt the private key of the TAK. The generated ciphertext is recorded as Cipher(TAKpriv).
Assemble the encryption results in the Cipher(ESK) || Cipher(TAKpriv) format to obtain encrypted key material.

Example: Use OpenSSL to generate key material for which the RSA_2048 algorithm is used

Create an RSA_2048 private key for your TAK and convert the private key to the PKCS #8 format.

openssl genrsa -out TakPrivPkcs1.pem 2048
openssl pkcs8 -topk8 -inform PEM -in TakPrivPkcs1.pem -outform der -nocrypt -out TakPrivPkcs8.bin

Create an AES_256 ESK.
```
openssl rand -out EskAes256.bin 32
```
Use the public key of the IWK to encrypt the ESK and obtain Cipher(ESK). RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) is used for the encryption. SHA-256 is used as the mask generation function 1 (MGF1) and the hash algorithm.
```
openssl pkeyutl -encrypt -pubin -inkey PublicKey.pem  -in EskAes256.bin  -pkeyopt \
rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -pkeyopt rsa_mgf1_md:sha256 -out \
CipherEsk.bin
```
Note
Replace PublicKey.pem with the name of the public key file that you downloaded in the KMS console.
Use the ESK to encrypt the private key of the TAK and obtain Cipher(TAKpriv). In the encryption process, the electronic code book (ECB) encryption mode and the PKCS #7 padding mode are used.
```
xxd -l 32  -c 32 -ps EskAes256.bin | xargs -I {} openssl enc  -aes-256-ecb -e  -K {} -in \ 
TakPrivPkcs8.bin -nosalt -out CipherTakPriv.bin
```
Assemble the encryption results in the Cipher(ESK) || Cipher(TAKpriv) format and encode the assembled data in Base64.
```
cat CipherEsk.bin CipherTakPriv.bin > EncryptedKeyMaterial.bin
openssl enc -e -base64 -A -in EncryptedKeyMaterial.bin -out EncryptedKeyMaterial_base64.txt
```
Note
In the preceding sample code, the EncryptedKeyMaterial_base64.txt file contains the key material.

4. Import the key material

On the key details page, click Import Key Material. In the Import Wrapped Key Material dialog box, configure the parameters and click OK.

After you import the key material, the status of the key changes from Pending Import to Enabling.

Wrapped Key Material: Upload the key material file that is generated in step 3. Use the wrapping public key to encrypt key material.
Import Token: Upload the token file that you downloaded in 3. Use the wrapping public key to encrypt the key material.
Key Material Expired On: You can select Never Expire or specify a custom expiration time.
Important
If you specify an expiration time for key material, KMS deletes the key material when the expiration time is reached, and you can no longer use the key material. If you want to reuse the key material, you can reimport the same key material into the key.

Step 2: Install the notation-alibabacloud-secret-manager plug-in

The notation-alibabacloud-secret-manager plug-in is developed according to the specifications of the open source Notation project. This plug-in lets you use keys managed in Alibaba Cloud KMS to sign images managed by ACR.

Note

The notation-alibabacloud-secret-manager plug-in must run in the same region and virtual private cloud (VPC) as the KMS instance. For more information about how to access a KMS instance from multiple VPCs in the same region, see Configure Multi-VPC access to KMS instances within the same region.

Download the plug-in for your operating system. For more versions, see notation-alibabacloud-secret-manager.

Linux_arm64

wget  https://notation-alibabacloud-secret-manager.oss-cn-hangzhou.aliyuncs.com/dist/v0.1.2/notation-alibabacloud-secret-manager_Linux_arm64.tar.gz

Linux_X86_64

wget https://notation-alibabacloud-secret-manager.oss-cn-hangzhou.aliyuncs.com/dist/v0.1.2/notation-alibabacloud-secret-manager_Linux_x86_64.tar.gz

Run the following command to create a directory for the plug-in.

mkdir -p  /root/.config/notation/plugins/alibabacloud.secretmanager.plugin/

Run the following command to decompress the plug-in package to the specified directory.

tar -xvf notation-alibabacloud-secret-manager_Linux_<Version>.tar.gz  -C /root/.config/notation/plugins/alibabacloud.secretmanager.plugin/

Configure environment variables.

export ALIBABA_CLOUD_ACCESS_KEY_ID=your_access_key_id
export ALIBABA_CLOUD_ACCESS_KEY_SECRET=your_access_key_secret
export ALIBABA_CLOUD_KMS_INSTANCE_ENDPOINT=your_kms_endpoint
export ALIBABA_CLOUD_KMS_CLIENTKEY_FILEPATH=your_clientkey_filepath
export ALIBABA_CLOUD_KMS_PASSWORD=your_password
export ALIBABA_CLOUD_KMS_CA_FILEPATH=your_ca_filepath

Note

The notation-alibabacloud-secret-manager plug-in supports multiple credential configuration methods. For more information, see credentials.

Environment variable	Description	Example
ALIBABA_CLOUD_ACCESS_KEY_ID	The AccessKey ID of your Alibaba Cloud account.	XXXXXX
ALIBABA_CLOUD_ACCESS_KEY_SECRET	The AccessKey secret of your Alibaba Cloud account.	XXXXXX
ALIBABA_CLOUD_KMS_INSTANCE_ENDPOINT	The VPC endpoint of the dedicated KMS instance.	`kst-hzxxxxxxxxxx.cryptoservice.kms.aliyuncs.com`
ALIBABA_CLOUD_KMS_CLIENTKEY_FILEPATH	The path of the local file that stores the client key of the AAP for the dedicated KMS instance. Create a file, such as /root/clientkey, and copy the content of the `clientKey_KAAP.****.json` file that you downloaded from your browser in Step c of creating an AAP.	/root/clientkey
ALIBABA_CLOUD_KMS_PASSWORD	The password of the AAP for the dedicated KMS instance. Use the content of the clientKey_KAAP.594c78e6-7244-4187-XXX-8d59dca2ceb4_Password.txt file that you downloaded from your browser in Step c of creating an AAP.	XXXXXX
ALIBABA_CLOUD_KMS_CA_FILEPATH	The path of the local file that stores the CA certificate of the dedicated KMS instance. Create a file and copy the content of the PrivateKmsCA_xxxxx.pem file that you downloaded from your browser by following the instructions in Step 5: Obtain the CA certificate of a KMS instance.	/root/privatekmsca

Step 3: Prepare and sign an image

1. Prepare an image in ACR

Use a Container Registry Enterprise Edition instance to build an image or Build and push a multi-arch image on an on-premises device to a Container Registry Enterprise Edition instance.
Note
Container Registry Enterprise Edition supports OCI Image and Distribution Specification 1.1.0. You can use tools such as OCI Registry As Storage (ORAS) to manage and distribute non-image artifacts. For more information, see Using OCI v1.1.0 Specification to Manage and Associate Container Images and Their Derivative Artifacts.
Configure VPC or Internet access control for your Container Registry Enterprise Edition instance. For more information, see Network access control.
Obtain the password to log on to your Container Registry Enterprise Edition instance. If you forget the password, you can reset it by configuring access credentials. For more information, see Configure access credentials for a Container Registry Enterprise Edition instance.

2. Use Notation to sign an ACR image based on a key managed in KMS

You can use the notation-alibabacloud-secret-manager plug-in to sign a specified image in ACR using the private key and certificate from KMS.

To use the KMS Instance SDK for Go with the notation-alibabacloud-secret-manager plug-in, you must meet the following conditions and set the required environment variables.

Run the following command to log on to the image repository.

./notation login --username=tsh_ram@11380257155*** test-for-doc-registry.cn-hangzhou.cr.aliyuncs.com

Run the following command to sign the specified image and generate a certificate. In this command, <dirPath> is the path where the certificate is stored, for example, /root.

./notation sign  --id <keyId> --plugin alibabacloud.secretmanager.plugin test-for-doc-registry.cn-hangzhou.cr.aliyuncs.com/test/nginx:2.11 --plugin-config output_cert_dir=<dirPath>

Expected output:

Successfully signed test-for-doc-registry.cn-hangzhou.cr.aliyuncs.com/test/nginx@sha256:f57e1908e63538ad5159fa99443d0492d23b9d34ba7******

You can run the following command in the Notation CLI to sign an artifact.

notation sign --id <keyId> --plugin alibabacloud.secretmanager.plugin  <myRegistry>/<myRepo>@<digest> --plugin-config output_cert_dir=<dirPath>

Parameter

Description

id

The ID of the Alibaba Cloud KMS instance.

plugin-config

The custom parameters of the plug-in. The following parameters are supported:

output_cert_dir: When you sign an artifact, you can use this parameter to issue a corresponding X.509 verification certificate based on the specified KMS key and output the certificate to a file in the specified directory.
ca_certs: When you use a self-signed key that is imported to a KMS instance to sign an artifact, if you also use the key to issue an X.509 certificate, you can use this parameter to specify the path of the self-signed certificate.

Step 4: Use Ratify and Gatekeeper to verify signatures

1. Install Ratify and Gatekeeper

Enable Gatekeeper-based policy governance. For more information, see Enable policy governance.

Install Ratify.

Create the ratify namespace.
```
kubectl create ns ratify
```
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, find the cluster you want and click its name. In the left-side navigation pane, choose Applications > Helm.
On the Helm page, click Deploy. On the Basic Information page, configure the parameters, select the ratify chart, and click Next.
Parameter
Example
Application Name
ratify
Namespace
Select ratify.
Source
The default value is Marketplace.
Chart
Use Scenarios: Select All.
Supported Architecture: Select amd64.
Search box: Search for ratify.

On the Parameters page, select a Chart Version. If you want to pull images using RAM Roles for Service Accounts (RRSA), modify the parameters based on the example configurations. Then, click OK.

Parameter	Description	Default	Example configuration
`ServiceAccount.create`	Specifies whether to create a dedicated ServiceAccount for Ratify. Valid values: `true` (default): automatically creates a ServiceAccount named `ratify-admin`. `false`: does not automatically create a ServiceAccount. If you want to use RRSA to pull images, you must create a ServiceAccount in advance.	`true`	Keep the default value.
`ServiceAccount.name`	The custom name of the Ratify ServiceAccount.	`ratify-admin`	Keep the default value.
`ServiceAccount.annotations`	The custom annotations of the ServiceAccount.	`{}`	Add the `pod-identity.alibabacloud.com/role-name: <Your-RRSA-role>` annotation to enable automatic injection. Note Replace `<Your-RRSA-role>` with the RRSA role that you use.
`oras.authProviders.k8secretsEnabled`	Specifies whether to enable the Kubernetes Secrets Provider for authentication with the image repository.	`false`	Keep the default value. Note For more information about ORAS configurations, see ORAS Store configuration example.
`oras.authProviders.alibabacloudAcrBasicEnabled`	Specifies whether to enable the Alibaba Cloud ACR Provider for RRSA authentication of ACR image repository instances.	`false`	`true`
`oras.cache.enabled`	Specifies whether to enable ORAS store caching for `ListReferrers` and `GetSubjectDescriptor`. Important After you enable this parameter, the TTL-based cache may be inconsistent with the data source. If you require strong consistency, disable this parameter.	`true`	Keep the default value.
`oras.cache.ttl`	The TTL of the cache in the ORAS Store.	`10`	Keep the default value.
`alibabacloudAcrConfig.defaultInstanceId`	The default instance ID of the ACR repository where the destination artifact is located.	``	Required. You must configure the instance ID of the created ACR Enterprise Edition repository.
`alibabacloudAcrConfig.acrInstancesConfig`	To pull images from different Alibaba Cloud ACR repository instances, you must define the `instanceName` and `instanceId` of each instance in the list.	[]	Set this parameter to the following content to connect to the Alibaba Cloud ACR private repository.
`upgradeCRDs.enabled`	Specifies whether to enable or disable the pre-install chart hooks plug-in for Ratify CRD upgrades.	`true`	If you do not need to upgrade the Ratify CRD, you can set this parameter to `false`. Note If you set this parameter to `true`, a `pre-install hook` is triggered, which may cause an installation timeout.
`featureFlags.RATIFY_CERT_ROTATION`	Specifies whether to enable or disable TLS certificate rotation. This configuration allows Ratify to automatically generate and rotate certificates.	`false`	You must set this parameter to `true` to allow the Ratify backend to automatically generate and rotate certificates.
`notationCert`	Deprecated. Use `notationCerts` instead to specify the queue of verification certificates for Notation. The public keys of the specified certificates and certificate chains are used to create the built-in certstore used by the Notation verifier.	None	Keep the default value.
`notationCerts`	Used to configure the queue of public key certificates and certificate chains for the built-in certstore in the Notation verifier.	``	You must specify the KMS verification certificate that is returned during the signing process of the Notation plug-in. For example:

In the navigation pane on the left, choose Security > Policy Governance. Click the My Policies tab and verify that the RatifyVerification policy exists.

2. Configure RRSA to pull signature information of private ACR images

Ratify supports pulling signature data from private Alibaba Cloud ACR repositories using RRSA. For more information, see Use RRSA to configure RAM permissions for a ServiceAccount to implement pod permission isolation.

On the Add-ons page of the specified cluster, install the ack-pod-identity-webhook component.

Create a RAM role named ratify-role, set its trusted entity type to identity provider, and configure the condition fields. You can also use the ack-ram-tool CLI tool to automate the configuration.

{
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "oidc:aud": "sts.aliyuncs.com",
      "oidc:iss": "<oidc_issuer_url>",
      "oidc:sub": "system:serviceaccount:<namespace>:<service_account>" # Use the namespace and ServiceAccount of the installed Ratify component.
    }
  },
  "Effect": "Allow",
  "Principal": {
    "Federated": [
      "<oidc_provider_arn>"
    ]
  }
}

Grant the AliyunContainerRegistryFullAccess permission to the ratify-role RAM role.
When you deploy Ratify, create a ServiceAccount and set the following annotation for the ServiceAccount and the namespace where Ratify is deployed. After deployment, you can see that the ALIBABA_CLOUD_ROLE_ARN, ALIBABA_CLOUD_OIDC_PROVIDER_ARN, and ALIBABA_CLOUD_OIDC_TOKEN_FILE environment variables are injected into the Ratify pod template.
Note
If you have created a ServiceAccount in advance, add the pod-identity.alibabacloud.com/role-name: ratify-role annotation to it.
```
---
apiVersion: v1
kind: Namespace
metadata:
  name: ratify  # Specify the name of the Namespace.
  labels:
    pod-identity.alibabacloud.com/injection: 'on'

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ratify-admin    # Specify the name of the ServiceAccount.
  namespace: ratify     # Specify the name of the Namespace.
  annotations:
    pod-identity.alibabacloud.com/role-name: ratify-role # The name of the RAM role created above.

---
```

Step 5: Verify that signing and signature verification have taken effect

Deploy an application that uses a specified image in an ACK cluster to verify that the image signing and signature verification features are working.

If you deploy an image with a valid signature, the workload is successfully deployed in the destination cluster.
If you deploy a workload that uses an unsigned image, Ratify blocks the deployment. You can run a kubectl command to check the workload status and retrieve the blocking information. You can also view detailed signature verification logs in the Ratify pod logs.
```
kubectl get deploy ${unsigned_deploy_name} -n${namespace} -oyaml  # Enter the application name and its namespace.
```
The signature verification logs are as follows:

More information about Ratify configurations

Ratify provides various built-in and external Verifier plug-ins to specify the artifact types that the verifier processes. You can customize KeyManagementProvider (KMP) instances based on different signature verification requirements and define the keys or certificates used for Verifier signature verification in different scenarios. Ratify also provides a Store to discover and retrieve metadata of associated types in the subject field of the OCI v1.1 specification. The following sections provide configuration examples:

Notation Verifier configuration example

You can define the name and artifactType fields in a Verifier to specify the artifact type. Verifiers can be defined at the cluster level, or at the namespace level using the NamespacedVerifier type. For more information about Verifiers, see the official Ratify documentation.

After you install the Ratify component with the default configurations, a Notation Verifier instance is automatically created in the cluster. You can configure a specific trustPolicyDoc policy based on your requirements. The following code provides a configuration example:

Click to view the Notation Verifier configuration example

apiVersion: config.ratify.deislabs.io/v1beta1
kind: Verifier
metadata:
  name: verifier-notation
spec:
  artifactTypes: application/vnd.cncf.notary.signature
  name: notation
  parameters:
    trustPolicyDoc:
      trustPolicies:
      - name: default
        registryScopes:
        - '*'
        signatureVerification:
          level: strict
        trustStores:
        - ca:certs
        trustedIdentities:
        - '*'
      version: "1.0"
    verificationCertStores:
      certs:
      - ratify-notation-inline-cert
  version: 1.0.0
status:
  issuccess: true

KMP configuration example

You can customize KeyManagementProvider instances for different signature verification requirements and define public keys or X.509 certificates in the CR. During signature verification, verifiers such as Notation and Cosign are associated with the corresponding KMP instance resources. KMP supports definitions at the cluster and namespace levels. For more information about KMP, see the official documentation of Ratify. The following code provides a configuration example:

Click to view the KMP configuration example

apiVersion: config.ratify.deislabs.io/v1beta1
kind: KeyManagementProvider
metadata:
  name: ratify-notation-inline-cert
spec:
  parameters:
    contentType: certificate
    value: |
      -----BEGIN CERTIFICATE-----
      XXXXXX
      XXXXXX
      XXXXXX
      -----END CERTIFICATE-----
  type: inline

ORAS Store configuration example

After you install the Ratify component, you can configure the authProvider parameter in the default ORAS Store instance to connect to the private Alibaba Cloud ACR repository. The following code provides a configuration example:

Click to view the ORAS Store configuration example

apiVersion: config.ratify.deislabs.io/v1beta1
kind: Store
metadata:
  name: store-oras
spec:
  name: oras
  parameters:
    authProvider:
      acrInstancesConfig:
      - instanceName: name1
        instanceId: cri-aaaaaaaaaaaa
      - instanceName: name2
        instanceId: cri-bbbbbbbbbbbb
      defaultInstanceId: cri-ccccccccc
      name: alibabacloudAcrBasic

Parameter name	Required	Description
`name`	No	The value of `authProvider.name` for Alibaba Cloud ACR is fixed at `alibabacloudAcrBasic`.
`acrInstancesConfig`	No	You can configure mappings between multiple ACR repository instances and instance IDs. Ratify obtains the corresponding instance ID based on the image repository name specified in the application workload.
`defaultInstanceId`	Yes	The ID of the default repository instance. Note If the instance ID cannot be obtained from `acrInstancesConfig`, Ratify uses the default repository instance ID specified in the `defaultInstanceId` field. Then, Ratify obtains the temporary username and password for logging on to the ACR repository instance based on the Alibaba Cloud Credentials configured in the environment.

Key management type	KMS key specification	Wrapping public key type	Encryption algorithm
Software-protected key	RSA_2048 RSA_3072 EC_P256 EC_P256K	RSA_2048	RSAES_OAEP_SHA_256_AES_256_ECB_PKCS7_PAD

Parameter	Example
Application Name	ratify
Namespace	Select ratify.
Source	The default value is Marketplace.
Chart	Use Scenarios: Select All. Supported Architecture: Select amd64. Search box: Search for ratify.