AuthorizationPolicy: add `serviceAccounts` field #3340

howardjohn · 2024-10-18T20:24:27Z

This is a minor implementation complexity in favor of a dramatic
simplification to usage of Istio authorization.

Today, if a user wants to dive into zero-trust 101, they are presented
with a requirement to set principals: A list of peer identities derived from the peer certificate, and write
<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>.

This simple sentance is a huge cognitive overload for users in my
experience working with users, and unnecesarily pushes SPIFFE, trust
domains, and other unneccesary concepts onto users. Additionally, the
requirement to set 'trust domain', which is overwhelmingly not desired
by users who just want SA auth, leads to all sorts of wonky workarounds
in Istio like cluster.local being a magic value.

Instead, we just add a SA field directly. This takes the format ns/sa,
as you cannot safely reference a SA without a namespace field as well.
Note we do this, rather than just require you to set 'service account' and 'namespace'
as individual fields, since you could have namespace=[a,b],sa=[d,e]
which is ambiguous.

If this is directionally approved, I will add some more documentation
and CEL validation and testing.

hzxuzhonghu

And you should document only one field can be specified

hzxuzhonghu · 2024-10-21T02:55:57Z

security/v1beta1/authorization_policy.proto

@@ -428,6 +428,8 @@ message Source {
  // `"<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>"`, for example, `"cluster.local/ns/default/sa/productpage"`.
  // This field requires mTLS enabled and is the same as the `source.principal` attribute.
  //
+  // Usage of `serviceAccounts` is typically simpler and offers the same functionality.


nope, if this is a client from outside, sa is not known, in this case principals is still needed.

I don't get it. If I know to write spiffe://cluster.local/ns/foo/sa/bar then surely I can know to write foo/bar?

If the client is from external, the identity could be any format, nit limited to spiffe://cluster.local/ns/foo/sa/bar

In that case the user would not use this field then.

It's not deprecating principals,just making the 99.9999% use case easier

Maybe something like this would clarify?

Suggested change

// Usage of `serviceAccounts` is typically simpler and offers the same functionality.

// Usage of `serviceAccounts` is typically simpler and offers similar functionality. For complex scenarios principals are still fully supported.

It's not even for "complex" scenarios - hardcoding principals in the bespoke Istio format in our Auth policies is one reason we can't currently support complex scenarios at all (custom SPIFFE IDs, SPIRE etc) - so we should just say that:

Suggested change

// Usage of `serviceAccounts` is typically simpler and offers the same functionality.

// Usage of `serviceAccounts` is typically simpler and offers the same security guarantees. Principals are still fully supported, but not recommended, as encoding complete principal strings leads to fragile policies.

ilrudie

Direction looks good. This seems inline with ambient's overarching mission to simplify the things which can be simple.

ilrudie · 2024-10-22T14:57:45Z

And you should document only one field can be specified

Is this decided for sure? It seems to me that mixing and matching is plausible even if likely not recommended and more error prone.

howardjohn · 2024-10-22T15:01:54Z

Is this decided for sure? It seems to me that mixing and matching is plausible even if likely not recommended and more error prone.

IMO you should be able to set both. The fields are not strictly related... its fine to say I want to allow from 'foo/bar OR spiffe://something-else'

bleggett · 2024-10-23T16:20:56Z

And you should document only one field can be specified

You should be able to include as many fields as Istio chooses to support in the AuthPolicy, ultimately - if they can be matched against the identity/principal, we will match them.

So this will probably eventually be a list of substrings to match against OR a whole SPIFFE ID.

SA is all we need to start, but this is also heavily related to istio/istio#43105 - effectively we cannot even properly support arbitrary SPIFFE IDs without this, so this is required for better SPIFFE/SPIRE support as well.

All that is really required is to match against substrings - whether Istio happens to be matching against a SPIFFE ID principal in the Istio format internally or not doesn't matter.

IMO you should be able to set both. The fields are not strictly related... its fine to say I want to allow from 'foo/bar OR spiffe://something-else'

as long as this is a strict OR, I agree - this will help encourage people to stop hardcoding SPIFFE IDs in auth policies in the Istio-specific format, which is the only real obstacle we have to supporting customizable SPIFFE IDs.

EDIT: actually wrong - this will still work just fine.

bleggett · 2024-10-23T17:13:25Z

security/v1beta1/authorization_policy.proto

+  //
+  // This takes the format `<namespace>/<serviceaccount>`.
+  //
+  // If not set, any service account is allowed.


Suggested change

// If not set, any service account is allowed.

// If not set, any service account is allowed.

// if both principal and this field are set, this field has precedence

If we are going to let people set both, we need to be explicit about whether it's an AND or an OR match, and what the precedence is if both are set.

(probably with a blurb on both principal and service account)

I think setting both should be allowed. Presumably internally we can normalize the types and then can just append one list to the other, dedupe and move on so neither takes precedence.

I think setting both should be allowed. Presumably internally we can normalize the types and then can just append one list to the other, dedupe and move on so neither takes precedence.

The problem is I don't think you can actually do that/it would make the existing problem worse to do that.

Given an AuthPol

principal: spiffe://example.org/ns/default/sa/my-sa service_account: default/my-sa

How do I evaluate the AuthPol if the presented workload principal is actually (best case)

spiffe://example.org/ns/default/sa/my-sa/some/other/stuff

or (worst case)

spiffe://example.org/beep/boop/ns/default/sa/my-sa

which should win in that case? Neither?

If we change this, we should at least change it in a way that makes istio/istio#43105 easier, and not harder. Supporting things other than the principal in AuthPol definitely makes #43105 easier, but not if we ignore the current problem we have with encouraging people to put fixed/complete principal strings in their AuthPolicies, which creates the secondary problem of forcing everyone to use a very specific/exact/fixed principal format which is compatible with no other product.

We either need to make the combined semantics very clear in the API, or make them mutually exclusive - I don't much care which, but I think it has to be one or the other.

maybe I misunderstand but my guess was internally we would use this as a shorthand for a spiffe ID in the istio format making the conversion from ns/sa to spiffe pretty straight forward. I do agree that spiffe -> ns/sa presumes all spiffe IDs are in the istio format which we likely don't want but spiffe -> ns/sa is lossy so we probably don't want to do that conversion even if we were ok mandating the istio format

I think the use case for a mix and match would, in practice, be limited. If you want to require some advanced ID format which includes some/other/stuff then I don't think relying on ns/sa is going to work for you really at all and in that case you should NOT try to specify things that way. I just don't think our API can really track the user's intent in that way. If this is your scenario then you probably need additional policy to enforce it

Ah nevermind, I had forgotten we support N principal strings.

Principals:
spiffe://td/ns/<ns>/sa/<sa>
spiffe://td/ns/<ns>/sa/<sa>/foo/bar/baz

SA:
ns/sa

So the above would OR the principal(s) and AND the SA.

That's fine, then. The problem I was thinking of was

Principals:
spiffe://td/ns/<ns>/sa/<sa>

SA:
ns/sa

but my actual principal is spiffe://td/ns/<ns>/sa/<sa>/foo/bar/ba

Here this would still fail because of exact matching, but we could just say either define all possible principals, or none and only use SA - with none being preferred in most cases, as it makes using arbitrary SPIFFE IDs much easier.

So then the expectation is that we change things and configure our proxies to do a match on both "ns/specified-ns" and "sa/specified-sa" being present in the SANs if we are using this field?

The API as I read it doesn't require the new service_account field to be a strict substring of the SPIFFE ID.

So that means if we have an AuthPol with

service_account: default/bar

we can internally map that against an identity principal of

spiffe://td/ns/default/sa/bar

OR

spiffe://td/ns/default/sa/bar/baz/beep/boop

pretty trivially with one AuthPolicy, and de-opinionate on the "SPIFFE ID format".

which means it's possible to now write an AuthPolicy that won't break if you change your SPIFFE ID format.

(impl is TBD but I am happy to have a way to express this in the API at all, which was lacking before)

I largely agree with Ian's comment about semantic assumptions in this thread.

We clearly have limitations in how we interpret SPIFFE URIs when the principal is a multi-path segment but leaving those aside for a moment these are both ways to define principals and should be ORed

After all there's not a lot of logical difference between the new fields and allowing a new URI type in this field to reference SAs. E.g

k8s://ServiceAccount/{namespace}/{name}

This is also the same damn thing as targetRef which has the nice property of allowing for reference expansion without requiring the API to evolve. E.g. this would allow for the introduction of types which represented principal groups to be referenced if they were added to the system

I largely agree with Ian's comment about semantic assumptions in this thread.

We clearly have limitations in how we interpret SPIFFE URIs when the principal is a multi-path segment but leaving those aside for a moment these are both ways to define principals and should be ORed

Yeah, I'm fine with OR - AND is what I originally thought made it a bit tricky given current assumptions Istio makes about SPIFFE ID formats (but even that is work-around-able, so I'm not worried about it)

After all there's not a lot of logical difference between the new fields and allowing a new URI type in this field to reference SAs. E.g

k8s://ServiceAccount/{namespace}/{name}

Do our APIs need any assumptions about principal formats at all? I kind of believe they do not.

e.g. istio cares about SA/NS/TD. How those are encoded in a specific principal format shouldn't be an API assumption, and doesn't need to be. The code behind the API just needs to know how to extract those, to match them.

The API doesn't need to care if the principal format is

k8s://ServiceAccount/{namespace}/{name}

spiffe://foo/bar/baz/ServiceAccount/{namespace}/{name}

some x509 custom fields

as long as the policy encodes the properties, it doesn't need to explicitly encode the format that contains them at all, AFAICT. The API defines the properties that must match, the code defines how to extract those from $WHATEVER_SUPPORTED_PRINCIPAL_FORMATS we handle.

This is also the same damn thing as targetRef which has the nice property of allowing for reference expansion without requiring the API to evolve. E.g. this would allow for the introduction of types which represented principal groups to be referenced if they were added to the system

something like

targetRefs: - principalTypes

?

I suspect this comment thread is close to my last comment - to be clear my suggestion is to just use the existing principal field, with a URL or DID syntax, and to not emphasize the service account but namespace and a service account prefix.

security/v1beta1/authorization_policy.proto

bleggett

This LGTM and makes istio/istio#43105 much easier to boot.

It may be necessary to add something like a trust domain later, but I do think it's much better to have an API that looks like

service_account
trust_domain
...etc

versus

exactPrincipal

or

matcherTupleWhichIsAKindOfIdentity (random fixed fields)

howardjohn · 2024-10-28T20:32:27Z

I've added some tests and validation. I have blocked usage of SA with principals, in the same from, since they are ANDed -- it does not make sense to say "from ns=a AND sa=foo/bar".

bleggett · 2024-10-28T21:35:57Z

I've added some tests and validation. I have blocked usage of SA with principals, in the same from, since they are ANDed -- it does not make sense to say "from ns=a AND sa=foo/bar".

It occurs to me we have historically supported (in the API validation sense, not the logical sense)

from ns=a AND principal=spiffe://td/ns/b/sa/c

which is, by the same token, also ~always a validation error we should probably check for (but that's OOS for this PR - I agree we should proactively validate the net-new bits like you've done it here)

security/v1beta1/authorization_policy.proto

hzxuzhonghu

Thank you

linsun

Felt a little odd to have namespace inside the value for serviceAccount while we also have namespace as a separate field under source but does make sense in this context.

LGTM

howardjohn · 2024-12-02T20:10:18Z

Felt a little odd to have namespace inside the value for serviceAccount while we also have namespace as a separate field under source but does make sense in this context.

LGTM

I thought the same initially and I would not have done it, but the two are lists and NS supports globbing, so we cannot meaningfully re-use the field IMO

linsun · 2024-12-09T15:52:54Z

Hi @louiscryan a friendly ping on this, any objections?

This is a minor implementation complexity in favor of a dramatic simplification to usage of Istio authorization. Today, if a user wants to dive into zero-trust 101, they are presented with a requirement to set `principals`: `A list of peer identities derived from the peer certificate`, and write `<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>`. This simple sentance is a huge cognitive overload for users in my experience working with users, and unnecesarily pushes SPIFFE, trust domains, and other unneccesary concepts onto users. Additionally, the requirement to set 'trust domain', which is overwhelmingly not desired by users who just want SA auth, leads to all sorts of wonky workarounds in Istio like `cluster.local` being a magic value. Instead, we just add a SA field directly. This takes the format `ns/sa`, as you cannot safely reference a SA without a namespace field as well. Note we do this, rather than just require you to set 'service account' and 'namespace' as individual fields, since you could have `namespace=[a,b],sa=[d,e]` which is ambiguous. If this is directionally approved, I will add some more documentation and CEL validation and testing.

costinm

Sorry for the late comment - when I read it first it sounded like a great idea, but I recently changed my mind a bit.

The fundamental problem with principal is the documentation stating "it must be in the weird spiffe format that only Istio is using". A service account in another weird format only used by Istio is not making things much better.

Keep in mind a service_account has the built-in assumption that multi-cluster is a flat trust model (which is not entirely true if you use principal fully). It also has a built in assumption that the identity is expressed a K8S service account ( there are many other service accounts ).

And while namespace is very important - the service account in the client namespace is quite less important and very hard to track if others use the model of one service account per revision.

In the end - the service_account is still a principal, just a very narrow kind.

How about just relaxing the docs and validations on principal, and allow either a url or 'did' like format - with a prefix that indicate what kind of principal it is.

Like did - we can have did:k8s:namespace or did:k8sprefix:namespace:sa_prefix (to deal with what I think is quite common case of versioned service account - see Istiod own use). And we can also support non-Istio SANs ( plain old service accounts using an email format), or DNS ( now that using did:web is getting popular ).

howardjohn · 2024-12-17T19:31:03Z

A service account in another weird format only used by Istio is not making things much better.

I have a hard time aligning this with the current state of Istio. Service Account is the core identity primitive in Istio -- full stop. Yet we make people express their polices in a weird Istio internal format (spiffe) instead of letting them directly reference the primitive.

It would be like an IAM engine that, instead of letting you say email: [email protected] makes me say identity: auth://internal/email/[email protected]. The former is a lot more ergonomic for a user to deal with than trying to understand yet another mapping of one concept to another

Keep in mind a service_account has the built-in assumption that multi-cluster is a flat trust model (which is not entirely true if you use principal fully)

I agree but this is a feature -- if a user wants to express the full identity (taking into account trust domain) they are free to do so! But in many cases, they actually want to express just the SA (namespace sameness is a core tenant of Istio and basically every multi-cluster identity scheme from cloud k8s providers). The existance of the serviceAccounts field doesn't preclude a user from using principals.

It also has a built in assumption that the identity is expressed a K8S service account ( there are many other service accounts ).

The existence of the serviceAccounts field doesn't preclude a user from using principals. Just because we support many formats doesn't mean we cannot offer helpers to easily and safely reference the common use cases.

And while namespace is very important - the service account in the client namespace is quite less important and very hard to track if others use the model of one service account per revision.

The existence of the serviceAccounts field doesn't preclude a user from using namespaces...

In the end - the service_account is still a principal, just a very narrow kind.

It is narrow, perhaps, in the broad sense. In Istio, it covers >99% of use cases. Its also likely to become the core primitive for NetworkPolicy in Kubernetes (kubernetes-sigs/network-policy-api#274).

How about just relaxing the docs and validations on principal, and allow either a url or 'did' like format - with a prefix that indicate what kind of principal it is.
Like did - we can have did:k8s:namespace or did:k8sprefix:namespace:sa_prefix (to deal with what I think is quite common case of versioned service account - see Istiod own use). And we can also support non-Istio SANs ( plain old service accounts using an email format), or DNS ( now that using did:web is getting popular ).

This generally defeats the purpose of this proposal IMO... The issue is not the lack of ability to specify things, but the lack of ability to understand how to use the API. Adding yet another obscure format doesn't seem to meaningfully help this situation.

costinm · 2024-12-17T19:59:12Z

On Tue, Dec 17, 2024 at 11:31 AM John Howard ***@***.***> wrote: A service account in another weird format only used by Istio is not making things much better. I have a hard time aligning this with the current state of Istio. Service Account is *the core identity primitive* in Istio -- full stop. Yet we make people express their polices in a weird Istio internal format (spiffe) instead of letting them directly reference the primitive.

Well - for client identification, the service account is the core identity for K8S clients and in Istio, but I would argue the namespace is really the 'core' boundary in both Istio and K8S. I don't disagree that the current spiffe format in principal is bad - my point is that 'principal' is the core concept for authentication in general, and it is in no way restricted to spiffe or istio format. We added it precisely to allow non-Istio (and non-K8S) identities to be expressed.

It would be like an IAM engine that, instead of letting you say email: ***@***.*** makes me say identity: ***@***.*** The former is a lot more ergonomic for a user to deal with than trying to understand yet another mapping of one concept to another

Yes, 100% agree. So principal: ***@***.***

Keep in mind a service_account has the built-in assumption that multi-cluster is a flat trust model (which is not entirely true if you use principal fully) I agree but this is a feature -- if a user wants to express the full identity (taking into account trust domain) they are free to do so! But in many cases, they actually want to express just the SA (namespace sameness is a core tenant of Istio and basically every multi-cluster identity scheme from cloud k8s providers). The existance of the serviceAccounts field doesn't preclude a user from using principals.

I'm not saying it precludes - just that another istio-invented syntax is not the best option. See also https://kubernetes.io/docs/setup/best-practices/certificates/* - *another syntax/format for service accounts used by K8S, or the syntax used in K8S issued JWT tokens. If it was 'namespaces' - I wouldn't mind - it is a clear concept and doesn't need another mangling.

It also has a built in assumption that the identity is expressed a K8S service account ( there are many other service accounts ). The existence of the serviceAccounts field doesn't preclude a user from using principals. Just because we support many formats doesn't mean we cannot offer helpers to easily and safely reference the common use cases.

I meant: "one" service account. Istiod identity is not expressed as a single service account - it's a set of service accounts that change with each version.

And while namespace is very important - the service account in the client namespace is quite less important and very hard to track if others use the model of one service account per revision. The existence of the serviceAccounts field doesn't preclude a user from using namespaces...

Or using a `principal: k8s:namespace:serviceaccount` ( or whatever the format K8S is already using in JWTs and client certs) - instead of an Istio namespace/serviceaccount

In the end - the service_account is still a principal, just a very narrow kind. It is narrow, perhaps, in the broad sense. In Istio, it covers >99% of use cases. Its also likely to become the core primitive for NetworkPolicy in Kubernetes (kubernetes-sigs/network-policy-api#274 <kubernetes-sigs/network-policy-api#274>).

It doesn't even cover Istiod use case (versioned SA). If the NetworkPolicy is adopted and uses ns/sa syntax - I don't have any objections. My concern is defining another Istio-only syntax for KSA.

How about just relaxing the docs and validations on principal, and allow either a url or 'did' like format - with a prefix that indicate what kind of principal it is. Like did - we can have did:k8s:namespace or did:k8sprefix:namespace:sa_prefix (to deal with what I think is quite common case of versioned service account - see Istiod own use). And we can also support non-Istio SANs ( plain old service accounts using an email format), or DNS ( now that using did:web is getting popular ). This generally defeats the purpose of this proposal IMO... The issue is not the lack of ability to specify things, but the lack of ability to *understand how to use* the API. Adding yet another obscure format doesn't seem to meaningfully help this situation.

So adding an obscure `serviceAccount: namespace/serviceAccount` is significantly better than `principal: k8s:namespace:sa` ? See my previous comment: if it is a syntax that is shared with NetworkPolicy and not unique to Istio - no concerns, looks good. I have not seen you address the versioned service accounts - which is IMO one of the biggest issues. Costin

…

Message ID: ***@***.***>

costinm · 2024-12-17T20:01:47Z

To be clear: I'm 100% for replacing the spiffe URL in principal, I loved the proposal initially and I fully support using a more explicit service account. The details of the syntax - and limitations on expressing versioned SA - are the problem, not preserving the use of the current (bad) syntax.

…

On Tue, Dec 17, 2024 at 11:58 AM Costin Manolache ***@***.***> wrote: On Tue, Dec 17, 2024 at 11:31 AM John Howard ***@***.***> wrote: > A service account in another weird format only used by Istio is not > making things much better. > > I have a hard time aligning this with the current state of Istio. Service > Account is *the core identity primitive* in Istio -- full stop. Yet we > make people express their polices in a weird Istio internal format (spiffe) > instead of letting them directly reference the primitive. > Well - for client identification, the service account is the core identity for K8S clients and in Istio, but I would argue the namespace is really the 'core' boundary in both Istio and K8S. I don't disagree that the current spiffe format in principal is bad - my point is that 'principal' is the core concept for authentication in general, and it is in no way restricted to spiffe or istio format. We added it precisely to allow non-Istio (and non-K8S) identities to be expressed. > It would be like an IAM engine that, instead of letting you say email: > ***@***.*** makes me say identity: ***@***.*** > The former is a lot more ergonomic for a user to deal with than trying to > understand yet another mapping of one concept to another > Yes, 100% agree. So principal: ***@***.*** > Keep in mind a service_account has the built-in assumption that > multi-cluster is a flat trust model (which is not entirely true if you use > principal fully) > > I agree but this is a feature -- if a user wants to express the full > identity (taking into account trust domain) they are free to do so! But in > many cases, they actually want to express just the SA (namespace sameness > is a core tenant of Istio and basically every multi-cluster identity scheme > from cloud k8s providers). The existance of the serviceAccounts field > doesn't preclude a user from using principals. > I'm not saying it precludes - just that another istio-invented syntax is not the best option. See also https://kubernetes.io/docs/setup/best-practices/certificates/* - *another syntax/format for service accounts used by K8S, or the syntax used in K8S issued JWT tokens. If it was 'namespaces' - I wouldn't mind - it is a clear concept and doesn't need another mangling. > It also has a built in assumption that the identity is expressed a K8S > service account ( there are many other service accounts ). > > The existence of the serviceAccounts field doesn't preclude a user from > using principals. Just because we support many formats doesn't mean we > cannot offer helpers to easily and safely reference the common use cases. > I meant: "one" service account. Istiod identity is not expressed as a single service account - it's a set of service accounts that change with each version. > And while namespace is very important - the service account in the client > namespace is quite less important and very hard to track if others use the > model of one service account per revision. > > The existence of the serviceAccounts field doesn't preclude a user from > using namespaces... > Or using a `principal: k8s:namespace:serviceaccount` ( or whatever the format K8S is already using in JWTs and client certs) - instead of an Istio namespace/serviceaccount > In the end - the service_account is still a principal, just a very narrow > kind. > > It is narrow, perhaps, in the broad sense. In Istio, it covers >99% of > use cases. Its also likely to become the core primitive for NetworkPolicy > in Kubernetes (kubernetes-sigs/network-policy-api#274 > <kubernetes-sigs/network-policy-api#274>). > It doesn't even cover Istiod use case (versioned SA). If the NetworkPolicy is adopted and uses ns/sa syntax - I don't have any objections. My concern is defining another Istio-only syntax for KSA. > How about just relaxing the docs and validations on principal, and allow > either a url or 'did' like format - with a prefix that indicate what kind > of principal it is. > Like did - we can have did:k8s:namespace or > did:k8sprefix:namespace:sa_prefix (to deal with what I think is quite > common case of versioned service account - see Istiod own use). And we can > also support non-Istio SANs ( plain old service accounts using an email > format), or DNS ( now that using did:web is getting popular ). > > This generally defeats the purpose of this proposal IMO... The issue is > not the lack of ability to specify things, but the lack of ability to *understand > how to use* the API. Adding yet another obscure format doesn't seem to > meaningfully help this situation. > So adding an obscure `serviceAccount: namespace/serviceAccount` is significantly better than `principal: k8s:namespace:sa` ? See my previous comment: if it is a syntax that is shared with NetworkPolicy and not unique to Istio - no concerns, looks good. I have not seen you address the versioned service accounts - which is IMO one of the biggest issues. Costin > Message ID: ***@***.***> >

bleggett · 2024-12-17T20:04:08Z

How about just relaxing the docs and validations on principal, and allow either a url or 'did' like format - with a prefix that indicate what kind of principal it is.

Like did - we can have did:k8s:namespace or did:k8sprefix:namespace:sa_prefix (to deal with what I think is quite common case of versioned service account - see Istiod own use). And we can also support non-Istio SANs ( plain old service accounts using an email format), or DNS ( now that using did:web is getting popular ).

This is kinda why I mentioned above I would ultimately rather the API not support specifying particular principal formats at all - there are many, and the Istio API, strictly speaking, does not need to care about them at all.

In an ideal world no one would put principals or encode specific principal formats in their AuthPols at all, they'd simply define one or more "principal property matchers" in the API, and then the same AuthPol can be applied to any principal format Istio happens to support internally (did, x509 fields, SPIFFE, JWT, whatever)

howardjohn · 2024-12-17T20:07:01Z

is significantly better than principal: k8s:namespace:sa

Setting aside what is a better UX, which is a higher opinionated topic... I functionally don't think we can do this. The contract today is that principal is direct mapping to the (SPIFFE specific) URI SAN. We cannot really change that -- how would we know if we were supposed to be treating that as a service account reference, or a strange SPIFFE url? There is also all sorts of complexities in the principal field like wildcards -- what if a user does principal: *k8s:namespace:sa?

I worry this would bring even more confusion to users, not less.

Keep in mind most Istio users are far from authentication experts. You (and probably everyone on this PR) are easily in the 99.999% percentile in that regard -- most people probably don't even know what a principal means in the first place!

I have not seen you address the versioned service accounts - which is IMO one of the biggest issues.

Please do not scope creep this... The goal is not to allow more functionality, its to make core use cases easier which has been the consistent goal of the project for the last 3 years.

howardjohn · 2024-12-17T20:10:00Z

To be super clear -- the use case I am trying to solve is this: https://istio.io/latest/blog/2022/get-started-ambient/#l4-authorization-policies.

The vast majority of policies are of this form, and its such a huge cliff to understanding Istio. Its the top motivator for Istio adoption, we have it as literally step 1 in our (and others) getting started walkthroughs, and its 10x more complicated than it needs to be!

costinm · 2024-12-17T22:26:13Z

On Tue, Dec 17, 2024 at 12:07 PM John Howard ***@***.***> wrote: is significantly better than principal: k8s:namespace:sa Setting aside what is a better UX, which is a higher opinionated topic... I functionally don't think we can do this. The contract today is that principal is direct mapping to the (SPIFFE specific) URI SAN. We cannot really change that -- how would we know if we were supposed to be treating that as a service account reference, or a strange SPIFFE url? There is also all sorts of complexities in the principal field like wildcards -- what if a user does principal: *k8s:namespace:sa? I worry this would bring even more confusion to users, not less.

SIPFFE is a URI SAN with spiffe:// scheme. We currently don't require the scheme - but the actual principal must have it, so that's already a big part of the confusion. I don't think changing the docs (and validation) to allow users to specify the scheme - and exactly match the principal and the SAN - is confusing or problematic, and it is possible to do it in a backwards-compatible way. If we allow scheme: I don't see the confusion in allowing other schemes, like k8s. Taking up words like 'principal' or 'serviceAccount' - and using them in a super narrow and 'original' sense - as 'istio mangling of a service account to a URL without scheme' and 'k8s service account in a particular istio specific format' is far more confusing than the normal semantics that people outside istio use. Allowing wildcards in principal is a slightly different topic - if we do, we should probably seriously consider deprecating it. Prefix may be ok, different field may be ok too - but regex and arbitrary widlcards are a huge problem. Using scheme can solve this in a more elegant way: principal 'namespace:example' or principal 'k8sprefix:namespace:istiod-' could use the schema to clearly indicate which principal formats can be interpreted as a matcher.

Keep in mind most Istio users are far from authentication experts. You (and probably everyone on this PR) are easily in the 99.999% percentile in that regard -- most people probably don't even know what a principal means in the first place!

Most people don't know 'serviceAccount' means a K8S service account in a new syntax we just invented ( in particular if they use any cloud - where service account can be a vendor service account, or use enterprise SSO/LDAP/etc which has its own service accounts) And I suspect the people who are not security experts are better using 'principal: k8snamespace:example' and not deal with (versioned) service accounts or matchers at all.

I have not seen you address the versioned service accounts - which is IMO one of the biggest issues. Please do not scope creep this... The goal is not to allow *more* functionality, its to make core use cases easier which has been the consistent goal of the project for the last 3 years.

I believe Istiod has used versioned accounts for >3years, and having a separate SA per version ( allowing the RBAC to evolve ) is not 'scope creep' but something we ourselves are doing. We can't pretend versioned service accounts don't exists or users are not allowed to use them ( but we are ). We can make it easier by allowing the user to specify just a namespace - hard to make it easier than that. Message ID: ***@***.***>

…

costinm · 2024-12-17T22:29:02Z

On Tue, Dec 17, 2024 at 12:10 PM John Howard ***@***.***> wrote: To be super clear -- the use case I am trying to solve is this: https://istio.io/latest/blog/2022/get-started-ambient/#l4-authorization-policies . The *vast* majority of policies are of this form, and its such a huge cliff to understanding Istio. Its *the* top motivator for Istio adoption, we have it as literally step 1 in our (and others) getting started walkthroughs, and its 10x more complicated than it needs to be!

100% agree with the use case and goal. My concern is with repeating the same mistake by adding another 'unique' format and more confusion. At the very least call it k8sServiceAccount, not 'serviceAccount' - and use the same scheme that k8s is using in NetworkPolicy. But I fail to see how allowing principal to be a URL is a problem - and adding a new field is better. Message ID: ***@***.***>

…

howardjohn · 2024-12-17T22:43:03Z

We can make it easier by allowing the user to specify just a namespace - hard to make it easier than that.

This is already supported in the API and is a great feature! But often users want to segment further than namespace. I know you personally do not think that is a good idea, but it is the reality of how users use Istio today. I have lost track of the number of users I have seen that have massive namespaces (or even a single namespace!) with desperate apps. Namespace is the best boundary but not the only boundary.

costinm · 2024-12-17T23:24:33Z

I think it is a very good idea to support service accounts - but taking into account that service accounts can be versioned (like we do), that the syntax for representing K8S Service accounts needs to be consistent with K8S - and that not all service accounts are K8S ( and will be very confusing to many users who also use non-K8S service accounts - Istio is still supposed to support more than K8S).

…

On Tue, Dec 17, 2024 at 2:43 PM John Howard ***@***.***> wrote: We can make it easier by allowing the user to specify just a namespace - hard to make it easier than that. This is already supported in the API and is a great feature! But often users want to segment further than namespace. I know you personally do not think that is a good idea, but it is the reality of how users use Istio today. I have lost track of the number of users I have seen that have massive namespaces (or even a single namespace!) with desperate apps. Namespace is the *best* boundary but not the only boundary. — Reply to this email directly, view it on GitHub <#3340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUR2W6F6YHW5BMSTHOPAL2GCSI3AVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZHAYDINZRGE> . You are receiving this because you commented.Message ID: ***@***.***>

costinm · 2024-12-17T23:29:36Z

John - I don't think we disagree on the goals or why this is a good idea, my comments are just about syntax and consistency, i.e. using 'serviceAccount' keyword and namespace/serviceAccount. For the latter - I am ok with it if that's also what K8S is using in NetworkPolicy. Regardless of the presence of serviceAccount ( or k8sServiceAccount as I would suggest ) - I think allowing/supporting proper scheme:// in the principal would be extremely useful, and a k8s:// scheme should be possible.

…

On Tue, Dec 17, 2024 at 3:24 PM Costin Manolache ***@***.***> wrote: I think it is a very good idea to support service accounts - but taking into account that service accounts can be versioned (like we do), that the syntax for representing K8S Service accounts needs to be consistent with K8S - and that not all service accounts are K8S ( and will be very confusing to many users who also use non-K8S service accounts - Istio is still supposed to support more than K8S). On Tue, Dec 17, 2024 at 2:43 PM John Howard ***@***.***> wrote: > We can make it easier by allowing the user to specify just a namespace - > hard to make it easier than that. > > This is already supported in the API and is a great feature! But often > users want to segment further than namespace. I know you personally do not > think that is a good idea, but it is the reality of how users use Istio > today. I have lost track of the number of users I have seen that have > massive namespaces (or even a single namespace!) with desperate apps. > Namespace is the *best* boundary but not the only boundary. > > — > Reply to this email directly, view it on GitHub > <#3340 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAUR2W6F6YHW5BMSTHOPAL2GCSI3AVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZHAYDINZRGE> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

therealmitchconnors · 2024-12-17T23:30:34Z

Istio has operated for as long as I can remember with the mantra that "Easy things should be easy, and hard things should be possible" (shamelessly stolen from Larry Wall). Using a K8s Service Account as a principal should be an easy thing, as it is what is used in all but the most complex Istio environments. Using a DID for principal, related to an arbitrary identity provider, is not something we've heard users ask for, but seems to fall into the category of hard things which should be possible (assuming we can safely handle migrating the field to support scheme, etc.)

With that principle in mind, it seems to me that both Service Account fields and an expanded support for DID principals would be valuable additions to the project, and do not appear to be incompatible with one another. I think it makes sense to merge this PR, and to allow @costinm to write a formal proposal for supporting arbitrary identity providers...

From a UX perspective, I don't think it makes sense to support policies which explicitly set the service account field and the principal field. We can sort of consider the Service Account field to be a structured projection of the principal field. In the case that both are specified, I think we should mark a status.condition to indicate that the policy is invalid.

costinm · 2024-12-17T23:46:40Z

On Tue, Dec 17, 2024 at 3:30 PM Mitch Connors ***@***.***> wrote: Istio has operated for as long as I can remember with the mantra that "Easy things should be easy, and hard things should be possible" (shamelessly stolen from Larry Wall). Using a K8s Service Account as a principal should be an easy thing, as it is what is used in all but the most complex Istio environments. Using a DID for principal, related to an arbitrary identity provider, is not something we've heard users ask for, but seems to fall into the category of hard things which should be possible (assuming we can safely handle migrating the field to support scheme, etc.) With that principle in mind, it seems to me that both Service Account fields and an expanded support for DID principals would be valuable additions to the project, and do not appear to be incompatible with one another. I think it makes sense to merge this PR, and to allow @costinm <https://github.com/costinm> to write a formal proposal for supporting arbitrary identity providers...

I was not actually suggesting we support DID - it was just an example. spiffe:// ( as required by the spiffe specification) - and using a scheme for k8s instead of foo/bar ( or some other way to make it clear it is a k8s account in an Istio specific syntax - not taking over the 'service account' concept). We have the 'easy' part with namespace - I don't think the namespace/serviceaccount is really easy if you consider the best practices (that we follow) of not sharing the same RBAC and service account across versions. Making it easy to do the wrong thing (sharing a SA across multiple versions) is not ideal, even if it is common.

From a UX perspective, I don't think it makes sense to support policies which explicitly set the service account field and the principal field. We can sort of consider the Service Account field to be a structured projection of the principal field. In the case that both are specified, I think we should mark a status.condition to indicate that the policy is invalid.

Not sure - it's an 'OR', a service may accept both 'easy' clients in other namespaces, service accounts - and some common non-Istio certificates ( in spiffe: or dns: or email: format) BTW - are we still agreeing that 'least privilege' and not having a shared account ( like we had in the old Istio) for all versions/revisions is the best practice ?

…

Message ID: ***@***.***>

nmnellis · 2024-12-18T15:43:57Z

I think we are missing the point of this feature and the end user it serves. 95% of Istio users just want to enable Service A to talk to Service B and that is all they know. Being able to express that intent easily helps prevent these users from making mistakes and having to learn about the identity system Istio uses. <namespace>/<service> is simple enough for all users to understand but making it some text based format like principal 'k8sprefix:namespace:istiod-' would not serve these users any better than today.

This feature request was in response to a NEW Istio end user trying it and getting frustrated trying to understand the complicated nature of Spiffe. This user ended up in a situation where a messed up AuthorizationPolicy took 2 weeks to find.

@costinm If we call it k8sServiceAccount would that be sufficient in moving forward?

costinm · 2024-12-18T16:58:24Z

On Wed, Dec 18, 2024, 07:44 Nick ***@***.***> wrote: I think we are missing the point of this feature and the end user it serves. 95% of Istio users just want to enable Service A to talk to Service B and that is all they know. Being able to express that intent easily helps prevent these users from making mistakes and having to learn about the identity system Istio uses. <namespace>/<service> is simple enough for all users to understand but making it some text based format like principal 'k8sprefix:namespace:istiod-' would not serve these users any better than today.

Very interesting point. I wouldn't mind a k8sService: scheme - it doesn't have the problem with versioned accounts and indeed matches what people understand. Keep in mind Service A may use multiple service accounts ( like Istio) and a service account can be shared by multiple services. Miss one - either breakage or security issue Namespace/service would be easy to understand if that was the syntax used by k8s - but it is not, k8s is using service.namespace For service accounts - it is using the system:... - in the JWTs we use to get the cert. This feature request was in response to a NEW Istio end user trying it and

getting frustrated trying to understand the complicated nature of Spiffe. This user ended up in a situation where a messed up AuthorizationPolicy took 2 weeks to find. @costinm <https://github.com/costinm> If we call it k8sServiceAccount would that be sufficient in moving forward?

I can live with that - if we can confirm the namespace/ksa scheme is what NetworkPolicy will adopt, or if we use a scheme that is in use with k8s. It still has the problem of versioned service account - I would much rather have what you suggested in this comment, k8sService - which is also the typical user intent and solves both versioned accounts and shared accounts. But it's not as bad as what we have. —

…

Reply to this email directly, view it on GitHub <#3340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUR2QAJX73FRBGW2CRLXD2GGJ5HAVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGY2TMNJSGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

costinm · 2024-12-18T17:02:04Z

BTW - to add on the idea in Nick's email - "Service A talk to Service B" is what we use for the client to server authentication ( 'secure naming' ) - so it would make the security symmetrical and easier to understand. At the same time - it has its own problems ( the set of identities associated with service changes - in particular with versioned accounts ). But as a concept it is easiest to understand by a user.

…

On Wed, Dec 18, 2024 at 8:58 AM Costin Manolache ***@***.***> wrote: On Wed, Dec 18, 2024, 07:44 Nick ***@***.***> wrote: > I think we are missing the point of this feature and the end user it > serves. 95% of Istio users just want to enable Service A to talk to Service > B and that is all they know. Being able to express that intent easily helps > prevent these users from making mistakes and having to learn about the > identity system Istio uses. <namespace>/<service> is simple enough for > all users to understand but making it some text based format like principal > 'k8sprefix:namespace:istiod-' would not serve these users any better > than today. > Very interesting point. I wouldn't mind a k8sService: scheme - it doesn't have the problem with versioned accounts and indeed matches what people understand. Keep in mind Service A may use multiple service accounts ( like Istio) and a service account can be shared by multiple services. Miss one - either breakage or security issue Namespace/service would be easy to understand if that was the syntax used by k8s - but it is not, k8s is using service.namespace For service accounts - it is using the system:... - in the JWTs we use to get the cert. This feature request was in response to a NEW Istio end user trying it and > getting frustrated trying to understand the complicated nature of Spiffe. > This user ended up in a situation where a messed up AuthorizationPolicy > took 2 weeks to find. > > @costinm <https://github.com/costinm> If we call it k8sServiceAccount > would that be sufficient in moving forward? > I can live with that - if we can confirm the namespace/ksa scheme is what NetworkPolicy will adopt, or if we use a scheme that is in use with k8s. It still has the problem of versioned service account - I would much rather have what you suggested in this comment, k8sService - which is also the typical user intent and solves both versioned accounts and shared accounts. But it's not as bad as what we have. — > Reply to this email directly, view it on GitHub > <#3340 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAUR2QAJX73FRBGW2CRLXD2GGJ5HAVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGY2TMNJSGY> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

linsun

Based on the discussion in today's upstream WG mtg, this PR does help users to simplify authz policies from the required principal today to k8s service account. Regarding Costin's concern about cloud provider also has service account concept, the general consensus is to clarify in the comment that the service account means k8s service account here and not asking users to use k8s as part of the serviceAccounts field.

/lgtm

/hold

adding hold so John can remove after he clarified that in the comment.

howardjohn requested a review from a team as a code owner October 18, 2024 20:24

howardjohn added the release-notes-none Indicates a PR that does not require release notes. label Oct 18, 2024

istio-testing added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Oct 18, 2024

hzxuzhonghu reviewed Oct 21, 2024

View reviewed changes

ilrudie reviewed Oct 22, 2024

View reviewed changes

bleggett reviewed Oct 23, 2024

View reviewed changes

security/v1beta1/authorization_policy.proto Outdated Show resolved Hide resolved

bleggett approved these changes Oct 24, 2024

View reviewed changes

istio-testing added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Oct 28, 2024

hzxuzhonghu reviewed Oct 29, 2024

View reviewed changes

security/v1beta1/authorization_policy.proto Show resolved Hide resolved

hzxuzhonghu approved these changes Oct 31, 2024

View reviewed changes

howardjohn assigned howardjohn and louiscryan and unassigned howardjohn Nov 5, 2024

howardjohn mentioned this pull request Nov 27, 2024

Implement serviceAccounts matcher for authz policy istio/istio#54091

Merged

linsun reviewed Dec 2, 2024

View reviewed changes

istio-testing added the needs-rebase Indicates a PR needs to be rebased before being merged label Dec 17, 2024

howardjohn added 3 commits December 17, 2024 06:26

Tests and validation

5b79025

add doc

b55e0db

howardjohn force-pushed the api/add-sa-authz branch from 6dd0b03 to b55e0db Compare December 17, 2024 14:27

istio-testing removed the needs-rebase Indicates a PR needs to be rebased before being merged label Dec 17, 2024

howardjohn requested a review from louiscryan December 17, 2024 15:09

costinm reviewed Dec 17, 2024

View reviewed changes

linsun approved these changes Dec 18, 2024

View reviewed changes

linsun added the do-not-merge/hold Block automatic merging of a PR. label Dec 18, 2024

Clarify comment that this is a KSA

2390edd

howardjohn removed the do-not-merge/hold Block automatic merging of a PR. label Dec 18, 2024

istio-testing merged commit 27d505c into istio:master Dec 18, 2024
5 checks passed

howardjohn mentioned this pull request Jan 8, 2025

authorization: implement new serviceAccounts field istio/ztunnel#1402

Merged

bleggett mentioned this pull request Jan 29, 2025

Support for sidecar-less service meshes spiffe/spiffe#313

Open

	// Usage of `serviceAccounts` is typically simpler and offers the same functionality.
	// Usage of `serviceAccounts` is typically simpler and offers similar functionality. For complex scenarios principals are still fully supported.

	// If not set, any service account is allowed.
	// If not set, any service account is allowed.
	// if both principal and this field are set, this field has precedence

AuthorizationPolicy: add serviceAccounts field #3340

AuthorizationPolicy: add serviceAccounts field #3340

Conversation

howardjohn commented Oct 18, 2024

hzxuzhonghu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleggett Oct 23, 2024 • edited Loading

Choose a reason for hiding this comment

ilrudie left a comment

Choose a reason for hiding this comment

ilrudie commented Oct 22, 2024

howardjohn commented Oct 22, 2024

bleggett commented Oct 23, 2024 • edited Loading

bleggett Oct 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleggett Oct 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleggett Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

bleggett Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleggett Dec 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleggett left a comment • edited Loading

Choose a reason for hiding this comment

howardjohn commented Oct 28, 2024

bleggett commented Oct 28, 2024 • edited Loading

hzxuzhonghu left a comment

Choose a reason for hiding this comment

linsun left a comment

Choose a reason for hiding this comment

howardjohn commented Dec 2, 2024

linsun commented Dec 9, 2024

costinm left a comment

Choose a reason for hiding this comment

howardjohn commented Dec 17, 2024

costinm commented Dec 17, 2024 via email

costinm commented Dec 17, 2024 via email

bleggett commented Dec 17, 2024 • edited Loading

howardjohn commented Dec 17, 2024

howardjohn commented Dec 17, 2024

costinm commented Dec 17, 2024 via email

costinm commented Dec 17, 2024 via email

howardjohn commented Dec 17, 2024

costinm commented Dec 17, 2024 via email

costinm commented Dec 17, 2024 via email

therealmitchconnors commented Dec 17, 2024

costinm commented Dec 17, 2024 via email

nmnellis commented Dec 18, 2024

costinm commented Dec 18, 2024 via email

costinm commented Dec 18, 2024 via email

linsun left a comment • edited Loading

Choose a reason for hiding this comment

AuthorizationPolicy: add `serviceAccounts` field #3340

AuthorizationPolicy: add `serviceAccounts` field #3340

bleggett Oct 23, 2024 •

edited

Loading

bleggett commented Oct 23, 2024 •

edited

Loading

bleggett Oct 23, 2024 •

edited

Loading

bleggett Oct 23, 2024 •

edited

Loading

bleggett Oct 24, 2024 •

edited

Loading

bleggett Oct 24, 2024 •

edited

Loading

bleggett Dec 2, 2024 •

edited

Loading

bleggett left a comment •

edited

Loading

bleggett commented Oct 28, 2024 •

edited

Loading

bleggett commented Dec 17, 2024 •

edited

Loading

linsun left a comment •

edited

Loading