Verify SLSA Provenance
In this document, we'll explore how to verify SLSA Provenance attestation and enforce policies to guarantee the provenance contents remain unaltered. Unlike the setup for SLSA provenance generation, the verification process can be conducted in both the Build and Deploy stages of your pipeline. Here’s an overview of the procedure:
![Click to view full size image](/assets/images/overview-slsa-ver-b99b8e031b0d55a2c2cff0905e3d540b.png)
Verify SLSA Attestation
In the Harness SCS, the SLSA verification step is responsible for verifying the attested provenance and applying policies. To incorporate this, navigate to either the build or deploy stage of your pipeline and add the "SLSA Verification" step. When adding this to a deploy stage, ensure it's placed within a container step group.
The SLSA Verification step has the following fields:
- Name: Enter a name for the step.
- Registry Type: Choose your registry from the list of supported items.
- DockerHub
- ECR
- GCR
- GAR
- ACR
-
Container Registry: Select the Docker Registry connector that is configured for the DockerHub container registry where the artifact is stored.
-
Image: Enter the name of your image, example
my-docker-org/repo-name
. -
Tag: Enter the tag name of your image, example
latest
.
![Click to view full size image](/assets/images/slsa-ver-dockerhub-b2601aeda5ee35f3d8261c86d808051a.png)
-
Container Registry: Select the Docker Registry connector that is configured for the Elastic container registry where the artifact is stored.
-
Image: Enter the name of your image, example
my-docker-repo/my-artifact
. -
Region: The geographical location of your ECR repository, example
us-east-1
-
Account ID: The unique identifier associated with your AWS account.
-
Tag: Enter the tag name of your image, example
latest
.
![Click to view full size image](/assets/images/slsa-ver-ecr-2e73db00025cc57239b4021b3d28ffd3.png)
-
Container Registry: Select the Docker Registry connector that is configured for the Google container registry where the artifact is stored.
-
Host: Enter your GCR Host name. The Host name is regional-based. For instance, a common Host name is
gcr.io
, which serves as a multi-regional hostname for the United States. -
Project ID: Enter the unique identifier of your Google Cloud Project. The Project-ID is a distinctive string that identifies your project across Google Cloud services. example:
my-gcp-project
-
Image Name: Enter the name of your image, example
my-image
. -
Tag: Enter the tag name of your image, example
latest
.
![Click to view full size image](/assets/images/slsa-ver-gcr-88415fbfd36e122cb6dfa05cf1855b5b.png)
-
Container Registry: Select the Docker Registry connector that is configured for the Google container registry where the artifact is stored.
-
Host: Enter your GAR Host name. The Host name is regional-based. For example,
us-east1-docker.pkg.dev
. -
Project ID: Enter the unique identifier of your Google Cloud Project. The Project-ID is a distinctive string that identifies your project across Google Cloud services. example:
my-gcp-project
-
Image Name: Enter the name of your image, example
repository-name/image
. -
Tag: Enter the tag name of your image, example
latest
.
![Click to view full size image](/assets/images/slsa-ver-gar-320d97dfd23d0c555cc29c43541075d3.png)
-
Container Registry: Select the Docker Registry connector that is configured for the Azure container registry where the artifact is stored.
-
Image: Enter your image details in the format
<registry-login-server>/<repository>
. The<registry-login-server>
is a fully qualified name of your Azure Container Registry. It typically follows the format<registry-name>.azurecr.io
, where<registry-name>
is the name you have given to your container registry instance in Azure. Example input:automate.azurecr.io/acr
-
Subscription Id: Enter the unique identifier that is associated with your Azure subscription.
-
Tag: Enter the tag name of your image, example
latest
.
![Click to view full size image](/assets/images/slsa-ver-acr-e6e6283b9f97f454a350a02f2535a311.png)
- Public Key: Choose the Harness file secret that holds the public key, which will be used to verify the attestation's authenticity. This key should correspond to the private key and password utilized during the attestation's generation.
Enforce Policies on SLSA Provenance
Immediately following the verification of the provenance attestation, you have the option to configure the step to enforce policies on the provenance. This ensures that the contents of the provenance remain unchanged and have not been tampered with.
To enforce policies, navigate to the Advanced tab of the "SLSA Verification" step, expand the "Policy Enforcement" section, and specify the policy sets you wish to enforce.
![Click to view full size image](/assets/images/slsa-ver-policy-enforce-49c017bc039bcf0e9ac51a41175cb5ce.png)
Create SLSA policies
You must create a set of OPA policies that you want Harness SCS to use for SLSA Provenance verification. You can create a dedicated SLSA Provenance verification policy set or use existing policy sets that you've already created. For more information about creating policies in Harness, go to the Harness Policy As Code overview.
OPA policies used for SLSA Provenance verification are different from SBOM policies used for SBOM policy enforcement.
- In your Harness Project, under Project Setup, go to Policies. You can also create policies at the Account and Org scopes.
- Select Policies, and then create policies for the individual rules that you want to enforce. You can select from the policy library or write your own policies.
- Create policy sets to group related policies. You must have at least one policy set.
SLSA policy example
Here's an example of an OPA policy that could be used to verify an SLSA Provenance generated in Harness. If you are verifying provenance from a third-party build system provider, make sure your OPA policies reflect the provenance structure used by that build system provider. Different providers might use different SLSA Provenance structures.
package slsa
# Build repo must be 'https://github.com/abc/abc-sample'. SLSA verification fails if a different repo is detected.
deny[msg]{
input[0].outcome.stepArtifacts.provenanceArtifacts[0].predicate.buildDefinition.externalParameters.codeMetadata.repositoryURL != "https://github.com/abc/abc-sample"
msg := "Repository verification failed in Provenance"
}
# Build branch must be 'main'. SLSA verification fails if a different branch is detected.
deny[msg]{
input[0].outcome.stepArtifacts.provenanceArtifacts[0].predicate.buildDefinition.externalParameters.codeMetadata.branch != "main"
msg := "Branch verification failed in provenance"
}
For more examples, go to Policy samples.
Run the pipeline
When the pipeline runs, the SLSA Verification step does the following:
- Verifies the authenticity of the attestation.
- Verifies the provenance data by applying the specified policy set.
- Records the policy evaluation results in the step's logs.
- Reports the overall pass/fail for SLSA verification on the Supply Chain tab.
For more information about inspecting SLSA verification results, go to view pipeline execution results.
Verify provenance from third-party build systems
You can use Harness SCS to verify provenance generated by third-party build systems.
To do this:
- Get the public key.
- Create SLSA policies that verify the provenance data according to the provenance structure used by in the build system provider.
- Add SLSA Verification step.