GEP: L7 Authorization Policy for Gateways and mesh workloads

[aryan16]

The Gateway API currently lacks a standardized authorization policy, a critical requirement for production deployments, particularly as cloud infrastructure increasingly adopts zero-trust security models where granular access control is essential.

This proposal outlines an L7 Authorization Policy specifically designed for L7 Gateways and L7 workloads within a service mesh, explicitly excluding applicability to L4 Gateways or raw TCP-based workloads such as databases like MongoDB and Redis.

Here is the proposed CRD

const (
	// AllGatewaysinNS applies the policy to all gateways in the same namespace.
	AllGatewaysinNS GatewayApplyTo = "SameNamespace"

	// TargetRefs applies the policy to the specified gateways in the targetRefs.
	TargetRefs GatewayApplyTo = "TargetRefs"
)

const (
	// Allow a request only if it matches the rules. This is the default type.
	Allow AuthzPolicyAction = "ALLOW"

	// Deny a request if it matches any of the rules.
	Deny AuthzPolicyAction = "DENY"

	// Custom action allows an extension to handle the user request if
	// the matching rules evaluate to true.
	Custom AuthzPolicyAction = "CUSTOM"
)

type AuthzPolicySpec struct {
	HTTPRules []AuthPolicyHTTPRule `json:"httpRules,omitempty"`

	Action *AuthzPolicyAction `json:"action,omitempty"`

	// CustomProviders defines the extension providers for authorization policy.
	CustomProviders *AuthzPolicyCustomProviders `json:"customProviders,omitempty"`

	TargetRefs []v1.LocalObjectReference `json:"-"`

	// Mesh identifies the mesh workloads to which the policy is applied.
	Mesh *Mesh `json:"mesh,omitempty"`

	// Gateway identifies the gateways to which the policy is applied.
	Gateway *Gateway `json:"gateway,omitempty"`
}

type AuthPolicyHTTPRule struct {
        // From will have client identities
        From *AuthzPolicyFrom `json:"from,omitempty"`
	
       // To will have path, host, port, headers, method
	To *AuthzPolicyTo `json:"to,omitempty"`

       // any valid conditional CEL expression
	When *string `json:"when,omitempty"`
}


// WorkloadSelector defines the selector for the workloads to which the policy is applied.
type WorkloadSelector struct {
	MatchLabels map[string]string `json:"matchLabels,omitempty"`
}

// Mesh defines the mesh workloads to which the policy is applied.
type Mesh struct {
	
	ApplyTo *MeshApplyTo `json:"applyTo,omitempty"`
	
	Selector *WorkloadSelector `json:"selector,omitempty"`
}

// Gateway defines the gateway workloads to which the policy is applied.
type Gateway struct {
	
	ApplyTo *GatewayApplyTo `json:"applyTo,omitempty"`
	
	TargetRefs []v1alpha2.LocalPolicyTargetReferenceWithSectionName `json:"targetRefs,omitempty"`
}

[aryan16]

@robscott @LiorLieberman

[guicassolato]

Hi @aryan16.

I'm jumping in as one who's also been involved with policies and, authorisation ones in particular.

First and foremost, thanks for this proposal. Auth is a much requested feature, with a non-trivial solution, I recon.

I see in your proposal a clear pointer to GEP-1494, which I'd recommend you checking out in case you haven't already. That GEP lays out some initial use cases for auth. It covers authentication and keeps it open for authorisation as well. Even though it doesn't elaborate much on the API or the implementation yet, I believe it's a good starting point for anything that intends to be standard eventually.

Regarding the API you propose, I see a lot of Istio's AuthorizationPolicy in it. This might work fine for this particular implementation, but not sure if it'd get enough support to become standard in Gateway API IMHO.

The proposed attachment mechanisms also deviates a bit from what we currently have in GEP-713. Things like WorkloadSelector, GatewayApplyTo and AuthPolicyHTTPRule would all probably overlap, to one extend or another, with the already spec'ed targeting options. On a positive note, it feels like you're identifying a need for enhancements to those existing targeting options, which IMO could be good points to discuss in the scope of #2927, and then perhaps some follow-up of #3609.

[aryan16]

Thanks @guicassolato for all the details and the feedback.

Given that authorization and authentication within a service mesh target individual workloads, relying on workload-native APIs makes the most sense. Consequently, traditional attachment points like Kubernetes Services and Routes become less effective, though Routes might still play a role in specific scenarios. The existing trust and adoption of Pod labels for workload identification provide a more aligned and robust approach for defining AuthZ/Authn policies imo.

I agree that this API, particularly its rule structure, bears a resemblance to Istio's AuthorizationPolicy. This similarity stems from the power of Istio's single API to handle diverse conditions, offering a unified and user-friendly approach to authorization. However, a key difference lies in the scope: while Istio's API can become complex when applied to TCP workloads (due to the mixing of L7 and L4 rules), the proposed API's focus solely on L7 simplifies policy management for these scenarios.

And WorkloadSelector, GatewayApplyTo, MeshApplyTo are required to make a clear separation between mesh and gateways which current Gateway API lacks and very confusing for an end user. I can add more details about that.

[youngnick]

Thanks for this proposal @aryan16, but as @guicassolato says, I'd encourage you to read the provisional version of GEP-1494 and recast this in those terms. Also please remember that anything that gets implemented needs to be implementable in dataplanes other than Envoy, so it's important to ensure that we either don't use Envoy-specific constructs, or we define a way to make those Envoy-specific constructs more standard.