You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
* Update applications-dashboard.md* Add content on keyless signingAdded section on keyless signing in build step and new topic on how to verify signed artifacts in pipelines* Add refs in oidc topicAdded x-refs to creating keyless signed images and verifying authenticity* Add missing entry to nav yamlContent edits and added entry for verification topic to nav yaml* Update build.mdEdited content for key-based and keyless signing* Update build.mdUpdated content for container image signing section* Content updatesAdded use of CF as OIDC for keyless, and verification command for key-based
Copy file name to clipboardExpand all lines: _docs/integrations/oidc-pipelines.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,6 +28,11 @@ After setup, to use the ID token, on the Codefresh side, we have a dedicated Mar
28
28
29
29
Review the[generic setup for OIDC](#oidc-setup-for-codefresh-pipelines), or follow the instructions in our example for[OIDC with AWS (Amazon Web Services)](#codefresh-oidc-for-aws).
30
30
31
+
#####Creating artifacts signed with Codefresh OIDC and keyless signing
32
+
Once you have set up Codefresh as an OIDC provider, you can sign container images created by Codefresh pipelines with the keyless signing method introduced by sigstore. See[Securing container images with OIDC and keyless signing]({{site.baseurl}}/docs/pipelines/steps/build/#securing-container-images-with-oidc-and-keyless-signing).
33
+
34
+
Any organization can then verify artifacts created and signed by Codefresh pipelines. See[Verifying artifacts signed with Codefresh pipelines]({{site.baseurl}}/docs/security/pipelines-verify-cf-artifacts/).
35
+
31
36
##OIDC ID tokens, standard & custom claims
32
37
33
38
The ID token is a JSON Web Token (JWT) which contains claims on the authentication and authorization of the user or resource.
Copy file name to clipboardExpand all lines: _docs/pipelines/steps/build.md
+147-1Lines changed: 147 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -89,7 +89,8 @@ The default behavior of the `build` step is defined a
89
89
| `working_directory` | The directory in which the build command is executed. It can be an explicit path in the container's file system, or a variable that references another step. <br>The default is {% raw %} `${{main_clone}}` {% endraw %}. Note that the `working_directory` when defined changes only the Docker build context. It is unrelated to the `WORKDIR` in the Dockerile. | Default |
90
90
| `dockerfile` | The path to the `Dockerfile` from which the image is built. The default is `Dockerfile`. | Default |
91
91
| `image_name` | The name of the image that is built. | Required |
92
-
| `region` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. The names of the regions for which to perform cross-region replication. The names of the source region and the destination region name must be defined in separate steps. | Optional |
92
+
| `region` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. <br>The names of the regions for which to perform cross-region replication. The names of the source region and the destination region name must be defined in separate steps. | Optional |
93
+
| `role_arn` | Relevant only for [Amazon ECR]({{site.baseurl}}/docs/integrations/docker-registries/amazon-ec2-container-registry/) integrations using either service accounts or explicit credentials. <br>The Amazon Resource Name (ARN) of the IAM role to be assumed to push the built image to the ECR repository, in the format `arn:aws:iam::<cross-account-id>:role/<role-name>`, where:<br>`<account-id>` is the ID of the AWS account where the ECR repository is hosted. <br>`<role-name>` is the specified role with the required permissions within this account to access and manage the ECR repository. | Required |
93
94
| `tag` | The single tag to assign to the built image. To assign multiple tags, use `tags` (see below). <br>The default tag is the name of the branch or revision that is built. | Default |
94
95
| `tags` | Multiple tags to assign to the built image. {::nomarkdown} <br>To assign a single tag, use <code class="highlighter-rouge">tag</code> (see above). <br> This is an array, and should conform to the following syntax:<br><code class="highlighter-rouge">tags:<br>- tag1<br>- tag2<br>- {% raw %}${{CF_BRANCH_TAG_NORMALIZED}}{% endraw %}<br>- tag4</code><br><br>OR<br><code class="highlighter-rouge">tags: [ 'tag1', 'tag2', '{% raw %}${{CF_BRANCH_TAG_NORMALIZED}}'{% endraw %}, 'tag4' ]</code>{:/} |Optional|
95
96
| `cache_from` | The list of cache sources to use as Docker cache when building the image. Every source in the list is passed to the build command using the `--cache-from` flag. See [Docker documentation](https://docs.docker.com/engine/reference/commandline/buildx_build/#cache-from){:target="\_blank"} for more info. | Optional |
@@ -427,6 +428,151 @@ steps:
427
428
428
429
Use this technique only as a last resort. It is better if the Dockerfile exists as an actual file in source control.
429
430
431
+
432
+
433
+
## Signing container images with Sigstore
434
+
435
+
Signing container images created and distributed by pipelines and verifying their authenticity is essential for maintaining software security.
436
+
Sigstore, a trusted authority for signing container images, offers two methods to secure images:**key-based signing**, the traditional method, and **keyless signing**, a new method using the OpenID Connect (OIDC) protocol.
437
+
438
+
* **Key-based signing**
439
+
Key-based signing relies on private-public key pairs to authenticate and verify container images. It comes with inherent security and maintenance challenges in managing the key pairs.
440
+
441
+
* **Keyless signing**
442
+
Keyless signing is now the _default_ method due to significant advantages:
443
+
* No long-term key management: No need to generate, store, or rotate private keys.
444
+
* Improved security: Reduces the risk of key theft or misuse, by eliminating the need for long-term private keys.
445
+
* Simplified automation: Ideal for CI/CD pipelines, as OIDC tokens are automatically retrieved and used for signing, with no manual intervention.
446
+
447
+
Codefresh supports both both key-based and keyless signing to secure container images generated by pipelines.
448
+
449
+
##### How Codefresh handles container image signing
450
+
Codefresh removes the complexity of setting up and managing both key-based and keyless signing by integrating the necessary components directly into the pipeline's `build` step. This automation enables you to sign container images with minimal configuration, simplifying the entire signing process.
451
+
452
+
See [Keyless signing for container images](#keyless-signing-for-container-images) and [Key-based signing for container images](#key-based-signing-for-container-images).
453
+
454
+
455
+
456
+
457
+
### Keyless signing for container images
458
+
459
+
Keyless signing in Codefresh utilizes the Codefresh OIDC provider during the artifact signing process. This integration simplifies authentication and ensures the integrity of the signing process by embedding claims within the signature. For detailed information on how to integrate Codefresh as an OIDC provider, see [OIDC for pipelines]({{site.baseurl}}/docs/integrations/oidc-pipelines/).
460
+
461
+
462
+
#### Benefits of Codefresh OIDC Provider for keyless signing
463
+
464
+
465
+
* **Secure authentication**
466
+
Codefresh acting as the OIDC provider for keyless signing eliminates the need for long-term private keys. By using the OIDC protocol, Codefresh securely authenticates the pipeline at runtime, ensuring that only authorized pipelines can sign the artifacts.
467
+
468
+
* **Claims identifying pipeline and build**
469
+
The Codefresh OIDC provider generates claims that uniquely identify both the pipeline and the build in the token issued for signing. These claims are automatically embedded in the OIDC token and passed to the signing process, ensuring that each container image's signature is tied to a specific build in a specific pipeline.
470
+
471
+
* **Robust verification process using claims**
472
+
The claims provided by the Codefresh OIDC provider are used in the signature for a robust verification process. When verifying signed container images, external systems can use the embedded claims to confirm the origin and authenticity of the artifact, ensuring that the image was signed by a trusted pipeline and build.
473
+
474
+
475
+
476
+
#### Keyless signing: components and roles
477
+
478
+
The table below outlines the key components involved in keyless signing and their roles.
479
+
480
+
481
+
For detailed information, including keyless-signing architecture, [read our blog](https://codefresh.io/blog/securing-containers-oidc/){:target="\_blank"}.
| **OIDC provider** | The organization creating the container images must act an OIDC provider. <br> Codefresh is an official OIDC provider, setting up an integration with Codefresh provides added benefits for keyless signing. See [Benefits of Codefresh OIDC Provider for keyless signing](#benefits-of-codefresh-oidc-provider-for-keyless-signing). | Customer|
487
+
| **ID token** | An ID token is created for the OIDC provider to authenticate and authorize pipeline actions. <br>Codefresh automatically retrieves the ID token through the `obtain-oidc-id-token` step, with no manual action required. | Codefresh|
488
+
| **ID token verification** | A certificate authority verifies the ID token against the OIDC provider, and issues a short-lived cryptographic certificate based on the ID token. | [Fulcio](https://docs.sigstore.dev/certificate_authority/overview/){:target="\_blank"}|
489
+
| **Image signing** | Codefresh integrates with Cosign to sign the container image. <br>Simply add the `cosign:sign: true` attribute to your pipeline's `build` step. | [Cosign](https://docs.sigstore.dev/signing/quickstart/){:target="\_blank"}|
490
+
| **Authenticity verification** | The certificate (public key) along with the signature/digest is stored in an append-only transparency log. Any external organization can verify the authenticity of the signed container image.<br>For details on image verification, see [Verifying artifacts signed with Codefresh pipelines]({{site.baseurl}}/docs/security/pipelines-verify-cf-artifacts/). | [Rekor](https://docs.sigstore.dev/logging/overview/){:target="\_blank"}|
491
+
492
+
#### Adding keyless signing to your pipeline
493
+
494
+
To enable keyless signing, add the following attribute to your pipeline's `build` step:
495
+
496
+
497
+
```yaml
498
+
cosign:
499
+
sign: true
500
+
```
501
+
Codefresh retrieves the OIDC token, invokes Cosign, and securely signs the container image without the need for additional setup.
502
+
503
+
Here's an example of a `build` step with this attribute:
All images built successfully with the build step are automatically pushed to the default Docker registry defined for your account. This behavior is completely automatic and happens without any extra configuration on your part. To disable this, add the `disable_push` property set to `true` to your build step. Remember that if you are using `buildx`, you cannot set the `disable_push` property to `true`.
Copy file name to clipboardExpand all lines: _docs/security/codefresh-signed-artifacts.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,7 @@ Verify the authenticity of forked Argo Project images for Codefresh GitOps Runti
47
47
```
48
48
49
49
##Authenticity of third-party images in Codefresh
50
-
To verify the authenticity of third-party images such as NGINX, Bitnami charts for Redis, MongoDB, and Sealed Secrets that Codefresh uses, refer to the official documentation of each component.
50
+
To verify the authenticity of third-party imagesthat Codefresh usessuch as NGINX, Bitnami charts for Redis, MongoDB, and Sealed Secrets, refer to the official documentation of each component.
title:"Verifying authenticity of Codefresh pipeline-created artifacts"
3
+
description:"Verify integrity of container images generated by Codefresh pipelines"
4
+
group:security
5
+
toc:true
6
+
---
7
+
8
+
9
+
Organizations deploying container images created by Codefresh pipelines using Codefresh as the OIDC provider for keyless or key-based signing can verify both the signature and the identity of the signer.
10
+
11
+
For more information, see[Signing container images with Sigstore]({{site.baseurl}}/docs/pipelines/steps/build/#signing-container-images-with-sigstore).
12
+
13
+
For detailed information on keyless signing, including its architecture,[read our blog](https://codefresh.io/blog/securing-containers-oidc/){:target="\_blank"} on the same.
14
+
15
+
16
+
##Verify authenticity of container images with keyless signing
17
+
18
+
Verify the authenticity of all container images created by Codefresh pipelines using the`cosign` command:
On successful verification,`cosign` displays details about the signature, such as the digest and the base64-encoded content of the signing certificate, as in the example below.