Support GCP KMS for checkpoint signer

[roger2hk]

#6

This pull request adds the GCP KMS signer for signing checkpoints and SCTs. The terraform configs are included. Note that it is impossible to immediately remove the keyring and corresponding keys once they're created.

This implementation uses remote signing on GCP KMS. The KMS signing QPS is high enough (60,000) that it is very hard to hit the limit. There is some cost incurred for each signing operation.

[phbnf]

This signer will also be used to sign SCTs. CT issuing rate right now is about 100 certs/s. I read that the cost of remote signing is 0.03 per 10,000 operations. That means that over a year, signing SCTs would cost 100*60*60*24*365*0.03/10000 ~=10k USD. I think it's a bit high, so we need a different strategy for CT. Is there another PR coming after this one and building on it to lower costs?

(without SCT signing, and an integration i.e a checkpoint every second, that's ~100USD a year, which looks okay to me. To put things into perspective, that's ~16% of the smallest GCP spanner footprint one can buy)

[roger2hk]

On top of KMS, I plan to implement the Secret Manager. This enables the CT server to fetch the key during initialization, so the signing operations can rely on the signing key in memory.

[phbnf]

Given that the Alpha goal is to use this for CT, let's prioritise the Secret Manager implementation first? I also wouldn't want load tests (and later, integration pipelines) to use KMS because that would incur further costs, (and potentially latency).

My vision for gcp/main.go is for it to be the main file that a CT log operator would use on GCP.

I understand after speaking with you that there might be some other use cases (like Sigstore) that might want to use KMS for signing operations, but we can probably delay this for after Alpha? Given that you've already written the code for KMS, maybe we could park it in a different branch and/or submit the code later, but not use it in gcp/main.go and the load test commands? When Sigstore experiments with CT, they can have their own main.go file that imports this library, and uses KMS. They would maybe even be interested in owning this library if they use KMS, but we don't for CT logs we run.

[roger2hk]

Closing this pull request as the KMS signing cost is quite expensive for the CT ecosystem when compared with in-memory signing. If any CT log operator is interested to use KMS signing, I will come back to this.