-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Labels
bugSomething isn't workingSomething isn't working
Description
Ref. b2652a5:
A client without any scopes is disallowed; ideally we shouldn't even
create a Maskinporten client if the spec only defines scopes to be
exposed and none consumed.This commit adds a default consumer scope for the Maskinporten client if
none are defined. Ideally, the "exposed scope" directive should be split out
into its own resource and reconciler rather than being tied directly to a
MaskinportenClient resource.
Other pain points with tying exposure of scopes to a single MaskinportenClient:
- ownership becomes unclear:
- multiple application manifests may define the same scope, but the source of truth is the last applied manifest
- what happens if the same application in the same namespace, but in different clusters have the same exposed scope?
- tracking desired and actual state becomes difficult (e.g. how do we determine that a scope should be deleted?)
The scopes we create via Digdirator today are also subject to some strange rules:
- The separator changes depending on whether you use a slash or a colon in its
name
: https://doc.nais.io/auth/maskinporten/reference/#scope-naming - This seems like unnecessary complexity and has also caused issues with delegation in Altinn, ref. https://nav-it.slack.com/archives/C5KUST8N6/p1708687933366659?thread_ts=1708329367.919129&cid=C5KUST8N6
- To remove implicit behaviour, the
name
itself should be authorative for the whole (sub)scope (except for the prefix, which is obviously set centrally at Digdir)
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working