Konflux CI, Enterprise Contract, and SLSA
SLSA Requirements
SLSA requirements verified explicitly by Enterprise Contract
Enterprise Contract comes with a set of policy rules designed for use with Konflux. Using EC to verify that a build passes all the checks defined by the policy provides a high level of confidence that the build was built securely and can be trusted.
Many of the policy rules are linked to specific SLSA requirements, for example:
| SLSA reference | EC policy rule | Notes |
|---|---|---|
Konflux uses Tekton so knowing that is enough to consider this requirement satisfied, however this specific rule confirms it explicitly for each build. The rule asserts that the attestation includes details about the pipeline run that created the build, that the specific task run that pushed the image is identifiable, and that information about each steps in that task run are present. |
||
This check aims to confirm the basic requirement from the v0.1 SLSA spec that the build ran on a build service. Once again, any build created by Konflux is expected to meet this requirement, but the rule confirms this by verifying that that a builder is present in the SLSA attestation. The SLSA Builder ID is also key part of the Verifying Artifacts process described in SLSA v1.0. |
||
This rule verifies that the build task was called with a particular parameter specifying the build should be done hermeticly. This rule is specific to Konflux’s task definitions, since EC isn’t able to explicitly confirm that the build was indeed hermetic. But, when combined with the strictest trusted tasks rule, and a trustable source for the task definition, we can use the rule to ensure that only builds performed hermeticly can be released. |
||
The verification process described in the SLSA v1.0 spec includes a check to confirm the builder id matches what is expected. This rule will fail if an unexpected builder id is found in the SLSA attestation. (For Konflux currently the builder id is the default used by Tekton Chains, though this may change in the future.) |
||
Enterprise Contract uses a public key to validate the signature of the image using Cosign. If the image
signature can’t be verified for any reason, a failure will be reported. There are other ways to verify image signatures, e.g. by using There is also experimental support in EC for validating signatures for images signed keylessly using Sigstore Fulcio, though Konflux currently uses long-lived signing keys to sign images and attestations. |
||
As well as verifying the image signature, EC also verifies the signature of the attestation, which is an important part of the artifact verification process. For Konflux the same key is used to sign the attestation and the image itself. As mentioned above, there is experimental support for verifying keylessly signed attestations. |
||
SLSA recommends an artifact verifier checks that the provenance statement’s subject matches the digest of the artifact in question. This is a good sanity check to confirm that the provenance being considered is for the expected image. Because EC uses Cosign under the hood, and Cosign does this check as part of its signature verification, we get this confirmed automatically. The EC rule linked here performs an additional confirmation by comparing the image reference produced by the build task and confirming that also matches the provenance subject. |
||
SLSA suggests that the predicate type in the artifact’s provenance should be |
||
This is a good sanity check related to artifact verification that isn’t specifically mentioned in the SLSA guidelines. In Konflux build pipelines the git clone task provides information about the git repo and the commit sha used. This rule confirms that the url and the commit sha from the git clone task match what appears in the "materials" provenance. |
SLSA requirements not explicitly verified by Enterprise Contract
There are numerous SLSA Build requirements that are met by Konflux CI, but not explicitly verifiable with an Enterprise Contract policy rule. We won’t go into depth in this document, but for example:
| SLSA reference | Konflux response |
|---|---|
Due to its design, its architecture, and operational management, Konflux CI, meets these requirements implicitly. And, as we’ve seen above, the Enterprise Contract can be used to verify the authenticity of the signed provenances. |
|
For example, the Konflux’s Tekton environment prevents different build pipelines from influencing each other, and has secure access polices and management practices for signing secrets and other credentials. |
Notes and caveats
Because EC was designed initially for use with Konflux, and Konflux uses Tekton CI/CD, many of the specific rules mentioned above are currently Tekton specific in that they use details about the Tekton pipeline run, which are currently made available in the SLSA attestation created by Tekton Chains.
This is not a limitation of EC itself, but rather just an attribute of the policies created for Konflux in their current state. In the future we’re aiming to extract the Tekton specific rules from the general SLSA rules to make the rules more generally applicable. We expected that policy rules for build systems not based on Tekton and Tekton Chains could be created easily.
Note also that since EC can conveniently apply any policy defined in OPA/Rego, it is able to be used for a wide range of purposes, e.g. to verify certain tests were run and passed, and to apply any business specific release policies. Browse the rules defined in Policies to see what other rules have been defined for use by Konflux within Red Hat.
Conclusion
Enterprise Contract can be used as a convenient and customizable SLSA artifact verifier. It’s doing that now within Konflux, and we think it’s capable and flexible enough to become a part of other build systems where supply chain security is a priority.
If you have questions, or want to provide feedback, please reach out to the Enterprise Contract team via GitHub.