Releases: chainloop-dev/chainloop
v0.60.0
Highlights
Remote Attestation State
Chainloop now supports a stateless attestation process #494.
This feature is disabled by default, to enable it you need to pass the --remote-state
flag
$ chainloop att init --remote-state
┌───────────────────┬──────────────────────────────────────┐
│ Initialized At │ 12 Feb 24 15:50 UTC │
├───────────────────┼──────────────────────────────────────┤
│ Attestation ID │ c8bac112-508c-4ab8-8ff2-9b7f22714628 │
│ Name │ test │
│ Team │ │
This state of the attestation is being stored now in Chainloop!
Subsequently, to continue with the attestation process, the attestation ID, returned by the init
process needs to be provided as well.
For example, to add materials, now:
$ chainloop att add --name artifact --value ./test.jar --remote-state --attestation-id c8bac112-508c-4ab8-8ff2-9b7f22714628
INF material added to attestation
The same applies to the reset
or push
methods.
What's Changed
- Bump Helm Chart Version => v0.56.0 by @github-actions in #482
- chore(deps): Bump CHAINLOOP_VERSION to use latest Chainloop CLI by @danlishka in #486
- chore(deps): Bump the anchore/sbom-action version by @danlishka in #485
- feat: release CLI as container image by @migmartri in #487
- chore(deps): Bump github.com/opencontainers/runc from 1.1.9 to 1.1.12 by @dependabot in #489
- chore(deps): Bump github.com/moby/moby from 24.0.5+incompatible to 24.0.9+incompatible by @dependabot in #490
- fix(authZ): propagate new policies across replicas by @migmartri in #484
- refactor(cli): modularize current state management code by @migmartri in #493
- chore(cli): make attestation cmds context aware by @migmartri in #497
- chore(api): move attestation API to common package by @migmartri in #496
- feat(api): remote attestation state API by @migmartri in #495
- feat(cli): remote attestation state support by @migmartri in #499
Full Changelog: v0.56.0...v0.60.0
v0.56.0
Chainloop Attestation Report here 🚀 🥳
Highlights
Authorization backend
This release sets the foundation of an authorization layer and enables it to our APITokens authentication method #474
This means that now unattended APITokens meant to be used by automation have a more granular, and restrictive, access level.
In the following demo you can see how the underlying policies are attached/removed during API-token creation/revocation.
Below, you'll see how only the allowed routes go through, and the rest get intercepted by the new backend.
CycloneDX 1.5 support
Chainloop now supports the latest version of the CycloneDX SBOM format as material type during attestations.
What's Changed
- Bump Helm Chart Version => v0.55.0 by @github-actions in #469
- chore(deps): Bump golang.org/x/crypto from 0.14.0 to 0.17.0 by @dependabot in #472
- chore(deps): Bump github.com/containerd/containerd from 1.7.5 to 1.7.11 by @dependabot in #473
- chore(deps): Bump github.com/go-git/go-git/v5 from 5.9.0 to 5.11.0 by @dependabot in #475
- chore: happy new year by @migmartri in #476
- fix: allow downloading artifacts with http clients by @migmartri in #471
- chore(deps): Bump github.com/cloudflare/circl from 1.3.5 to 1.3.7 by @dependabot in #477
- feat: add support for CycloneDX 1.5 by @migmartri in #480
- feat: authorization backend for API tokens by @migmartri in #474
- fix(docs): devel README instructions by @fgallina in #481
Full Changelog: v0.55.0...v0.56.0
v0.55.0
Like clockwork, we are dropping a new release 🎁 for you right in time for Christmas!
Highlights
API-tokens support
Operators can now create long-lasting, but revocable, API tokens #453 associated with their organizations that can be used in their unattended automation.
Its management is under the chainloop organization api-token
CLI namespace and includes creation, listing, and revocation.
$ chainloop organization api-token
Manage API tokens to authenticate with the Chainloop API.
Available Commands:
create Create an API token
list List API tokens in this organization
revoke revoke API token
Once you have a token, you can use it in the CLI by providing it via the --token flag
or the $CHAINLOOP_API_TOKEN. For HTTP requests such as /download/[sha256]
, this token can also be set in the Authorization Bearer
header.
We are very excited about this feature because it enables best practices, such as GitOps approach for updating workflow contracts 💪🏼 🎉
Improved discovery endpoint
The discovery index now includes, at first glance, information about the attestations, saving you from the need to download and process them. See with your own eyes in this example discover/sha256:64d99214c867476c96dc00a6cac70a2ec9726a6736bca407cd8fb92792aa1925.
What's Changed
- Bump Helm Chart Version => v0.50.0 by @github-actions in #454
- feat(org): prevent from leaving current organization by @buccarel in #457
- fix: enable JWT audience verification by @migmartri in #459
- Api tokens reference persistence by @migmartri in #455
- fix(referrer): remove sha256 requirement by @migmartri in #460
- API tokens API support by @migmartri in #461
- chore: simplify membership check by @migmartri in #465
- feat: allow upload/downloads using API token by @migmartri in #464
- feat: add attestation info to index by @migmartri in #467
- fix(controlplane): bump revision only during workflow contract update by @fgallina in #468
New Contributors
Full Changelog: v0.50.0...v0.55.0
v0.50.0
Highlights
Multi-tenancy API
This new release exposes new APIs and CLI commands to handle multi-tenancy. Now you can Create
, Edit
, and Leave
organizations. This feature expands on the previously released invitation system.
Declarative API foundation
We are setting the foundation for declarative APIs starting with organizations. Their name now needs to follow RFC 1123, same format used by kubernetes namespaces
In the next release we'll add uniqueness constraints to ultimately make these names primary identifiers.
Optional Attestation Runner properties
@buccarel has made an overhaul of how the attestation CLI handles runner-type discovery. Now it's possible to define environment variables to gather that are not only required (like before) but also optional.
What's Changed
- Bump Helm Chart Version => v0.40.0 by @github-actions in #445
- fix(referrer): remove sha256 digest validation by @migmartri in #447
- chore(deps): Bump github.com/go-jose/go-jose/v3 from 3.0.0 to 3.0.1 by @dependabot in #446
- feat(controlplane): update org name by @migmartri in #449
- feat(runner): allow for optional environment variables by @buccarel in #443
- feat(controlplane): create organization by @migmartri in #450
- fix(cli attestation): handle non-merged branches by @migmartri in #451
- feat(controlplane): leave organization by @migmartri in #452
Full Changelog: v0.40.0...v0.50.0
v0.40.0
Public discovery endpoint
This release exposes a discovery API endpoint that returns the referrers from public workflows of allowed organizations #441. This feature enables a shared (cross-organization) public index between materials, attestations, and CI context.
For example, let's say we want to know everything about a container image with digest sha256:679d7f74941e1b121c49f85b2efbe7a147db90d60352e02b1d20da0a8b44c924
, by going to this URL you can see all the attestations that have referenced this image.
This result is also available through the CLI in the discover cmd with the --public
flag.
chainloop discover --public -d sha256:679d7f74941e1b121c49f85b2efbe7a147db90d60352e02b1d20da0a8b44c924
{
"digest": "sha256:679d7f74941e1b121c49f85b2efbe7a147db90d60352e02b1d20da0a8b44c924",
"kind": "CONTAINER_IMAGE",
"downloadable": false,
"public": true,
"createdAt": "2023-11-09T13:33:50.3421Z",
"references": [
{
"digest": "sha256:0017be43cbf1e4a8db5e635130b08ad2f08681cec164ef18e119d72c8591f224",
"kind": "ATTESTATION",
"downloadable": true,
"public": true,
"createdAt": "2023-11-27T16:08:51.184944Z",
"references": []
},
{
"digest": "sha256:00409892e7295d2c6ad6ae85d8a0f4ec68024985175d7b77c4c912c22bc09d09",
"kind": "ATTESTATION",
"downloadable": true,
"public": true,
"createdAt": "2023-11-17T12:30:07.963532Z",
"references": []
},
{
...
What's Changed
- Bump Helm Chart Version => v0.30.0 by @github-actions in #426
- fix(cli): handle empty files by @jiparis in #430
- feat(referrer): support same digest for two different kinds by @migmartri in #431
- chore(deps): Bump github.com/sigstore/cosign/v2 from 2.1.1 to 2.2.1 by @dependabot in #429
- feat(referrer):
kind
parameter support by @migmartri in #434 - feat(runner): Integrate runner for CircleCI builds by @buccarel in #437
- feat: workflow update by @migmartri in #436
- fix(runner): remove optional env variable from the requirements by @buccarel in #439
- feat(referrers): add public property by @migmartri in #438
- feat(referrers): shared index API by @migmartri in #441
- deploy(referrers): add public index configuration by @migmartri in #444
Full Changelog: v0.30.0...v0.40.0
v0.30.0
This release sets the stage for exciting new features coming to Chainloop.
Jenkins Support
@buccarel has added support to Jenkins in this new release 🙌🏼 🚀
Referrer API
You can now query Chainloop for relationship between pieces of evidence, artifacts, and associated attestations via a discover
API #415
Conceptually, this is similar to what the OCI referrer API does but across all cas-backends and Chainloop organizations. In any case, we plan on propagating this index to OCI natively.
For example, let's say that you know a container image hashicorp/vault-k8s@sha256:4500e988b7ce9f10d25930ac2ea7e29fda6a0fe239e22be653a3ea0549a84a55
. You can inspect in what attestations this container image appears.
$ chainloop discover -d sha256:4500e988b7ce9f10d25930ac2ea7e29fda6a0fe239e22be653a3ea0549a84a55
{
"digest": "sha256:4500e988b7ce9f10d25930ac2ea7e29fda6a0fe239e22be653a3ea0549a84a55",
"kind": "CONTAINER_IMAGE",
"downloadable": false,
"createdAt": "2023-11-09T13:33:08.059074Z",
"references": [
{
"digest": "sha256:157cb0891dd6fa4df340471ba1e834b114bf845328cb2f6bfb0aa9acc6ec6f88",
"kind": "ATTESTATION",
"downloadable": true,
"createdAt": "2023-11-09T13:33:08.057887Z",
"references": []
}
]
}
As you can see, there is a reference to an attestation. Let's keep pulling the thread 🪄
$ chainloop discover -d sha256:157cb0891dd6fa4df340471ba1e834b114bf845328cb2f6bfb0aa9acc6ec6f88
{
"digest": "sha256:157cb0891dd6fa4df340471ba1e834b114bf845328cb2f6bfb0aa9acc6ec6f88",
"kind": "ATTESTATION",
"downloadable": true,
"createdAt": "2023-11-09T13:33:08.057887Z",
"references": [
{
"digest": "sha1:b7d4b3a6fabdd2e6f19b834870bbc728d92f413f",
"kind": "GIT_HEAD_COMMIT",
"downloadable": false,
"createdAt": "2023-11-09T13:32:18.923814Z",
"references": []
},
{
"digest": "sha256:08b98b03efba73e3d0affea9b0b321641ae7faaada72ab21fbbece5c4a9682fc",
"kind": "ARTIFACT",
"downloadable": true,
"createdAt": "2023-11-09T13:33:08.052813Z",
"references": []
},
{
"digest": "sha256:285d7fb8aace379c460745a11baafdfa4f39a6234c69bcbf944caab5a442906e",
"kind": "ARTIFACT",
"downloadable": true,
"createdAt": "2023-11-09T13:33:08.054857Z",
"references": []
},
{
"digest": "sha256:4500e988b7ce9f10d25930ac2ea7e29fda6a0fe239e22be653a3ea0549a84a55",
"kind": "CONTAINER_IMAGE",
"downloadable": false,
"createdAt": "2023-11-09T13:33:08.059074Z",
"references": []
},
{
"digest": "sha256:cb98bdbb49e9e22d36b5baa17dde7a18956485771c8587fa59413f3d14210ed2",
"kind": "SBOM_SPDX_JSON",
"downloadable": true,
"createdAt": "2023-11-09T13:33:08.056048Z",
"references": []
},
{
"digest": "sha256:d20d817bbfab6a2091e4bdd31f0466fb18af4a84be1bf43427c1c8ca8a65cd31",
"kind": "SBOM_CYCLONEDX_JSON",
"downloadable": true,
"createdAt": "2023-11-09T13:33:08.060168Z",
"references": []
}
]
}
You can now see all the pieces of evidence associated with this attestation along with their content digest. These can be downloaded, too!
chainloop artifact download -d sha256:d20d817bbfab6a2091e4bdd31f0466fb18af4a84be1bf43427c1c8ca8a65cd31
INF downloading file name=cyclonedx.json to=/home/migmartri/work/chainloop/cloud/cyclonedx.json
100.00% [#################.] [202.64KB in 345.663ms; 586.23KB/s] ...
... done! [202.64KB in 580ms; 349.17KB/s]
Get attestations via digest
Remember that attestation that was shown above in the discovery index? Now, you can quickly get it with the CLI by providing its digest!
$ chainloop workflow run describe --digest sha256:157cb0891dd6fa4df340471ba1e834b114bf845328cb2f6bfb0aa9acc6ec6f88 -o statement
{
"type": "https://in-toto.io/Statement/v1",
"subject": [
{
"name": "chainloop.workflow.process_vac_containers",
"digest": {
"sha256": "117151a471d07764193ead79f38a97cf74b3815cefc8955a2a3fcbb1a4afbe06"
}
},
{
"name": "git.head",
"digest": {
"sha1": "b7d4b3a6fabdd2e6f19b834870bbc728d92f413f"
},
"annotations": {
"date": "2023-11-09T13:30:54Z",
"message": "temporary fix for enriched cycclonedx\n\nSigned-off-by: Daniel Liszka \u003cdaniel@chainloop.dev\u003e\n",
...
What's Changed
- Bump Helm Chart Version => v0.25.0 by @github-actions in #407
- Reduce the size by stripping debug symbols by @danlishka in #410
- chore(ci): bump chainloop CLI to v0.25.0 by @migmartri in #409
- fix(ci): detect generated API missing by @migmartri in #412
- fix(controlplane): bubble up authorization permission by @migmartri in #408
- feat(runner): Integrate runner for Jenkins jobs by @buccarel in #411
- chore: clear some unintended trailing spaces by @buccarel in #413
- chore: display jenkins job type in runner column by @buccarel in #421
- fix(api): remove empty properties description by @javirln in #422
- fix(DB): cleanup items on organization deletion by @migmartri in #423
- feat(referrers): persistence layer by @migmartri in #416
- feat(referrers): API endpoint by @migmartri in #424
- feat(cli): retrieve worklowRun by attestation digest by @migmartri in #425
New Contributors
Full Changelog: v0.25.0...v0.30.0
v0.25.0
Marching Step by Step towards v1.0
with a new release and the help of new contributors! 🚀
Automatic Git Repository Attestor
Attestations will automatically include information about the Git repository Head Commit, if available. This includes not only the commit sha but also the author and remote information. This information is in the form of resourceDescriptor annotations, which was possible after refactoring #397 (thanks, @marcelamelara, for your help!)
Multi-tenancy organization invitation
Chainloop data model root is namespaced (soft multi-tenancy) by an organization entity. Users are connected to different organizations through memberships. The management of these memberships was not exposed through an API, that changes with this release.
Now, you can invite other users (registered or not) to your organization.
For example, let's say that you have an organization like this.
$ chainloop org ls
┌──────────────────────────────────────┬──────────────────┬─────────┬─────────────────────┐
│ ORG ID │ ORG NAME │ CURRENT │ JOINED AT │
├──────────────────────────────────────┼──────────────────┼─────────┼─────────────────────┤
│ 161bd37d-6d20-444f-8847-1c6db81b2d78 │ nervous_dijkstra │ true │ 24 Mar 23 11:13 UTC │
└──────────────────────────────────────┴──────────────────┴─────────┴─────────────────────┘
You can now invite any user by performing.
$ chainloop org invite create --organization 161bd37d-6d20-444f-8847-1c6db81b2d78 --receiver another-user@chainloop.dev
┌──────────────────────────────────────┬──────────────────┬────────────────────────────┬─────────┬─────────────────────┐
│ ID │ ORG NAME │ RECEIVER EMAIL │ STATUS │ CREATED AT │
├──────────────────────────────────────┼──────────────────┼────────────────────────────┼─────────┼─────────────────────┤
│ a03d1012-2201-4335-9cc9-1920985e4d6b │ nervous_dijkstra │ another-user@chainloop.dev │ pending │ 31 Oct 23 15:12 UTC │
└──────────────────────────────────────┴──────────────────┴────────────────────────────┴─────────┴─────────────────────┘
If you prefer, you can also revoke the invite at any time via chainloop org invite revoke --id ...
Then, when a user with the email address another-user@chainloop.dev
logs in to Chainloop, they will see the new organization available that they can choose from.
$ chainloop org ls
┌──────────────────────────────────────┬──────────────────────┬─────────┬─────────────────────┐
│ ORG ID │ ORG NAME │ CURRENT │ JOINED AT │
├──────────────────────────────────────┼──────────────────────┼─────────┼─────────────────────┤
│ deadbeef-853c-4ad6-9d60-8f562b123fd2 │ integrations testing │ false │ 10 Jul 23 09:23 UTC │
├──────────────────────────────────────┼──────────────────────┼─────────┼─────────────────────┤
│ deadbeef-6d20-444f-8847-1c6db81b2d78 │ nervous_dijkstra │ false │ 31 Oct 23 14:37 UTC │
├──────────────────────────────────────┼──────────────────────┼─────────┼─────────────────────┤
What's Changed
- Bump Helm Chart Version => v0.21.1 by @github-actions in #393
- chore(docs): update Helm Chart readme with Azure KeyVault info by @migmartri in #394
- chore(deployment): upgrade development deps by @migmartri in #395
- chore(api): enable request time histogram by @migmartri in #396
- refactor: migrate to intoto/attestations go library -> in-toto 1.0 bump by @migmartri in #397
- fix(secretmanager): fix error handling in ReadCredentials by @buccarel in #399
- chore(deps): Bump google.golang.org/grpc from 1.57.0 to 1.57.1 by @dependabot in #400
- feat(attestation): add annotations to subject materials by @migmartri in #398
- feat(attestation): add git repository annotations by @migmartri in #402
- chore(deps): Bump github.com/docker/docker from 24.0.5+incompatible to 24.0.7+incompatible by @dependabot in #405
- feat(controlplane): organization invite system by @migmartri in #404
New Contributors
Full Changelog: v0.21.1...v0.25.0
v0.21.1
After a previous tick release focused on performance, it's time for a new release, but this time packing some big features! 🚀
AWS S3 CAS backend support
We welcome Amazon S3 blob storage as a new addition to the CAS backend family, joining OCI registry and Azure Blob Storage. Now, you can configure an S3 bucket as a destination for all your SDLC pieces of evidence (SBOMS, artifacts, test results, VEX files) and attestations.
You can learn how to configure it in our documentation, but in a nutshell...
$ chainloop cas-backend add aws-s3 \
--access-key-id [accessKeyID] \
--secret-access-key [secretAccessKey] \
--region [region] \
--bucket [bucketName]
The result is having all the artifacts stored in your s3 bucket following a content addressable convention.
With tamper-resistant properties and additional information for easy retrieval.
Azure KeyVault credentials backend
This release also adds support for Azure KeyVault. This means that when you deploy Chainloop in Azure, you can now fully leverage Azure-managed services by not only using CloudSQL (for DB) and Azure Blob Storage (for content addressable storage (CAS)) but also Azure KeyVault for credentials handling.
This makes this deployment topology on par with what we already have in Google Cloud (via GCP secret manager) and Amazon Web Services (with AWS secret manager). Congratulations, Azure users! 🎉
You can find the full release attestation here
What's Changed
- Bump Helm Chart Version => v0.20.0 by @github-actions in #384
- fix: Azure Pipeline Run URI incorrect value by @danlishka in #386
- chore(deps): Bump golang.org/x/net from 0.15.0 to 0.17.0 by @dependabot in #387
- feat: Azure KeyVault support by @migmartri in #388
- feat(deployment): Azure KeyVault support by @migmartri in #389
- feat(CAS): AWS S3 blob storage support by @migmartri in #390
- Bump Helm Chart Version => v0.21.0 by @github-actions in #391
- fix(azure): existing file regression by @migmartri in #392
Full Changelog: v0.20.0...v0.21.1
v0.20.0
CAS performance improvements
This release improves the stability and performance of our CAS proxy. It improves the handle of high latency scenarios and unreliable networks #375 (comment)
Automatic git information gathering
The attestation CLI will not automatically discover if the attestation process is happening inside a git repo, if so, it will record the head commit digest.
{
"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": "chainloop.dev/attestation/v0.2",
"subject": [
{
"name": "chainloop.workflow.empty",
"digest": {
"sha256": "eec3f9e5bd477a5d95c4aea898d8ce05339e658a9634e090514746e9a2e8ca84"
}
},
{
"name": "git.head",
"digest": {
"sha1": "83d34125f5f6abe66c450fc1ed37ec630a7d4101"
}
}
],
"predicate": {
"metadata": {
"name": "empty",
"project": "empty",
...
Changelog
v0.19.1
Like Swiss clockwork, we are on time for another feature-packed Chainloop release, among the highlights we got...
SARIF, OpenVEX and CSAF VEX support
Chainloop has now first class support for SARIF, OpenVEX and CSAF VEX file formats as pieces of evidence. This means that now these files a) are validated once provided, b) they get uploaded to CAS and injected in the attestation and c) can leverage third-party integrations :)
To add these pieces of evidence as a requirement in your attestation, just update your contract with something like:
schemaVersion: v1
materials:
# CSAF_VEX and OPENVEX are supported
- type: OPENVEX
name: disclosure
# And static analysis reports in SARIF format
- type: SARIF
name: static-out
You can see a full contract example and learn more about these and other material types here
Azure Blob Storage support as Content Addressable Storage (CAS) #357
In addition to OCI-based CAS backends, you can now also configure an Azure Blob Storage Account as a destination for all your SDLC pieces of evidence (SBOMS, artifacts, test results, VEX files) an attestations.
Below you can see a screenshot of how these artifacts will look in Azure. The nice part is that Chainloop will take care of figuring out the nifty details specific to Azure (metadata, naming, tampering checks) so for you, as an user, nothing has changed, you can reference the asset through the sha256 checksum as usual. Ahh, and this work across multiple backends :)
This new feature is now available in the Chainloop CLI
$ chainloop cas-backend ls
┌──────────────────────────────────────┬─────────────────────────────────────┬───────────┬─────────────────────────────────────┬───────────────┬─────────┐
│ ID │ LOCATION │ PROVIDER │ DESCRIPTION │ LIMITS │ DEFAULT │
├──────────────────────────────────────┼─────────────────────────────────────┼───────────┼─────────────────────────────────────┼───────────────┼─────────┤
│ 2fc43734-a8e8-4d17-a790-3365e4da8af4 │ chainloop/chainloop │ AzureBlob │ │ MaxSize: 100M │ true │
├──────────────────────────────────────┼─────────────────────────────────────┼───────────┼─────────────────────────────────────┼───────────────┼─────────┤
...
To learn more on how to set up your Azure Storage Account, ptal at our docs
What's Changed
- Bump Helm Chart Version => v0.18.0 by @github-actions in #345
- fix: least privilege support in automated workflows by @migmartri in #347
- [StepSecurity] Apply security best practices by @step-security-bot in #346
- feat: Split Sentry configuration for individual services by @cristiangauma in #355
- chore: upgrade golang to 1.21 by @jiparis in #349
- Create SECURITY.md by @migmartri in #348
- fix: add pinned dependencies by @migmartri in #354
- feat: CSAF VEX / OpenVEX material type support by @migmartri in #356
- chore: add OpenSSF scorecard by @migmartri in #358
- refactor(CAS proxy): multiple CAS backend providers support by @migmartri in #359
- feat: add SARIF format support by @migmartri in #362
- feat(cas): Azure Blob Storage support by @migmartri in #360
- Bump Helm Chart Version => v0.19.0 by @github-actions in #363
- fix(deployment): wrong labeling templating by @migmartri in #364
- fix(attestation): generic normalization function by @migmartri in #367
- fix: extend http download timeout by @migmartri in #369
New Contributors
- @cristiangauma made their first contribution in #355
- @jiparis made their first contribution in #349
Full Changelog: v0.18.0...v0.19.1