AuthPolicy - configuration changes require restart

[PhilCorney]

SPIRE AuthPolicy OPA policy changes (AuthPolicy) require a server restart before taking effect, which could be problematic for production rollout.

Is there a recomended way to appying rego changes?

• Version: 1.4.3
• Platform: arm64 [single server]
• Subsystem: AuthPolicy

[MarcosDY]

It would be helpful if you could provide some more details around your use case and why the dynamic reloading is needed in your case.

[PhilCorney]

We're still exploring, but the percieved use case would be that of example 1 where we would want to be able to change departments being authorised without loosing service. Perhaps this should be rolled out by CICD with HA confIguration?

[dennisgove]

Issue #3282 discussed this type of dynamic rule changes by supporting a remote OPA instance. Separating the Policy Enforcement Point (SPIRE) and the Policy Decision Point (OPA) we would be able to support dynamic access rules without requiring a SPIRE restart. OPA already supports multiple mechanisms to dynamically change its internal ruleset.

However, the issue was closed because the maintainers felt support for remote OPA evaluation might be premature given that OPA integration in any form was still experimental.

[PhilCorney]

Thank you Dennis.
I liked the proposal there maybe performance/security implications for going down this route.
Are there plans to move this out of Experimental?

[evan2645]

Hey folks .. very sorry for the confusion around the state of support for OPA Rego ... I know that the signals have been a bit confusing.

We had a lengthy conversation around this issue, and all the surrounding ones, in our public contributor call this past Tuesday. IMO the configuration of a "remote" OPA (even if local) is table stakes for Rego support, however the original request was hampered by the current state/support of this feature... and the TL;DR there is, we have a hard time seeing a path forward in terms of graduating this feature out of experimental support.

I know that @dennisgove has some specific concerns around authorization ... and perhaps some of those are solved in other ways (e.g. supporting federated auth on SPIRE Server APIs, and permitting identities from foreign trust domains to be admins). But putting that aside, the general feeling here is that OPA Rego support hasn't quite gotten us as far as we'd hoped, and the downsides outweigh the upsides. This conclusion makes it hard to reason about committing further effort to supporting OPA Rego integration - instead, we'd like to focus conversation towards a new solution. I opened #3620 for this purpose.

I know that this isn't the news that you might have hoped for, but I do believe that it's the right call. I think that some community needs can be met with targeted feature implementation in the short term ... and in the long term, I hope that we can move to a system with first class authorization implemented with something like rbac/capabilities/etc

[dennisgove]

Thank you @evan2645. I agree with this move and am glad that we're going to take the opportunity to re-think SPIRE authorization.

[PhilCorney]

Thank you for the update and sharing the rational.
That makes sense.
Phil