Open Policy Agent integration

[BenoitKnecht]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I've recently started using step-ca in my home lab, inspired by this great tutorial, and I'm loving it!

I setup my intermediate CA with name constraints, and one of the things that tripped me up was that step-ca still lets me sign certificates that will be rejected by clients because they violate these constraints, so I have to setup a policy that matches the intermediate CA name constraints, but then it's easy for them to diverge.

As I was looking into ways to improve this, I thought of a lot of other things that I may want to tweak in policies: maybe I want to allow certificates for some subdomains only if the request comes from a certain subnet, or let JWK provisioners generate tokens only if the request comes from a trusted IP address, you get the idea.

Since covering all these use-cases using a custom policy engine would be complex and inconvenient, Open Policy Agent came to mind as a generic way to express complex policies. It can either be integrated as a library, or run separately and be called through its HTTP API, all you need it to give it some input (which would contain the JWT, the source of the request, the requested SAN, whatever might be useful), and then policies are written using a simple declarative language, e.g.

package application.authz

import future.keywords

# Everyone can see pets up for adoption
allowed_pets contains pet if {
	some pet in input.pet_list
	pet.up_for_adoption
}

# Employees can see all pets.
allowed_pets contains pet if {
	[_, payload, _] := io.jwt.decode(input.token)
	payload.employee
	some pet in input.pet_list
}

This would let users define complex policies without having to change anything in step-ca itself, and even the current nameconstraint-inspired policies could be expressed as OPA policies.

Why is this needed?

As more and more use-cases need to be covered by step-ca policies, a custom policy engine will become more and more difficult to maintain. Leaning on the powerful policy language of OPA would make step-ca much more flexible and would let users comply with stricter security requirements in their organizations.

[dopey]

Hey @BenoitKnecht 👋. Thanks for opening this issue!

We've thrown this idea around before, and you've hit the nail on the head with the use cases you suggested.

I've added this to our triage and will update once we've had an internal conversation.

[dopey]

Hey @BenoitKnecht, appreciate your patience. We had a chance to discuss this issue, and Authz in general, this morning. Following up here with our general thoughts.

We don't think that a tighter integration with OPA (or other authorization software) should be part of step-ca's codebase. Instead, our vision is one where step-ca defines a number of lifecycle webhooks for the higher level cryptographic resources that it manages, and then developers to hook into those webhooks via plugins. More concretely, we imagine a list of developer configured webhooks that would be applied during a pre-sign authz lifecycle phase. One of those webhooks may reach out to an OPA plugin with the CSR, the planned certificate template, and other metadata the user stores in step-ca. See also this response from @maraino about a similar topic #731 (comment)

Let us know your thoughts on this plan. This will most likely be a slow roll out as we move the existing modifiers and validators towards a webhook style model.