PeerAuthentication Graduation to v1

[whitneygriffith]

As discussed in Release Channels RFC, v1beta1 security APIs can be promoted to v1.

[istio-testing]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[hzxuzhonghu]

Just PA not requestAuthentication or authorizationPolicy？

[costinm]

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: ***@***.***>

[linsun]

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?

[linsun]

@whitneygriffith could you add a release note?

[costinm]

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: ***@***.***>

…

[keithmattix]

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.

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.

Ambient already supports 100% of the PeerAuthentication API surface 😃

[whitneygriffith]

/test release-notes

[whitneygriffith]

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.

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.

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 ?

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.

[whitneygriffith]

Just PA not requestAuthentication or authorizationPolicy？

Yes, all of the other Security APIs are v1.

[costinm]

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: ***@***.***>

[louiscryan]

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

[howardjohn]

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

[ericvn]

I'm fine with this as well. One minor nit in the release notes.

[nrjpoddar]

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.

[whitneygriffith]

/retest

[whitneygriffith]

Part of 173