Best Practices to help secure your container image build pipeline by using AWS Signer

[ad_1]

AWS Signer is a completely managed code-signing service to assist make sure the belief and integrity of your code. It helps you confirm that the code comes from a trusted supply and that an unauthorized get together has not accessed it. AWS Signer manages code signing certificates and private and non-private keys, which might scale back the overhead of your public key infrastructure (PKI) administration. It additionally supplies a set of options to simplify lifecycle administration of your keys and certificates so to concentrate on signing and verifying your code.

In June 2023, AWS introduced Container Picture Signing with AWS Signer and Amazon EKS, a brand new functionality that provides you native AWS help for signing and verifying container photographs saved in Amazon Elastic Container Registry (Amazon ECR).

Containers and AWS Lambda features are well-liked serverless compute options for functions constructed on the cloud. Through the use of AWS Signer, you possibly can confirm that the software program working in these workloads originates from a trusted supply.

On this weblog put up, you’ll find out about the advantages of code signing for software program safety, governance, and compliance wants. Versatile steady integration and steady supply (CI/CD) integration, administration of signing identities, and native integration with different AWS companies may also help you simplify code safety by automation.

Background

Code signing is a vital a part of the software program provide chain. It helps be certain that the code is unaltered and comes from an accepted supply.

To automate software program improvement workflows, organizations usually implement a CI/CD pipeline to push, take a look at, and deploy code successfully. You’ll be able to combine code signing into the workflow to assist stop untrusted code from being deployed, as proven in Determine 1. Code signing within the pipeline can offer you several types of data, relying on the way you resolve to make use of the performance. For instance, you possibly can combine code signing into the construct stage to attest that the code was scanned for vulnerabilities, had its software program invoice of supplies (SBOM) accepted internally, and underwent unit and integration testing. You can too use code signing to confirm who has pushed or printed the code, corresponding to a developer, staff, or group. You’ll be able to confirm every of those steps individually by together with a number of signing levels within the pipeline. For extra data on the worth offered by container picture signing, see Cryptographic Signing for Containers.

Determine 1: Safety IN the pipeline

Within the following part, we are going to stroll you thru a easy implementation of picture signing and its verification for Amazon Elastic Kubernetes Service (Amazon EKS) deployment. The signature attests that the container picture went by the pipeline and got here from a trusted supply. You should use this course of in additional complicated situations by including a number of AWS CodeBuild code signing levels that make use of assorted AWS Signer signing profiles.

Companies and instruments

On this part, we talk about the assorted AWS companies and third-party instruments that you simply want for this resolution.

CI/CD companies

For the CI/CD pipeline, you’ll use the next AWS companies:

AWS CodePipeline — a completely managed steady supply service that you need to use to automate your launch pipelines for quick and dependable software and infrastructure updates.
AWS CodeCommit — a completely managed supply management service that hosts safe Git-based repositories.
AWS Signer — a completely managed code-signing service that you need to use to assist make sure the belief and integrity of your code.
AWS CodeBuild — A completely managed steady integration service that compiles supply code, runs checks, and produces software program packages which might be able to deploy.

Container companies

You’ll use the next AWS companies for containers for this walkthrough:

Amazon EKS — a managed Kubernetes service to run Kubernetes within the AWS Cloud and on-premises information facilities.
Amazon ECR — a completely managed container registry for high-performance internet hosting, so to reliably deploy software photographs and artifacts anyplace.

Verification instruments

The next are publicly obtainable signal verification instruments that we built-in into the pipeline for this put up, however you may combine different instruments that meet your particular necessities.

Notation — A publicly obtainable Notary mission throughout the Cloud Native Computing Basis (CNCF). With contributions from AWS and others, Notary is an open customary and shopper implementation that enables for vendor-specific plugins for key administration and different integrations. AWS Signer manages signing keys, key rotation, and PKI administration for you, and is built-in with Notation by a curated plugin that gives a easy client-based workflow.
Kyverno — A publicly obtainable coverage engine that’s designed for Kubernetes.

Resolution overview

Determine 2: Resolution structure

Right here’s how the answer works, as proven in Determine 2:

Builders push Dockerfiles and software code to CodeCommit. Every push to CodeCommit begins a pipeline hosted on CodePipeline.
CodeBuild packages the construct, containerizes the appliance, and shops the picture within the ECR registry.
CodeBuild retrieves a selected model of the picture that was beforehand pushed to Amazon ECR. AWS Signer and Notation signal the picture through the use of the signing profile established beforehand, as proven in additional element in Determine 3.

Determine 3: Signing photographs described

AWS Signer and Notation confirm the signed picture model after which deploy it to an Amazon EKS cluster.

If the picture has not beforehand been signed appropriately, the CodeBuild log shows an output much like the next:

Error: signature verification failed: no signature is related to “<AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/hello-server@<DIGEST>” , be sure that the artifact was signed efficiently

If there’s a signature mismatch, the CodeBuild log shows an output much like the next:

Error: signature verification failed for all of the signatures related to <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/hello-server@<DIGEST>

Kyverno verifies the container picture signature to be used within the Amazon EKS cluster.

Determine 4 reveals steps 4 and 5 in additional element.

Figure 4: Verification of image signature for Kubernetes

Determine 4: Verification of picture signature for Kubernetes

Conditions

Earlier than getting began, just be sure you have the next stipulations in place:

An Amazon EKS cluster provisioned.
An Amazon ECR repository on your container photographs.
A CodeCommit repository together with your software code. For extra data, see Create an AWS CodeCommit repository.
A CodePipeline pipeline deployed with the CodeCommit repository because the code supply and 4 CodeBuild levels: Construct, ApplicationSigning, ApplicationDeployment, and VerifyContainerSign. The CI/CD pipeline ought to appear like that in Determine 5.

Figure 5: CI/CD pipeline with CodePipeline

Determine 5: CI/CD pipeline with CodePipeline

Walkthrough

You’ll be able to create a signing profile through the use of the AWS Command Line Interface (AWS CLI), AWS Administration Console or the AWS Signer API. On this part, we’ll stroll you thru how you can signal the picture through the use of the AWS CLI.

To signal the picture (AWS CLI)

Create a signing profile for every id.

# Create an AWS Signer signing profile with default validity interval
$ aws signer put-signing-profile
–profile-name build_signer
–platform-id Notation-OCI-SHA384-ECDSA

Signal the picture from the CodeBuild construct—your buildspec.yaml configuration file ought to appear like the next:

model: 0.2

phases:
pre_build:
instructions:
– aws ecr get-login-password –region $AWS_REGION | docker login –username AWS –password-stdin $AWS_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com
– REPOSITORY_URI=$AWS_ACCOUNT_ID.dkr.ecr. $AWS_REGION.amazonaws.com/hello-server
– COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | reduce -c 1-7)
– IMAGE_TAG=${COMMIT_HASH:=newest}
– DIGEST=$(docker manifest examine $AWS_ACCOUNT_ID.dkr.ecr. $AWS_REGION.amazonaws.com/hello-server:$IMAGE_TAG -v | jq -r ‘.Descriptor.digest’)
– echo $DIGEST

– wget https://d2hvyiie56hcat.cloudfront.web/linux/amd64/installer/rpm/newest/aws-signer-notation-cli_amd64.rpm
– sudo rpm -U aws-signer-notation-cli_amd64.rpm
– notation model
– notation plugin ls
construct:
instructions:
– notation signal $REPOSITORY_URI@$DIGEST –plugin com.amazonaws.signer.notation.plugin –id arn:aws:signer: $AWS_REGION:$AWS_ACCOUNT_ID:/signing-profiles/notation_container_signing
– notation examine $AWS_ACCOUNT_ID.dkr.ecr. $AWS_REGION.amazonaws.com/hello-server@$DIGEST
– notation confirm $AWS_ACCOUNT_ID.dkr.ecr. $AWS_REGION.amazonaws.com/hello-server@$DIGEST
post_build:
instructions:
– printf ‘[{“name”:”hello-server”,”imageUri”:”%s”}]’ $REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json
artifacts:
recordsdata: imagedefinitions.json

The instructions within the buildspec.yaml configuration file do the next:

Signal you in to Amazon ECR to work with the Docker photographs.
Reference the particular picture that can be signed through the use of the commit hash (or one other versioning technique that your group makes use of). This will get the digest.
Signal the container picture through the use of the notation signal command. This command makes use of the container picture digest, as a substitute of the picture tag.
Set up the Notation CLI. On this instance, you employ the installer for Linux. For a listing of installers for varied working methods, see the AWS Signer Developer Information,
Signal the picture through the use of the notation signal command.
Examine the signed picture to make it possible for it was signed efficiently through the use of the notation examine command.
To confirm the signed picture, use the notation confirm command. The output ought to look much like the next:

Efficiently verified signature for <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/hello-server@<DIGEST>

(Non-obligatory) For troubleshooting, print the notation coverage from the pipeline itself to verify that it’s working as anticipated by working the notation coverage present command:

For this, embody the command within the pre_build section after the notation model command within the buildspec.yaml configuration file.

After the notation coverage present command runs, CodeBuild logs ought to show an output much like the next:

{
“model”: “1.0”,
“trustPolicies”: [
{
“name”: “aws-signer-tp”,
“registryScopes”: [
“<AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/hello-server”
],
“signatureVerification”: {
“stage”: “strict”
},
“trustStores”: [
“signingAuthority:aws-signer-ts”
],
“trustedIdentities”: [
“arn:aws:signer:<AWS_REGION>:<AWS_ACCOUNT_ID>:/signing-profiles/notation_test”
]
}
]
}

To confirm the picture in Kubernetes, arrange each Kyverno and the Kyverno-notation-AWS Signer in your EKS cluster. To get began with Kyverno and the Kyverno-notation-AWS Signer resolution, see the set up directions.
After you put in Kyverno and Kyverno-notation-AWS Signer, confirm that the controller is working—the STATUS ought to present Operating:

$ kubectl get pods -n kyverno-notation-aws -w

NAME READY STATUS RESTARTS AGE
kyverno-notation-aws-75b7ddbcfc-kxwjh 1/1 Operating 0 6h58m

Configure the CodeBuild buildspec.yaml configuration file to confirm that the pictures deployed within the cluster have been beforehand signed. You should use the next code to configure the buildspec.yaml file.

model: 0.2

phases:
pre_build:
instructions:
– echo Logging in to Amazon ECR…
– aws –version
– REPOSITORY_URI=${REPO_ECR}
– COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | reduce -c 1-7)
– IMAGE_TAG=${COMMIT_HASH:=newest}
– curl -LO “https://dl.k8s.io/launch/$(curl -L -s https://dl.k8s.io/launch/steady.txt)/bin/linux/amd64/kubectl”
– curl -LO “https://dl.k8s.io/launch/$(curl -L -s https://dl.k8s.io/launch/steady.txt)/bin/linux/amd64/kubectl.sha256”
– echo “$(cat kubectl.sha256) kubectl” | sha256sum –check
— chmod +x kubectl
– mv ./kubectl /usr/native/bin/kubectl
– kubectl model –client
construct:
instructions:
– echo Construct began on `date`
– aws eks update-kubeconfig -—identify ${EKS_NAME} —-region ${AWS_DEFAULT_REGION}
– echo Deploying Utility
– sed -i ‘/picture: picture/picture: ‘”${REPOSITORY_URI}:${IMAGE_TAG}”‘/g’ deployment.yaml
– kubectl apply -f deployment.yaml
– KYVERNO_NOTATION_POD=$(kubectl get pods –no-headers -o custom-columns=”:metadata.identify” -n kyverno-notation-aws)
– STATUS=$(kubectl logs –tail=1 kyverno-notation-aws-75b7ddbcfc-kxwjh -n kyverno-notation-aws | grep $IMAGE_TAG | grep ERROR)
– |
if [[ $STATUS ]]; then
echo “There may be an error”
exit 1
else
echo “No Error”
fi
post_build:
instructions:
– printf ‘[{“name”:”hello-server”,”imageUri”:”%s”}]’ $REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json
artifacts:
recordsdata: imagedefinitions.json

The instructions within the buildspec.yaml configuration file do the next:

Arrange the setting variables, such because the ECR repository URI and the Commit hash, to construct the picture tag. The kubectl device will use this later to reference the container picture that can be deployed with the Kubernetes objects.
Use kubectl to hook up with the EKS cluster and insert the container picture reference within the deployment.yaml file.
After the container is deployed, you possibly can observe the kyverno-notation-aws controller and entry its logs. You’ll be able to verify if the deployed picture is signed. If the logs comprise an error, cease the pipeline run with an error code, do a rollback to a earlier model, or delete the deployment when you detect that the picture isn’t signed.

Decommission the AWS assets

If you happen to not want the assets that you simply provisioned for this put up, full the next steps to delete them.

To wash up the assets

Delete the EKS cluster and delete the ECR picture.
Delete the IAM roles and insurance policies that you simply used for the configuration of IAM roles for service accounts.
Revoke the AWS Signer signing profile that you simply created and used for the signing course of by working the next command within the AWS CLI:

$ aws signer revoke-signing-profile

Delete signatures from the Amazon ECR repository. Be sure to interchange <AWS_ACCOUNT_ID> and <AWS_REGION> with your individual data.

# Use oras CLI, with Amazon ECR Docker Credential Helper, to delete signature
$ oras manifest delete <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/pause@sha256:ca78e5f730f9a789ef8c63bb55275ac12dfb9e8099e6a0a64375d8a95ed501c4

Word: Utilizing the ORAS mission’s oras shopper, you possibly can delete signatures and different reference kind artifacts. It implements deletion by first eradicating the reference from an index, after which deleting the manifest.

Conclusion

On this put up, you discovered how you can implement container picture signing in a CI/CD pipeline through the use of AWS companies corresponding to CodePipeline, CodeBuild, Amazon ECR, and AWS Signer together with publicly obtainable instruments corresponding to Notary and Kyverno. By implementing obligatory picture signing in your pipelines, you possibly can verify that solely validated and approved container photographs are deployed to manufacturing. Automating the signing course of and signature verification is significant to assist securely deploy containers at scale. You additionally discovered how you can confirm signed photographs each throughout deployment and at runtime in Kubernetes. This put up supplies precious insights for anybody wanting so as to add picture signing capabilities to their CI/CD pipelines on AWS to supply provide chain safety assurances. The mix of AWS managed companies and publicly obtainable instruments supplies a strong implementation.

In case you have suggestions about this put up, submit feedback within the Feedback part beneath. In case you have questions on this put up, contact AWS Help.

Need extra AWS Safety information? Comply with us on Twitter.

Jorge Castillo

Jorge is a Options Architect at AWS for the general public sector primarily based in Santiago, Chile. He focuses on safety and compliance and works with many authorities businesses.

Joseph Rodríguez

Joseph is a Options Architect at AWS for the general public sector primarily based in Chile. Joseph has collaborated with a number of public sector establishments on cloud know-how adoption, with a concentrate on containers. He beforehand labored as a Software program Architect at monetary companies establishments.

Monika Vu Minh

Monika is a ProServe Safety Marketing consultant at AWS primarily based in London. She works with monetary companies prospects to assist them comply with safety greatest practices on AWS. In her free time, she likes portray, cooking, and travelling.

[ad_2]

Source link