ctfe public key default name breaks cosign
Opened this issue · 7 comments
Description
I am not sure if this is a bug or a documentation problem. I'm leaving this here as I imagine that anyone deploying these days probably has the same issue.
I deployed scaffold 0.6.36
, including tuf
and got stuck with the following error with cosign v2.2.0
when performing signing
**Warning** Missing fallback target ctfe.pub, skipping
Error: getting ctlog public keys: no matching targets by custom metadata, fallbacks not found: ctfe.pub
main.go:74: error during command execution: getting ctlog public keys: no matching targets by custom metadata, fallbacks not found: ctfe.pub
Error: Process completed with exit code 1.
I also noticed that I don't have ctfe.pub
in my root targets... I have ctlog_pubkey
.
cosign initialize --root redacted/root.json --mirror redacted
Root status:
{
"local": "redacted.../.sigstore/root",
"remote": "redacted",
"metadata": {
"root.json": {
"version": 1,
"len": redacted,
"expiration": "redacted",
"error": ""
},
"snapshot.json": {
"version": 1,
"len": redacted,
"expiration": "redacted",
"error": ""
},
"targets.json": {
"version": 1,
"len": redacted,
"expiration": "redacted",
"error": ""
},
"timestamp.json": {
"version": 1,
"len": redacted,
"expiration": "redacted",
"error": ""
}
},
"targets": [
"rekor-pubkey",
"ctlog-pubkey",
"fulcio-cert"
]
}
This is different from what I can find in all guides online to deploy sigstore, for instance https://blog.stephane-robert.info/post/devops-cosign-rekor-private/ (it's in french, sorry, scroll down to the cosign -d initialize --root root.json --mirror https://tuf.robert.local
)
Cosign does not seem to allow to override the filename, as it is hardcoded in https://github.com/sigstore/cosign/blob/878b6c766e17d59d5624c802a1e196e8e8d47f56/pkg/cosign/ctlog.go#L28.
In the end I was able to resolve this through the env variable SIGSTORE_CT_LOG_PUBLIC_KEY_FILE
. But that is annoying because it requires to manually inspect the kubernetes secret to copy the public key...
PS is there a way to fetch that public key like there is for rekor api/v1/log/publicKey
?
I do not understand currently if this is caused by configuration of tuf
, ctlog
, fulcio
or the copysecrets
jobs
Version
- cosign: v2.2.0
- scaffold: 0.6.36
@federico-falconieri-form3 can you share your values file or the items unique to your deployment?
Sure, however I cannot share the fulcio OIDC issuer configuration:
trillian:
enabled: true
namespace:
create: true
mysql:
persistence:
enabled: true
ctlog:
enabled: true
namespace:
create: true
rekor:
enabled: true
namespace:
create: true
server:
ingress:
http:
enabled: false # I create the ingress manually elsewhere
attestation_storage:
enabled: false
fulcio:
enabled: true
namespace:
create: true
server:
args:
certificateAuthority: fileca
ingress:
http:
enabled: false # I create the ingress manually elsewhere
tuf:
enabled: true
namespace:
create: true
ingress:
enabled: false # I create the ingress manually elsewhere
copySecretJob:
enabled: true
tsa:
enabled: false
@federico-falconieri-form3 if you want to add the following, it should solve the issues that you are facing
tuf:
secrets:
fulcio:
path: fulcio_v1.crt.pem
rekor:
path: rekor.pub
ctlog:
path: ctfe.pub
These will be the default values moving forward
Can you share the tuf targets.json
config? It seems you are missing the metadata for ctlog-pubkey
? Looking at Sigstore's metadata, it looks like this:
...
"ctfe.pub": {
"length": 177,
"hashes": {
"sha256": "7fcb94a5d0ed541260473b990b99a6c39864c1fb16f3f3e594a5a3cebbfe138a",
"sha512": "4b20747d1afe2544238ad38cc0cc3010921b177d60ac743767e0ef675b915489bd01a36606c0ff83c06448622d7160f0d866c83d20f0c0f44653dcc3f9aa0bd4"
},
"custom": {
"sigstore": {
"status": "Active",
"uri": "https://ctfe.sigstore.dev/test",
"usage": "CTFE"
}
}
},
...
So the usage
attribute is what is being used to search for the correct public key.
@kommendorkapten One issue is I think this is lagging behind some of the updates to the expected Sigstore TUF metadata, it's not setting custom
. sigstore/helm-charts#673 should fix this because it uses the fallback names, but a long-term fix is to set the custom metadata too.
@haydentherapper ah, got it. I'm not very familiar with the scaffolding project and how the TUF repository is configured.