Clarifying authentication/authorization requirements

[alirazeen]

Hello! I'm just playing around with step ca and I'm wondering about what kinds of protections I need against unauthorized users using my public-facing step CA server.

As already discussed in #787, anyone can bootstrap against my Internet facing CA server. However, only actual authorized users can generate certificates anyways. For example, if I am using an OIDC provisioner in step ca, then only those valid users in that OIDC can generate things like SSH keys.

However, there seem to be some public endpoints that do NOT require any kind of authorization. For example, as far as I can tell, there's nothing that stops unauthorized users from running step ssh hosts and seeing all the hosts registered against my step ca instance. Is this an accurate observation? If so, I have two questions: 1) are there any other public endpoints that can potentially leak information, and 2) are there any recommendations to protect against such informational leaks?

[tashian]

Hi @alirazeen, great questions.

I've been working on a documentation section about this but it is still an early draft.

The main areas of concern are:

• Enumeration of infrastructure in the ssh hosts list, as you mentioned
• Enumeration of provisioners at the /provisioners endpoint
• Unauthenticated provisioners (especially ACME)

With ACME provisioners, the concerns are:

• If you use the default ACME provisioner configuration, anyone can get a certificate from your CA. So, you need to explicitly create policies to limit that.
• Furthermore, as a form of authentication, you can make an unguessable ACME directory URL that acts as a shared secret. If you do this, you'll need to block /provisioners from the internet as well, because otherwise your ACME directory URL will be exposed at that endpoint.

Generally speaking, it would make sense to create an allowlist of endpoints in your reverse proxy server—the minimum to allow your clients to enroll—and only forwarding those to step-ca.

[maraino]

@tashian we should also mention that if you enable ACME-DA you can get certificates for YubiKeys and Apple devices.

And perthaps that both /roots and /federation would show the root certificate, so you can also calculate the fingerprint and bootstrap using step.

[maraino]

Authorization webhooks can be a way to authorize the signing of certificates.

[hslatman]

For the SSH hosts listing specifically, there's a knob to disable the endpoint: disableGetSSHHosts in the authority object. It'll return a 404 when set to true.

[alirazeen]

Thank you all, for the suggestions and answers! This is very helpful to me. I think the combination of maybe using a reverse proxy + disableGetSSHHosts will solve my basic requirements of not leaking information. The authorization webhook suggestion might help me solve a different question that occurred to me earlier today, so thanks for answering that preemptively :)