gateway-api
gateway-api copied to clipboard
kubernetes-sigs
GEP: Support E/W authorization
What would you like to be added: A new API to support E/W Authorization.
Why this is needed:
East/West (E/W) authorization is a critical part of any service mesh. To ensure GAMMA can be used as a standalone solution by a broad user base, it must include some form of E/W authorization.
Most (if not all) meshes today provide this functionality, some examples:
- Istio - https://istio.io/latest/docs/reference/config/security/authorization-policy/
- Linkerd - https://linkerd.io/2-edge/reference/authorization-policy/
- Kuma - https://docs.konghq.com/mesh/latest/policies/meshtrafficpermission/
I think the most difficult problem here is going to be defining the principals in Gateway API terms. You can't have a standard GAMMA policy referring to principals that aren't also defined in GAMMA. So the most important part here is going to be defining what these authorization policies are actually acting on.
I think the most difficult problem here is going to be defining the principals in Gateway API terms. You can't have a standard GAMMA policy referring to principals that aren't also defined in GAMMA. So the most important part here is going to be defining what these authorization policies are actually acting on.
Agreed. In the past we've talked about tying these to Kubernetes Service Accounts, would that make sense to you?
This feature has been accepted for the v1.4.0 release. Please see this announcement for more details, and for the timing expectations for transitions. Note that if the timeline can not be met, there is a risk that this feature may unfortunately need to be dropped from the release. If you have any questions, concerns, or are in need of support please reach out to the maintainers so we can assist you!
Note: This feature only currently has one reviewer assigned (@robscott) to help ensure things move along smoothly, we recommend you reach out and get a commitment from at least one more reviewer to support the iterations on this feature.
I can be a reviewer for this.
@kflynn and @howardjohn would likely be interested in this as well.
The initial GEP phase for the experimental target for v1.4.0 has ended, and this is now merged as Provisional.
The next step is working on the implementation details and moving this towards Implementable. Note that you don't have to move straight to Implementable with the next PR, and in fact it may be better to do the implementation details in smaller iterative PRs depending on the subject matter.
Make sure to check #3824 for details on the remaining timeline for the GEP phases, and feel free to ping @kubernetes-sigs/gateway-api-maintainers issue if you get blocked or need any support moving this forward. 🖖
Note that we've updated our timeline to change the next transition (the "How?" transition where implementation details are at least ready for review) by 1 week, to be due on July 1st. Please keep in touch with us if you get stuck during this time, and let us know how we can support you! 🖖
Experimental transition pulled from v1.4.0 scope (see https://github.com/kubernetes-sigs/gateway-api/pull/3891#issuecomment-3136069398). Recommending re-submission for v1.5.0.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
