Docker image to run the AWS CLI and related tools.
This image is based on the official
amazon/aws-cli image. The
main difference is that default entrypoint of the official image is
aws
because it is the only command that this image is meant to run.
On the other hand, this image's default entrypoint is a shell (bash
)
in which you can run not only aws
but also other commands typically
useful when building a more advanced CI/CD pipeline. For example this
image includes the jq
utility often very useful to process the
output of the aws
command. The tool cfn-policy-validator
is also
included to run IAM policies from a CloudFormation template through
IAM Access Analyzer checks.
Another significant difference with the official image is that this
image is not running using the root
user. Running as root
should
not be necessary for CI/CD activities and it is considered a security
risk.
To run the AWS CLI using this image:
docker run --rm -i leplusorg/aws-cli aws --version
To get the SBOM for the latest image (in SPDX JSON format), use the following command:
docker buildx imagetools inspect leplusorg/aws-cli --format '{{ json (index .SBOM "linux/amd64").SPDX }}'
Replace linux/amd64
by the desired platform (linux/amd64
, linux/arm64
etc.).
Sigstore is trying to improve supply chain security by allowing you to verify the origin of an artifcat. You can verify that the jar that you use was actually produced by this repository. This means that if you verify the signature of the ristretto jar, you can trust the integrity of the whole supply chain from code source, to CI/CD build, to distribution on Maven Central or whever you got the jar from.
You can use the following command to verify the latest image using its sigstore signature attestation:
cosign verify leplusorg/aws-cli --certificate-identity-regexp 'https://github\.com/leplusorg/docker-aws-cli/\.github/workflows/.+' --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
The output should look something like this:
Verification for index.docker.io/leplusorg/xml:main --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- Existence of the claims in the transparency log was verified offline
- The code-signing certificate was verified using trusted certificate authority certificates
[{"critical":...
For instructions on how to install cosign
, please read this documentation.