Re-evaluate SPIRE Server API authorization

[evan2645]

Many previous issues and PRs have taken attempts at solving a plethora of authorization pains that the SPIRE Server APIs currently face. These APIs tend to have a number of consumers, and the current authorization framework effectively provides an all-or-nothing authorization posture. This is particularly problematic for registrars which should have control over only a portion of the SPIFFE namespace, or for operators that should have the ability only to e.g. evict agents but not alter entries. These are two of many examples.

Initially, we tried to implement an OPA Rego-based authorization subsystem, which would allow users to provide their own authorization policies. This has been shipping as an experimental feature for quite some time now, however it suffers from many of its own unique challenges:

• It must be compatible with the existing authorization system in core, which has complicated the req/resp pattern that OPA expects
• This complexity is guaranteed to grow as flexibility in core increases, since we're obligated to support users that are not supplying us with OPA Rego
• Trivial mistakes in the user-provided policy can lead to catastrophic security holes in the SPIRE security posture
• We've been unable to identify a safe and straightforward way to perform any sanity check on the user supplied policies

This past Tuesday, SPIRE contributors discussed this issue and concluded that there is no clear path forward in terms of graduating OPA Rego support out of experimental. Rather, the consensus was that the only suitable solution is likely to be a major re-think of the way that SPIRE Server performs API authorization, and that the likely answer is a first-class authorization system based on roles/capabilities/etc.

This is an unscoped issue meant to explore and capture the possible solutions. This issue is done when we've made a decision on the basic shape of a solution, at which point we can open further issues.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[azdagron]

This is still relevant.