Live data from Hacker News

Easy private certificate management for VMs on AWS, GCP, and Azure

smallstep.com

11–20 of 20 posts

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#11
post #10
post #9

Earlier quoted context omitted.

Since it's my own CA, I have a few personal scripts that handle it. Everything else (like the root cert) is handled offline with a different physical device. It's nothing more than some glorified bash stuff and pulling public CA's from my own sites. XCA is a gui for dealing with making certs. For me even as a technical user, i prefer it more than CLI.

Cool that's good feedback. We've been working on a web interface that we could maybe turn into an electron app for this sort of stuff. I'm probably pressing my luck promoting here but if you do a bunch of cert related stuff check out our `step certificate` command group at https://smallstep.com/docs/cli/certificate/#commands -- it does a bunch of cool stuff like dumping x509 as JSON and extracting public keys and lin…

I will be taking a look at it for sure! Like I said i'm pretty small time, but I love the power of having my own CA.

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#12
I feel like the lack of "audience" field (or equivalent) in AWS IID makes them bit less attractive for authentication than GCP/Azure ones. For example here step-ca could impersonate (if compromised) the client instance to any other services that were to use IID for auth (or vise versa).

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#13
post #12

I feel like the lack of "audience" field (or equivalent) in AWS IID makes them bit less attractive for authentication than GCP/Azure ones. For example here step-ca could impersonate (if compromised) the client instance to any other services that were to use IID for auth (or vise versa).

Yep. AWS's instance identity implementation is crap. I want to write a follow-up blog post about this. They also don't rotate their keys and their tokens don't expire. To top it off, their implementation is buggy and terribly documented. Honestly it's pretty shameful. They have the resources to fix it, and they should fix it. GCP's implementation is the best. It's JWT-based and heavily inspired by OAuth OIDC identity tokens and uses a lot of the same infrastructure. Azure's is a close second. None are perfect.

That said, even AWS's crappy implementation is super useful, and really the only good way to do this (that I know of?). We've tried to mitigate this risk somewhat by making tokens single use. I'd like to also add a way to send a token to `step-ca` to say "this server doesn't need a certificate" that basically marks the instance as "used" without issuing anything. If everything that uses IIDs did this, and you ran through all of your services at startup and either authenticated or said "I never need to use this service", it would provide some protection.

Still, to your point, AWS should fix their shit.

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#14
post #13
post #12

I feel like the lack of "audience" field (or equivalent) in AWS IID makes them bit less attractive for authentication than GCP/Azure ones. For example here step-ca could impersonate (if compromised) the client instance to any other services that were to use IID for auth (or vise versa).

Yep. AWS's instance identity implementation is crap. I want to write a follow-up blog post about this. They also don't rotate their keys and their tokens don't expire. To top it off, their implementation is buggy and terribly documented. Honestly it's pretty shameful. They have the resources to fix it, and they should fix it. GCP's implementation is the best. It's JWT-based and heavily inspired by OAuth OIDC identity…

Btw can step create client certs? That would reduce the need to use IID for anything else, even if it doesn't really resolve the underlying issues with IID

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#15
post #14
post #13

Earlier quoted context omitted.

Yep. AWS's instance identity implementation is crap. I want to write a follow-up blog post about this. They also don't rotate their keys and their tokens don't expire. To top it off, their implementation is buggy and terribly documented. Honestly it's pretty shameful. They have the resources to fix it, and they should fix it. GCP's implementation is the best. It's JWT-based and heavily inspired by OAuth OIDC identity…

Btw can step create client certs? That would reduce the need to use IID for anything else, even if it doesn't really resolve the underlying issues with IID

Yep. That's my preferred solution, obviously ;)

Certs have "TLS Client Authentication" key use set by default.

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#17
post #16

What's the advantage of this over some scripts like https://github.com/tomberek/easy-ca ?

See the comparison to cfssl below. Step has lots more features, is easier to use, and harder to misuse. Relative to easy-rsa, the most important difference is that step-ca is a service that can issue certs via an API. Combined with step it can also help with lots of cert management tasks like root distribution and automated renewal.

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#18
post #8
post #7

The idea and functionality looks good. Some quick friendly feedback: For production I would want to run this in Docker in some sort of a portable fashion. Looking at the documentation it seems that you have to manually enter the password when you start up step-ca. That's not really going to work for automated setups. You need to be able to inject secrets from environment variables, or these days, Kubernetes secrets.…

> For production I would want to run this in Docker in some sort of a portable fashion. Do https://hub.helm.sh/charts/smallstep/step-certificates & https://hub.docker.com/r/smallstep/step-ca tick this box for you? > Looking at the documentation it seems that you have to manually enter the password when you start up step-ca... environment... kubernetes secrets There are a couple options here. You're only prompted for…

Excellent response, thank you. Answers all my questions.

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#19
This is very neat stuff and I'd actually be interested in talking to you more about where you see it going in the future, because it's extremely closely related to some stuff I've worked on. One clarification:

Am I understanding it correctly that step-ca can be configured to either 1) hand out certs for any CN or 2) only hand out certs for the machine's FQDN according to the instance metadata? In essence, the "any CN" mode is only useful for knowing that this instance is one of your own (but exactly which one is totally on the honor system), and the "FQDN only" mode is useful if you use your cloud provider's FQDNs for your hosts. Do I have that correct?

Re: Easy private certificate management for VMs on AWS, GCP, and Azure

#20

This is very neat stuff and I'd actually be interested in talking to you more about where you see it going in the future, because it's extremely closely related to some stuff I've worked on. One clarification: Am I understanding it correctly that step-ca can be configured to either 1) hand out certs for any CN or 2) only hand out certs for the machine's FQDN according to the instance metadata? In essence, the "any CN…

Yes, your understanding is correct. I think it's slightly better than you suggest... since instance identity authentication only works once per instance (by default) you'd probably have some other monitoring stuff in your stack that would notice if a VM went rogue. If a `foo` instance got a cert for `bar` your CD stack would presumably still consider it a `foo` instance and, for example, add it to DNS as `foo`. Then connections to that instance would fail (since it can't authenticate as `foo`) and, hopefully, you'd notice.

Still, this is hand-wavey and complicated and not ideal from a security perspective. It's a lot better than not having certificates at all, but it'd be even better if this gap were closed.

To close this gap we need some sort of enrollment process. The reason we didn't add this for MVP is it's kind of complicated. I think we'd need some policy at the CA that maps VM identities to the workload identities the VM is authorized to run. We need to figure out what would run this enrollment step to add the mappings (probably different for different stacks) and how that thing would authenticate to the CA.

We've also been a bit reluctant to add ad-hoc policy stuff to the CA because we have a generic policy solution that we've been working on. Once that's released it'll give us a much better foundation for this sort of stuff.

Finally, there are other ways to build a stronger enrollment mechanism today. We have a JWT-based one-time-token authentication mechanism[1] that you can use, where a "provisioner" (e.g., something in your CD pipeline like Puppet or Kubernetes) issues a one-time token for a workload to get a certificate from `step-ca`. In this flow the JWT contains the workload's identity, so whatever issues the JWT controls certificate enrollment. This flow has pretty much the same characteristics as an IID+enrollment flow.

Finally, we have ACME support coming soon (next week, actually). So that'll be another option if you want a stronger binding to an instance's FQDN.

Hope this makes sense. Happy to answer any additional questions!

[1] https://smallstep.com/docs/design-document/#jwk-provisioner

Post reply on HN