Allowing GCP provisioner to issue SSH User Certificates - Option 1

[adantop]

Name of feature:

Allowing GCP provisioner to issue SSH User Certificates - Option 1

Pain or issue this feature alleviates:

Why is this important to the project (if not answered above):

Workloads running in GCP Compute Instances are run with an assigned Service Account. The Service Account authenticated on a given Compute Instance can be found in the Identity Token obtained from the metadata server that the GCP provisioner uses to obtain the Compute Instance identity and generate the SSH Host Certificate.

Allowing the GCP provisioner to issue SSH User Certificates would allow the above referred Workloads to use the smallstep infrastructure to sign into other Compute Instances. Examples of workloads that would benefit from this change are: CICD systems like Jenkins and Ansible.

Without this feature there would be two other options to achieve this:

• Have a separate JWK provisioner: This provisioner is present in the ca.json configuration file.
• Have a X5C provisioner to generate an intermediary X.509 certificate to then issue the SSH User Certificate from it: This option involves the creation of an intermediary certificate that could be used for TLS that will need to be maintained along with the SSH User Certificate.

However neither of these can validate the service account principal.

Is there documentation on how to use this feature? If so, where?

If this change is accepted we could update the documentation for the GCP provisioner here

In what environments or workflows is this feature supported?

This would work for smallstep-ca deployments that support GCP

In what environments or workflows is this feature explicitly NOT supported (if any)?

This will not work outside of GCP

Supporting links/other PRs/issues:

This proposal features minimal changes to the existing code, we removed the enforcement of the HostCert type, added the username validation and changed the certificate template. However this change requires a significant refactor to the tests because of the change in the certificate template which leads to rely more on the Certificate Sign Request as opposed to the provisioner sign options.

We propose a second approach which relies the most on the provisioner sign options but required a bigger refactor to the codebase:

#1558

❤️ Thank you!

[CLAassistant]

All committers have signed the CLA.

[maraino]

Thanks @adantop, we want to move forward with this, but I want to make some changes. We could work with both PRs; I like having the certType in the context, it could give us more flexibility. And as I have to pick one, I'll chose the second and close this one.