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
Currently we support a variety of different signers, including Fulcio and Vault PKI, but these all will result in private key material being loaded into memory to sign data locally.
We should be able to support using KMS solutions to do signing for us. Some example KMS solutions we'd like to support:
AWS KMS
GCP KMS
Vault Transit Secret Engine
Some considerations we need to account for:
Our current Signer interface does not take in a context to it's Sign function. With calls happening to remote resources we need to be able to have a context for cancellation purposes.
A new class of errors. This isn't a huge consideration since we already have error handling in our signing code, but there may be some subtleties we have to account for.
Verification. We may not be able to reach the KMS solution during verification, for example we could be in an air gapped environment or not have cloud permissions to reach the KMS. For keys backed by X509 certificates we need to make sure we receive the certificate from the kms solution. For keys that are not, the user will be responsible for embedding the public portion of the key into their policy.
The text was updated successfully, but these errors were encountered:
Also, for reference, cosign has run into some rough edges with key rotations and versioning. While this issue is focused on the Vault Transit Engine implementation, this could be an issue for other KMS solutions as well.
Currently we support a variety of different signers, including Fulcio and Vault PKI, but these all will result in private key material being loaded into memory to sign data locally.
We should be able to support using KMS solutions to do signing for us. Some example KMS solutions we'd like to support:
Some considerations we need to account for:
Our current Signer interface does not take in a context to it's Sign function. With calls happening to remote resources we need to be able to have a context for cancellation purposes.
A new class of errors. This isn't a huge consideration since we already have error handling in our signing code, but there may be some subtleties we have to account for.
Verification. We may not be able to reach the KMS solution during verification, for example we could be in an air gapped environment or not have cloud permissions to reach the KMS. For keys backed by X509 certificates we need to make sure we receive the certificate from the kms solution. For keys that are not, the user will be responsible for embedding the public portion of the key into their policy.
The text was updated successfully, but these errors were encountered: