Signing with AWS Signer Profile and Deployment to Amazon EKS Cluster

Overview

Container image signing with AWS Signer Profile and deploying to the Amazon EKS cluster ensures the integrity and authenticity of container images before they are deployed to a Kubernetes cluster. This process involves creating an AWS Signer signing profile, signing the container image with the signing profile, and configuring the Kubernetes cluster to verify the signature of the image before it is deployed. This process helps to ensure that only trusted images are deployed to the cluster, which can help to improve security and compliance.

Pioneers in Cloud Consulting & Migration Services

Reduced infrastructural costs
Accelerated application deployment

Get Started

Introduction

Customers may now sign and validate container images stored in container registries such as Amazon Elastic Container Registry (Amazon ECR) with native AWS support according to a new feature called AWS Signer Container Image Signing.

AWS Signer is a fully managed code signing solution that ensures your code is trustworthy and reliable. In addition to managing public and private keys and code signing certificates, AWS Signer offers several tools that streamline lifecycle management, allowing you to concentrate on signing and validating your code.

AWS Signer is a fully managed code signing service to help you ensure the trust and integrity of your container images. Organizations validate images against a digital signature to confirm that the image is unaltered and from a trusted publisher.

Pre-requisites

Amazon EC2 instance
Install eksctl
Install Kubectl
Install helm
Install Notation cli
Docker
Ratify
Jq

Steps to be performed on your Amazon EC2 instance

Attach a role that contains the Amazon ECR, AWS Signer Profile, Amazon EC2, Amazon EKS, and other required permissions to your Amazon EC2 instance.
Install aws cli, eksctl, helm from: https://codeshare.io/EBxAE4
Install notation CLI

wget https://d2hvyiie56hcat.cloudfront.net/linux/amd64/installer/rpm/latest/aws-signer-notation-cli_amd64.rpm

rpm -ivh aws-signer-notation-cli_amd64.rpm

wget https://d2hvyiie56hcat.cloudfront.net/linux/amd64/installer/rpm/latest/aws-signer-notation-cli_amd64.rpm

rpm -ivh aws-signer-notation-cli_amd64.rpm

Create an Amazon ECR repo, push one sample image to Amazon ECR (ex: nginx image), and export REPO_URI as a global variable for further reference.

Ex: export REPO_URI=<Account_id>. dkr.ecr.ap-south-1.amazonaws.com/<repo_name>

Create Amazon EKS Cluster

eksctl create cluster\
  --name ratify-demo \
  --region ap-south-1 \
  --zones ap-south-1a,ap-south-1b \
  --with-oidc \
  --ssh-access \
  --ssh-public-key ratifyDemo

eksctl create cluster\

--name ratify-demo \

--region ap-south-1 \

--zones ap-south-1a,ap-south-1b \

--with-oidc \

--ssh-access \

--ssh-public-key ratifyDemo

It will take approx. 15 minutes to create the Amazon EKS Cluster with oidc.

Meanwhile, you can sign off on Amazon ECR Image through the notation CLI.

Sign Container image

Create AWS Signer profile and export the ARN as a Global Variable

aws signer put-signing-profile \
    --profile-name ratifyDemo \
    --platform-id Notation-OCI-SHA384-ECDSA
 
export PROFILE_ARN=$(aws signer get-signing-profile --profile-name ratifyDemo | jq .arn -r)

aws signer put-signing-profile \

--profile-name ratifyDemo \

--platform-id Notation-OCI-SHA384-ECDSA

export PROFILE_ARN=$(aws signer get-signing-profile --profile-name ratifyDemo | jq .arn -r)

notation key add \
    --plugin com.amazonaws.signer.notation.plugin \
    --id $PROFILE_ARN \
    --default ratifyDemo

notation key add \

--plugin com.amazonaws.signer.notation.plugin \

--id $PROFILE_ARN \

--default ratifyDemo

Sign the image with the Image tag

notation sign $REPO_URI:v1
notation inspect $REPO_URI:v1

1 2	notation sign $REPO_URI:v1 notation inspect $REPO_URI:v1

Now, you can verify the Amazon ECR image has been signed successfully, and the signature can be seen in the Console.

step1

Deploy Gatekeeper

Although Gatekeeper serves as Kubernetes’ policy controller, the actual validation of images and their artifacts will be carried out by the Ratify container.

We first need to install Gatekeeper into the cluster. We will use the Gatekeeper helm chart with some customizations:

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
 
helm install gatekeeper/gatekeeper  \
    --name-template=gatekeeper \
    --namespace gatekeeper-system --create-namespace \
    --set enableExternalData=true \
    --set validatingWebhookTimeoutSeconds=5 \
    --set mutatingWebhookTimeoutSeconds=2

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

helm install gatekeeper/gatekeeper \

--name-template=gatekeeper \

--namespace gatekeeper-system --create-namespace \

--set enableExternalData=true \

--set validatingWebhookTimeoutSeconds=5 \

--set mutatingWebhookTimeoutSeconds=2

Next, we need to deploy a Gatekeeper policy and constraint.

kubectl apply -f https://deislabs.github.io/ratify/library/default/template.yaml

kubectl apply -f https://deislabs.github.io/ratify/library/default/samples/constraint.yaml

kubectl apply -f https://deislabs.github.io/ratify/library/default/template.yaml

kubectl apply -f https://deislabs.github.io/ratify/library/default/samples/constraint.yaml

Configure AWS IAM Permission

Before deploying Ratify, we need to configure Ratify permissions to request AWS Signer. We will use AWS IAM Roles for Service Accounts integration to do this. First, we need to create an AWS IAM policy that has AWS Signer permissions:

cat > signer_policy.json << EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "signer:GetRevocationStatus"
            ],
            "Resource": "*"
        }
    ]
}
EOF
 
export POLICY_ARN=$(aws iam create-policy \
    --policy-name signerGetRevocationStatus \
    --policy-document file://signer_policy.json \
    | jq ."Policy"."Arn" -r)

cat > signer_policy.json << EOF

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": [

"signer:GetRevocationStatus"

"Resource": "*"

}

]

}

EOF

export POLICY_ARN=$(aws iam create-policy \

--policy-name signerGetRevocationStatus \

--policy-document file://signer_policy.json \

| jq ."Policy"."Arn" -r)

Then, we will use eksctl to create a service account and role and attach the policies to the role:

eksctl create iamserviceaccount \
    --name ratify-admin \
    --namespace gatekeeper-system \
    --cluster ratify-demo \
    --attach-policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
    --attach-policy-arn $POLICY_ARN \
    --approve

eksctl create iamserviceaccount \

--name ratify-admin \

--namespace gatekeeper-system \

--cluster ratify-demo \

--attach-policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \

--attach-policy-arn $POLICY_ARN \

--approve

We can validate that the service account was created by using kubectl:

kubectl -n gatekeeper-system get sa

1	kubectl -n gatekeeper-system get sa

Deploy Ratify

Now we can deploy Ratify to our cluster with the AWS Signer root as the notation verification certificate:

helm repo add ratify https://deislabs.github.io/ratify
helm repo update

curl -sSLO https://d2hvyiie56hcat.cloudfront.net/aws-signer-notation-root.cert
 
helm install ratify \
    ratify/ratify --atomic \
    --namespace gatekeeper-system \
    --set-file notationCert=./aws-signer-notation-root.cert \
    --set featureFlags.RATIFY_CERT_ROTATION=true \
    --set featureFlags.RATIFY_EXPERIMENTAL_DYNAMIC_PLUGINS=true \
    --set serviceAccount.create=false \
    --set oras.authProviders.awsEcrBasicEnabled=true

helm repo add ratify https://deislabs.github.io/ratify

helm repo update

curl -sSLO https://d2hvyiie56hcat.cloudfront.net/aws-signer-notation-root.cert

helm install ratify \

ratify/ratify --atomic \

--namespace gatekeeper-system \

--set-file notationCert=./aws-signer-notation-root.cert \

--set featureFlags.RATIFY_CERT_ROTATION=true \

--set featureFlags.RATIFY_EXPERIMENTAL_DYNAMIC_PLUGINS=true \

--set serviceAccount.create=false \

--set oras.authProviders.awsEcrBasicEnabled=true

After deploying Ratify, we will download the AWS Signer notation plugin to the Ratify pod:

cat > aws-signer-plugin.yaml << EOF
apiVersion: config.ratify.deislabs.io/v1beta1
kind: Verifier
metadata:
  name: aws-signer-plugin
spec:
  name: notation-com.amazonaws.signer.notation.plugin
  artifactTypes: application/vnd.oci.image.manifest.v1+json
  source:
    artifact: public.ecr.aws/aws-signer/notation-plugin:linux-amd64-latest
EOF
 
kubectl apply -f aws-signer-plugin.yaml

cat > aws-signer-plugin.yaml << EOF

apiVersion: config.ratify.deislabs.io/v1beta1

kind: Verifier

metadata:

spec:

artifactTypes: application/vnd.oci.image.manifest.v1+json

source:

artifact: public.ecr.aws/aws-signer/notation-plugin:linux-amd64-latest

EOF

kubectl apply -f aws-signer-plugin.yaml

Finally, we will create a verifier that specifies the trust policy to use when verifying signatures. In this guide, we will use a trust policy that only trusts images signed by the SigningProfile we created earlier:

cat > notation-verifier.yaml << EOF
apiVersion: config.ratify.deislabs.io/v1beta1
kind: Verifier
metadata:
  name: verifier-notation
spec:
  name: notation
  artifactTypes: application/vnd.cncf.notary.signature
  parameters:
    verificationCertStores:
      certs:
        - ratify-notation-inline-cert
    trustPolicyDoc:
      version: "1.0"
      trustPolicies:
        - name: default
          registryScopes:
            - "*"
          signatureVerification:
            level: strict
          trustStores:
            - signingAuthority:certs
          trustedIdentities:
            - $PROFILE_ARN
EOF
 
kubectl apply -f notation-verifier.yaml

cat > notation-verifier.yaml << EOF

apiVersion: config.ratify.deislabs.io/v1beta1

kind: Verifier

metadata:

spec:

artifactTypes: application/vnd.cncf.notary.signature

parameters:

verificationCertStores:

certs:

- ratify-notation-inline-cert

trustPolicyDoc:

version: "1.0"

trustPolicies:

- name: default

registryScopes:

- "*"

signatureVerification:

level: strict

trustStores:

- signingAuthority:certs

trustedIdentities:

- $PROFILE_ARN

EOF

kubectl apply -f notation-verifier.yaml

Deploy Container Image:

Now that the signed container image is in the registry and Ratify is installed into the Amazon EKS cluster, we can deploy our container image:

kubectl run demosigned --image $REPO_URI:latest

1	kubectl run demosigned --image $REPO_URI:latest

We should see from the Ratify and Gatekeeper logs that the container signature was validated. The pod for the container should also be running.

kubectl logs -n gatekeeper-system deployment/ratify

1	kubectl logs -n gatekeeper-system deployment/ratify

We can also test that an image without a valid signature is not able to run:

kubectl run demounsigned --image hello-world

1	kubectl run demounsigned --image hello-world

The command should fail with an error, and we should be able to see from the Ratify and Gatekeeper logs that the signature validation failed.

Conclusion

This post provided an overview of AWS Signer Container Image Signing. This new feature allows you to sign and validate your container images using a fully managed solution. You may implement a straightforward client-based procedure for signing and validating your container images using the open-source Notation client with the carefully chosen AWS Signer plugin.

Drop a query if you have any questions regarding AWS Signer Container Image Signing and we will get back to you quickly.

Making IT Networks Enterprise-ready – Cloud Management Services

Accelerated cloud migration
End-to-end view of the cloud environment

Get Started

About CloudThat

CloudThat is a leading provider of Cloud Training and Consulting services with a global presence in India, the USA, Asia, Europe, and Africa. Specializing in AWS, Microsoft Azure, GCP, VMware, Databricks, and more, the company serves mid-market and enterprise clients, offering comprehensive expertise in Cloud Migration, Data Platforms, DevOps, IoT, AI/ML, and more.

CloudThat is recognized as a top-tier partner with AWS and Microsoft, including the prestigious ‘Think Big’ partner award from AWS and the Microsoft Superstars FY 2023 award in Asia & India. Having trained 650k+ professionals in 500+ cloud certifications and completed 300+ consulting projects globally, CloudThat is an official AWS Advanced Consulting Partner, AWS Training Partner, AWS Migration Partner, AWS Data and Analytics Partner, AWS DevOps Competency Partner, Amazon QuickSight Service Delivery Partner, Amazon EKS Service Delivery Partner, Microsoft Gold Partner, AWS Microsoft Workload Partners, Amazon EC2 Service Delivery Partner, and many more.

To get started, go through our Consultancy page and Managed Services Package, CloudThat’s offerings.

FAQs

1. What is the benefit of using AWS Signer Container Image Signing?

ANS: – This new feature helps ensure the trust and integrity of your container images by adding a digital signature. This signature confirms that the image is unaltered and comes from a trusted publisher like you. This is especially important for sensitive workloads or when you must comply with strict security regulations.

2. How does the process of signing and validating container images work?

ANS: – You can sign your images using the open-source Notation client with the AWS Signer plugin. This creates a unique signature that’s stored with the image. Then, Ratify, a policy controller deployed in your EKS cluster, validates the signature against your trust policy. If the signature matches, the image is allowed to run. If not, it’s blocked. This helps prevent unauthorized or compromised images from running in your cluster.

WRITTEN BY Ravikumar Eranna Murali

Ravikumar works as a Sr. Research Associate at CloudThat. His expertise lies in AWS Services and pursuing DevOps technologies like Kubernetes, Docker, and Jenkins. Ravi enjoys learning and working on new challenges to give the best solution.