Authors: Rahul Anand (email@example.com), Craig Brookes (firstname.lastname@example.org)
Istio offers an AuthorizationPolicy resource which requires it to be applied in the namespace of the workload. This means that all the configuration is completely decoupled from routing logic like hostnames and paths. For managed gateway scenario, users need to either ask cluster operator to apply their policies in the gateway's namespace (which is not scalable) or use sidecars/personal gateway for their workloads in their own namepsace which is not optimal.
The new GatewayAPI defines a standard policy attachment mechanism for hierarchical effect of vendor specific policies. We believe creating a new CRD with concepts from Gateway API that solves use cases of Istio's AuthorizationPolicy plus its limitations as described above.
targetRef from policy attachment concept, following are the goals:
- Application developer should be able to target
HTTPRoute object in their own namespace. This will define authorization policy at the hostname/domain/vHost level.
- Cluster operator should be able to target
Gateway object along with HTTPRoute in the gateway's namespace. This will define policy at the level.
- To reduce context sharing at the gateway and external authorization provider, action type and auth-provider are defaulted to
CUSTOM and authorino respectively.
Following is the proposed new CRD that combines policy attachment concepts with Istio's AuthorizationPolicy:
apiVersion: kuadrant.io/v1beta1 kind: AuthPolicy metadata: name: toystore spec: targetRef: group: # Only takes gateway.networking.k8s.io kind: HTTPRoute | Gateway name: toystore rules: - hosts: ["*.toystore.com"] methods: ["GET", "POST"] paths: ["/admin"] authScheme: # Embedded AuthConfigs hosts: ["admin.toystore.com"] identity: - name: idp-users oidc: endpoint: https://my-idp.com/auth/realm authorization: - name: check-claim json: rules: - selector: auth.identity.group operator: eq value: allowed-users status: conditions: - lastTransitionTime: "2022-06-06T11:03:04Z" message: HTTPRoute/Gateway is protected/Error reason: HTTPRouteProtected/GatewayProtected/Error status: "True" | "False" type: Available observedGeneration: 1
targetRef field is taken from policy attachment's target reference API. It can only target one resource at a time. Fields included inside:
Group is the group of the target resource. Only valid option is
Kind is kind of the target resource. Only valid options are
Name is the name of the target resource.
Namespace is the namespace of the referent. Currently only local objects can be referred so value is ignored.
rules field describe the requests that will be routed to external authorization provider (like authorino). It includes:
hosts: a host is matched over
Host request header or
SNI if TLS is used.
Note: Each rule's host in a route level policy must match at least one hostname regex described in HTTPRoute's
hostnames but Gateway level policies have no such restriction.
targetRef HTTPRoute ◄───────────────────────── AuthPolicy hostnames: ["*.toystore.com"] rules: ┌────────────────────────────┐ Rejected Rule: │- hosts: ["*.carstore.com"] │ Regex mismatch │ methods: ["GET", "DELETE"]│ └────────────────────────────┘ ┌───────────────────────────────┐ Accepted Rule: │- hosts: ["admin.toystore.com"]│ Regex match │ methods: ["POST", "DELETE"] │ └───────────────────────────────┘
paths: a path matches over request path like
methods: a method matches over request method like
Fields in a rule object are ANDed together but inner fields follow OR semantics. For example,
*.toystore.comAND the method is
GET; AND path is
AuthScheme is embedded form of Authorino's AuthConfig. Applying an AuthPolicy resource with AuthScheme defined, would create an AuthConfig in the .
Note: Following the heirarchial constraints,
spec.AuthScheme.Hosts must match at least one
spec.Hosts for AuthPolicy to be validated.
The example AuthPolicy showed above will create the following AuthConfig:
apiVersion: authorino.kuadrant.io/v1beta1 kind: AuthConfig metadata: name: default-toystore-1 spec: hosts: - "admin.toystore.com" identity: - name: idp-users oidc: endpoint: https://my-idp.com/auth/realm authorization: - name: check-claim json: rules: - selector: auth.identity.group operator: eq value: allowed-users
Overall control structure looks like the following between the developer and the kuadrant operator:
- Issue tracking this proposal: https://github.com/Kuadrant/kuadrant-operator/issues/130