.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Low-Code/No Code Artifact Signing
A low-code/no code artifact signing solution makes it easy to implement an enterprise solution for verifying authenticity of software artifacts and tracing their origins.
A low-code/no code artifact signing solution makes it easy to implement an enterprise solution for verifying authenticity of software artifacts and tracing their origins.
A low-code/no code artifact signing solution makes it easy to implement an enterprise solution for verifying authenticity of software artifacts and tracing their origins.
A low-code/no code artifact signing solution makes it easy to implement an enterprise solution for verifying authenticity of software artifacts and tracing their origins.
A low-code/no code artifact signing solution makes it easy to implement an enterprise solution for verifying authenticity of software artifacts and tracing their origins.
Endor Labs customers can implement private code signing in a manner that is private, seamless, and simple — making it an alternative to Sigstore for organizations that need a private transparency log and don’t want to take on the complexity of deploying and managing the necessary infrastructure to implement Sigstore at scale. In Signing Your Artifacts For Security, Quality, and Compliance, we laid out the many use cases for artifact signing, and we demonstrated one such use case in Improve Kubernetes Security with Signed Artifacts and Admission Controllers. In this blog, we do a deep-dive on our low-code/no code design philosophy so you can decide if our approach is right for your organization.
Keyless, Identity-Based Artifact Signing
Artifact signing requires infrastructure for four main capabilities:
- Establishing the identity of a signer
- Managing the lifecycle of signing certificate data
- Managing signature data (including revocations and related status)
- Retaining a tamper-resistant log of signature events
Once these components are set up and secured, pipelines can be configured to create signatures. And admission controllers, pipelines, scanners, and other components can verify signatures and logs.
Because these components can be costly to set up, maintain, and continuously secure, Endor Labs created a “keyless” identity-based artifact signing system that leverages an organization’s existing identity infrastructure and provides the remaining components, making for a solution that:
- Requires no net new infrastructure to deploy, secure, and maintain
- Manages keys transparently
- Integrates quickly, with no-code or low-code deployments, into CI/CD pipelines, admission controllers, and other environments for signing and verification
Identity-Based and Keyless Signing
Artifact signing requires a trustworthy identity with which to request signatures. Endor Labs artifact signing solves this by using your existing identity stores, connecting to them through broadly-adopted standards.
Our solution is based on identity-based or keyless signing that primarily relies on our existing support for workflow based OpenID Connect (OIDC) authentication. Based on the OIDC token provided by the issuer (e.g. GitHub), our private certificate authority (CA) issues a short-lived certificate that binds an ephemeral key to the OIDC identity. Once the artifact is signed with the provided certificate, we create an immutable entry in the database, specific to the tenant namespace that the signature is associated with. Any subsequent signing operations for the same artifact name will create entirely new entries in the database.
No Tags
For the case of container images, we have decided to require specific identifiers (currently, SHA256 digests) to uniquely identify the artifact. We made the decision to not support tags (e.g., latest), which can lead to ambiguities as to which image is going to be signed. Using digests only makes sure that the image being signed and run is exactly the one that was intended and has been verified as secure.
No Need for Artifact Registry Access
Because of the decision to use the SHA256 digest to uniquely identify the artifact, Endor Labs does not need additional access privileges to private artifact registries in order to resolve a tag to a digest. When a request to sign a container image is made using a tag, e.g. “example.com/ubuntu@latest”, the software would need to access the artifact registry in order to retrieve the digest corresponding to the “latest” tag. In most cases, these registries are private and require special permissions to access.
Given that the workflow initiating the sign operation will be in close proximity to the build operation, which should have the proper access privileges to the artifact registry storing the images, it’s quite natural and straightforward to also retrieve the container’s digest and provide it to the sign operation. This means that Endor Labs will not need to be provided any additional permissions to the artifact registry in order to obtain the digest ourselves.
Keyless Signing Components
There are three main components that are instrumental for keyless signing:
- Identity Provider (IdP)
- Certificate Authority
- Timestamp Authority & Transparency log
Identity Provider (IdP)
The IdP was already solved by Endor Labs for our scanning workflows. When a sign request gets processed, an attempt to retrieve a token is initiated with an OIDC IdP (such as GitHub). For example, in the case of the integration with the GitHub actions, an interaction with GitHub is initiated and a token is obtained with claims as part of it. For example:
Build config digest: ec0282333b338d0abaddf7d7e8033eb2e1ecc9c1
Build config name: Release
Certificate identity: repo:endorlabs/monorepo:ref:refs/tags/v1.6.216
Certificate OIDC issuer: https://token.actions.githubusercontent.com
Runner environment: self-hosted
Source repository: endorlabs/monorepo
Source repository digest: ec0282333b338d0abaddf7d7e8033eb2e1ecc9c1
Source repository owner: endorlabs
Source repository ref: refs/tags/v1.6.216
Certificate Authority (CA)
All of our microservices talk to each other using mTLS certificates that are obtained from another microservice that is our certificate authority.
In order to support signing, we extended our CA to also support code signing certificates. In effect, when a request to sign an artifact is received, a new certificate request is sent to the CA with an ephemeral public key and any claims that we have received with the token.
Specifically, these are the steps:
- Create ephemeral ECDSA-256 private key/public key pair
- Create certificate request (CSR) including the public key and any relevant claims to be maintained.
- Send the CSR to the Certificate Authority which creates the x509 certificate with a 5 minute validity, adding any passed claims as pkix certificate extensions
- Use the corresponding private key to sign the artifact name, and discard all copies of the private key
- Save the signature, the certificate (including the public key) and a timestamp in the DB
Timestamp Authority & Transparency Log
Rekor, part of the Sigstore project, is a secure ledger that provides an immutable record of metadata for software artifacts, enabling traceability and verification of software supply chain integrity. Rekor’s transparency log fulfills the signature transparency role of Sigstore’s software signing infrastructure. With this log, signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used, and someone who downloads an artifact can confirm that the certificate was valid at the time of signing.
Endor Labs provides this capability on a per tenant basis using its database. All signature operations create immutable entries in the database with the certificate, signature and any provenance metadata associated with the sign operation.
Artifact Signing
An artifact can be signed using the Endor Labs CLI (endorctl) or GitHub action. The artifact’s name and the tenant’s namespace are required parameters for the command:
endorctl artifact sign --namespace=example-ns
--name=registry/image@sha256:cec83ad230502a3cc1bec3edd228669625ca652b9b34ed7aece69711f86454be
When using the Endor Labs GitHub action to initiate the sign operation, the GitHub OIDC token includes provenance information in the form of claims that are extracted and maintained in the database as part of this signature event. Two of this set of claims have a more prominent role, one for the verification command (certificate-oidc-issuer) and the other for the revoke-signature event (source-repository-ref). When using the CLI, these two options are required.
The diagram below shows the full sequence of events for the sign operation.
Artifact Verification
The signature of an artifact can be verified using the Endor Labs CLI (endorctl), our GitHub action or directly using our API as part of an admissions controller. The artifact’s name, the tenant’s namespace, and the OIDC issuer of the certificate are required parameters for the command:
endorctl artifact verify --namespace=example-ns –certificate-oidc-issuer https://token.actions.githubusercontent.com
--name=registry/image@sha256:cec83ad230502a3cc1bec3edd228669625ca652b9b34ed7aece69711f86454be
If successful, the following information is printed:
The artifact's signature has been verified successfully. This means that:
1. The certificate was issued by a CA that we trust.
2. The timestamp in the signature entry is within the certificate's validity.
3. The signature has been verified using the certificate's public key.
4. Any CLI provenance information or token claims match the ones in the certificate.
Signature information:
---------------------------------------------------------
Signature: MEYCIQDLcUqH8T2q/aDE0dDC2qpEaw2PO1uuuPGomeLxfmpVDAIhAMGT3RfTKkdwfsINhaMbHmMtZxX2WYrB1caksa3BzEwZ
Timestamp: 2024-03-22 11:25:48.983761494 +0000 UTC
Provenance Information:
-----------------------
Build config digest: 049e91b177bf1e1bce48e367967059c75b41bb13
Build config name: Release
Certificate identity: repo:endorlabs/monorepo:ref:refs/tags/v1.6.217
Certificate OIDC issuer: https://token.actions.githubusercontent.com
Runner environment: self-hosted
Source repository: endorlabs/monorepo
Source repository digest: 049e91b177bf1e1bce48e367967059c75b41bb13
Source repository owner: endorlabs
Source repository ref: refs/tags/v1.6.217
The first section of the response provides the basic verification steps that take place. Given the artifact name that is being verified, Endor Labs will look up its database searching for a signature event in the tenant’s namespace (“example-ns”) that match the following criteria:
- The artifact name matches
- The certificate OIDC issuer matches
If no such entry exists then the verification will fail. If an entry is found, an additional set of checks is performed by examining the database entry, namely:
- The version has not been added to the admission blocklist or had its signature revoked.
- The certificate was issued by the trusted Certificate Authority (CA). Currently, the root CA is one issued by one of our microservices acting as the certificate authority so this check will succeed if we find its certificate in the certificate chain as the root CA. Eventually we intend to move to a scheme where an authority other than Endor Labs is used as the root CA and our own CA is used as an intermediary in the certificate chain.
- Given that our CA has issued a short lived certificate (5 minutes) for the signature event, we confirm that the timestamp event for the found entry is within the validity of the certificate.
- Using the public key of the certificate, we verify that the signature can be verified.
- Any additional provenance metadata that the user requests that is checked against the stored signature match.
The diagram below shows the full sequence of events for the verify operation.
Artifact Signature Revocation
An artifact signature can be revoked using the Endor Labs CLI (endorctl) or UI. The artifact’s name, the tenant’s namespace, and the source repository ref (e.g, release tag) are required parameters for the command:
endorctl artifact revoke-signature --namespace=example-ns –source-repository-ref refs/tags/v1.6.217
--name=registry/image@sha256:cec83ad230502a3cc1bec3edd228669625ca652b9b34ed7aece69711f86454be
If a match is found in the database, Endor Labs will not delete it but mark it as “revoked”. When an attempt to verify this artifact is made afterwards, Endor Labs will fail it.
GitHub Action Integration
Here is an example of using our GitHub action to sign an artifact.
name: Release Workflow
on:
workflow_dispatch:
jobs:
release:
name: Build and Sign
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Create container
run: docker build -t org/sign-demo:latest .
- name: Get Image Digest to Sign
run: |
IMAGE_SHA=$(docker inspect org/sign-demo:latest | jq -r '.[].Id')
SIGNING_TARGET=org/sign-demo@"$IMAGE_SHA"
echo ARTIFACT="$SIGNING_TARGET" >> $GITHUB_ENV
- name: Container Sign
uses: endorlabs/github-action/sign@736c93ea52b002f2ac229aaeb273b102cbf6fe12
with:
namespace: "example"
artifact_name: ${{ env.ARTIFACT }}
Build a CI/CD Security Program with Endor Labs
In addition to Artifact Signing, Endor Labs CI/CD includes:
- CI/CD Discovery: Get visibility into tools used in pipelines across your org, understand security coverage, and find policy violations.
- Repository Security Posture Management: Detect repo misconfigurations, best practices, and risks with over 50 out-of-the-box policies.
Endor Labs CI/CD is available in our free trial, where you can explore the Endor Labs Software Supply Chain Security platform on a pre-populated demo environment and with your own projects.