Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions content/en/cosign/key_management/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,13 +6,13 @@ weight: 500
---

Sigstore handles keys and key management internally by default. However, while the default makes it unnecessary, you can configure Sigstore, through Cosign, to work with KMS providers. This page contains detailed instructions on how to configure `cosign` to work with KMS providers.
Right now `cosign` supports [AWS KMS](https://aws.amazon.com/kms/), [GCP KMS](https://cloud.google.com/security-key-management), [Azure Key Vault](https://azure.microsoft.com/en-gb/products/key-vault), [Hashicorp Vault](https://www.vaultproject.io/) and [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) with the hope to support more in the future!
Right now `cosign` supports [AWS KMS](https://aws.amazon.com/kms/), [GCP KMS](https://cloud.google.com/security-key-management), [Azure Key Vault](https://azure.microsoft.com/en-gb/products/key-vault), [Hashicorp Vault](https://www.vaultproject.io/), [OpenBao](https://openbao.org) and [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) and with the hope to support more in the future!

## Basic Usage

When referring to a key managed by a KMS provider, `cosign` takes a [go-cloud](https://gocloud.dev) style URI to refer to the specific provider.

For example: `awskms://`, `gcpkms://`, `azurekms://`, `hashivault://` and `k8s://`. The URI path syntax is provider specific and explained in the section for each provider.
For example: `awskms://`, `gcpkms://`, `azurekms://`, `hashivault://`, `openbao://` and `k8s://`. The URI path syntax is provider specific and explained in the section for each provider.

### Key Generation and Management

Expand Down Expand Up @@ -145,12 +145,13 @@ To create a key using `cosign generate-key-pair --kms azurekms://[VAULT_NAME][VA

To sign images using `cosign sign --key azurekms://[VAULT_NAME][VAULT_URI]/[KEY] [IMAGE_DIGEST]` you will need a user which has permissions to the sign action such as the `Key Vault Crypto User` role.

### Hashicorp Vault
### Hashicorp Vault and OpenBao

Hashicorp Vault keys can be used in `cosign` for signing and verification.
The URI format for Hashicorp Vault KMS is: `hashivault://$keyname`
Hashicorp Vault and OpenBao keys can be used in `cosign` for signing and verification.
The URI format for Hashicorp Vault KMS is: `hashivault://$keyname`.
For OpenBao KMS `openbao://$keyname` is also supported.

This provider requires that the standard Vault environment variables (`$VAULT_ADDR`, `$VAULT_TOKEN`) are set correctly.
This provider requires that the standard Vault or OpenBao environment variables (`$VAULT_ADDR`, `$VAULT_TOKEN`, `$BAO_ADDR`, `$BAO_TOKEN`) are set correctly.
This provider also requires that the `transit` secret engine is enabled.

The token needs (at least) the following permissions, that will be defined as an ACL policy in the next example. Suppose that the `transit` secret engine is mounted at the path `/transit`, and the `$keyname` is `cosign`, the policy would look like this:
Expand Down
3 changes: 2 additions & 1 deletion content/en/cosign/signing/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -74,7 +74,8 @@ $ cosign sign --identity-token=$(
gcr.io/user-vmtest2/demo
```

On Google Cloud Build, the standard identity tokens endpoint is also available thorugh its metadata server as described [here](https://docs.cloud.google.com/build/docs/securing-builds/authorize-service-to-service-access).
On Google Cloud Build, the standard identity tokens endpoint is also available through its metadata server as described [here](https://docs.cloud.google.com/build/docs/securing-builds/authorize-service-to-service-access).

## Custom infrastructure

If you're running your own Sigstore services flags are available to set your own endpoint's, e.g
Expand Down
6 changes: 6 additions & 0 deletions content/en/cosign/signing/signing_with_containers.md
Original file line number Diff line number Diff line change
Expand Up @@ -118,6 +118,12 @@ $ cosign sign --key gcpkms://projects/[PROJECT]/locations/global/keyRings/[KEYRI
$ cosign sign --key hashivault://[KEY] $IMAGE
```

### Key stored in OpenBao

```shell
$ cosign sign --key openbao://[KEY] $IMAGE
```

### Key stored in a Kubernetes secret

```shell
Expand Down
1 change: 1 addition & 0 deletions content/en/policy-controller/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -155,6 +155,7 @@ Each `key` authority can contain these properties:
- `awskms://[ENDPOINT]/{ARN}` where `ARN` can be either key ARN or alias ARN.
- `gcpkms://projects/[PROJECT]/locations/global/keyRings/[KEYRING]/cryptoKeys/[KEY]`
- `hashivault://[KEY]`
- `openbao://[key]`

### Configuring `keyless` authorities

Expand Down
Loading