istio
AuthorizationPolicy: add `serviceAccounts` field
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.
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.
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'
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 https://github.com/istio/istio/issues/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.
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".
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)
Felt a little odd to have namespace inside the value for serviceAccount while we also have namespace as a separate field under
sourcebut 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
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 (https://github.com/kubernetes-sigs/network-policy-api/pull/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.
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 https://github.com/kubernetes-sigs/network-policy-api/pull/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: @.***>
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/serviceaccountIn 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 https://github.com/kubernetes-sigs/network-policy-api/pull/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/serviceAccountis significantly better thanprincipal: 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: @.***>
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)
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.
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!
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: @.***>
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: @.***>
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.
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 https://github.com/istio/api/pull/3340#issuecomment-2549804711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUR2W6F6YHW5BMSTHOPAL2GCSI3AVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZHAYDINZRGE . You are receiving this because you commented.Message ID: @.***>
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 https://github.com/istio/api/pull/3340#issuecomment-2549804711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUR2W6F6YHW5BMSTHOPAL2GCSI3AVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZHAYDINZRGE . You are receiving this because you commented.Message ID: @.***>
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.
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: @.***>
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?
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.
/ 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 https://github.com/istio/api/pull/3340#issuecomment-2551656526, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUR2QAJX73FRBGW2CRLXD2GGJ5HAVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGY2TMNJSGY . You are receiving this because you were mentioned.Message ID: @.***>
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.
/ 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 https://github.com/istio/api/pull/3340#issuecomment-2551656526, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUR2QAJX73FRBGW2CRLXD2GGJ5HAVCNFSM6AAAAABQGUWP5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGY2TMNJSGY . You are receiving this because you were mentioned.Message ID: @.***>