license_key_entitlements#36452
Conversation
bec463d to
cd879d2
Compare
| /// Repeatable: each `--entitlement <name>` adds one entitlement to the | ||
| /// signed key (e.g. `--entitlement ory`). | ||
| #[clap(long = "entitlement")] | ||
| entitlements: Vec<String>, |
There was a problem hiding this comment.
I'm not positive if Vec is the right shape.
Abrief discussion:
I think this makes sense if we roughly think of these as "FeatureFlags" which are always bool, and we treat inclusion as true, and omission as take the default. If we wanted to adopt broader systemVar it could be done in a seperate field.
There was a problem hiding this comment.
That seems very complicated. We also don't want to lock to a specific version of MZ, and we don't have access to this code from the oci-registry-proxy repo.
I see the work entitlement as "something you are allowed to get". To me, this is a simple boolean, and omission is false (or default I guess, but if you aren't "entitled" to it, the default is probably false).
Do you have a more concrete example of what type you want here? I don't really want to be juggling serde_json::Value everywhere.
jubrad
left a comment
There was a problem hiding this comment.
Yeah, I think I've convinced myself that this makes sense.
Add a new
entitlementsfield to our license keys, which is a list of strings.Motivation
Part of https://linear.app/materializeinc/issue/DEP-130/include-entitlements-in-newly-generated-license-keys
The first use case for these entitlements are for downloading the Ory Enterprise images through our registry proxy. Not all license keys will be allowed to get ory images.
Verification
New rust tests checking serialization/deserialization both with and without entitlements.