-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PeerAuthentication Graduation to v1 #3112
Conversation
Skipping CI for Draft Pull Request. |
Just PA not requestAuthentication or authorizationPolicy? |
Of all the APIs - this is the one we should rather deprecate than move to
v1.
It is rarely used, its original purpose ( to help migrate to 'strict' )
never actually worked, as proven by the vast number of users
who are still on 'permissive' ( which effectively means insecure ).
We have ample data that the API is bad - we know ambient can't really
support it and has a huge cost in
complexity and generated config.
I think the only positive thing about promoting this API to v1 is that it
sends the signal that the istio v1 API surface
is a dead end and not serious - and may motivate users to move to Gateway
API faster...
…On Wed, Mar 6, 2024 at 5:52 PM Zhonghu Xu ***@***.***> wrote:
Just PA not requestAuthentication or authorizationPolicy?
—
Reply to this email directly, view it on GitHub
<#3112 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUR2XCZI62UREU6BK7JBTYW7B55AVCNFSM6AAAAABEJO2EZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBSGE4TINZQGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I think some of the security APIs are already in v1. I am good with this change.
Not sure if this would signal users that. I don't think gateway API has Istio's security API replacement? |
@whitneygriffith could you add a release note? |
On Thu, Mar 7, 2024 at 7:06 AM Lin Sun ***@***.***> wrote:
Just PA not requestAuthentication or authorizationPolicy?
I think some of the security APIs are already in v1.
I am good with this change.
I think the only positive thing about promoting this API to v1 is that it
sends the signal that the istio v1 API surface
is a dead end and not serious - and may motivate users to move to Gateway
API faster...
Not sure if this would signal users that. I don't think gateway API has
Istio's security API replacement?
Security API ( authz and JWT ) are fine as 'vendor extensions' and already
v1. If we find other implementations - they
may become upstream, but the normal criteria is to not add
single-implementation APIs. I'm pretty sure other vendors
have similar APIs - and in time and after a lot of review, a common API
will emerge.
But the chance of another mesh or gateway supporting 'permissive' mode and
Istio ALPN hacks is pretty close to 0,
so this particular API is very unlikely to be used outside Istio ( and
proxyless gRPC, ambient, etc are also pretty
unlikely to support it ).
So far none of the Istio APIs changed from alpha to v1 - we seem to be the
only project in the world that
managed to get perfect APIs from start without any need to use the user
feedback, and with minimal
review and low bar in alpha. Telemetry seems the only API where we at least
tried to do the work
and adjust based on how it is used and what we learned from users - but if
we promote PeerAuthentication
we may as well also promote the alpha telemetry to v1, since it's unlikely
we'll make any changes from beta to v1.
I'm very curious how the process will work for the new 'experimental' vs
'stable' track - if PeerAuthentication is promoted
to v1 as-is, what will be the bar there ? Why even bother with 2 tracks if
everything just gets promoted to v1 anyways ?
Message ID: ***@***.***>
… |
At least on the Azure side, we see a decent percentage of use. 10% of users who deploy a VirtualService also deploy a PeerAuthentication, and IMO that's a non-negligible segment/trend of adoption.
Ambient already supports 100% of the PeerAuthentication API surface 😃 |
/test release-notes |
I am not aware of the context around promoting PeerAuthentication to v1beta1, but since it is v1beta1 which users understand to be relatively stable, we do not want to revert its status to experimental. And as we discussed, there is no plans to improve this further especially as the future is still unclear. Keep in mind we can still deprecate v1 APIs with 1 year of advanced notice and a supported upgrade path to a replacement feature.
The release channels strategy is to get to a place where we have two API versions v1alpha1 and v1, and because we have existing v1beta1 APIs, we concluded we can graduate them to v1 as stated here which reflects a semantic change not an increase in stability/refined use case as the effort to do the latter is not worth it at the moment. Moving forward the bar, APIs will only be graduated to v1 based on the existing requirements for Stable features as well as what's being proposed here. |
Yes, all of the other Security APIs are v1. |
That's interesting. Do you know what they set in PeerAuthentication, and if
it is the one in istio-system or per workload ?
There are usages on turning off mTLS, for people who only use
telemetry/routing but rely on the low-level CNI encryption (setting NONE),
and we have (unfortunately) few users setting the mesh default to STRICT.
Both are valid and important uses - but better set in
mesh config or as install option.
Like the tracing API discussion - allowing each namespace owner to pick a
different log format or provider is different
from allowing the mesh admin or operator to configure this.
…On Fri, Mar 8, 2024 at 9:55 AM Keith Mattix II ***@***.***> wrote:
It is rarely used, its original purpose ( to help migrate to 'strict' )
never actually worked, as proven by the vast number of users
who are still on 'permissive' ( which effectively means insecure ).
At least on the Azure side, we see a decent percentage of use. 10% of
users who deploy a VirtualService also deploy a PeerAuthentication, and IMO
that's a non-negligible segment/trend of adoption.
—
Reply to this email directly, view it on GitHub
<#3112 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUR2U5ZZHHZT725HI4TOTYXH3Q5AVCNFSM6AAAAABEJO2EZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGE2TANZZHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Since it is v1beta1 Im fine with promoting. I think we should update the API docs to indicate that the API is also frozen and likely to be replaced in ambient |
LGTM. As have Louis and Lin. That leaves @nrjpoddar @ericvn @therealmitchconnors - PTAL I don't know we need 6/6 signoff, but given the importance of this change would be good to get as much visibility as possible |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this as well. One minor nit in the release notes.
We see our customers frequently set mTLS STRICT in the PeerAuth at the mesh level to ensure all traffic is guaranteed mTLS. I don't see a reason why we can't promote this as it's been stable and used by customers. |
/retest |
e1b2686
to
c396fe7
Compare
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
b758ec6
to
7164c16
Compare
Signed-off-by: whitneygriffith <whitney.griffith16@gmail.com>
Part of 173 |
As discussed in Release Channels RFC, v1beta1 security APIs can be promoted to v1.