Security Model¶

Introduction¶

Gateway API has been designed to enable granular authorization for each role in a typical organization.

Resources¶

Gateway API has 3 primary API resources:

GatewayClass defines a set of gateways with a common configuration and behavior.
Gateway requests a point where traffic can be translated to Services within the cluster.
Routes describe how traffic coming via the Gateway maps to the Services.

Roles and personas¶

There are 3 primary roles in Gateway API, as described in roles and personas:

Ian (he/him): Infrastructure Provider
Chihiro (they/them): Cluster Operator
Ana (she/her): Application Developer

RBAC¶

RBAC (role-based access control) is the standard used for Kubernetes authorization. This allows users to configure who can perform actions on resources in specific scopes. RBAC can be used to enable each of the roles defined above. In most cases, it will be desirable to have all resources be readable by most roles, so instead we'll focus on write access for this model.

Write Permissions for Simple 3 Tier Model¶

	GatewayClass	Gateway	Route
Infrastructure Provider	Yes	Yes	Yes
Cluster Operators	No	Yes	Yes
Application Developers	No	No	Yes

Write Permissions for Advanced 4 Tier Model¶

	GatewayClass	Gateway	Route
Infrastructure Provider	Yes	Yes	Yes
Cluster Operators	Sometimes	Yes	Yes
Application Admins	No	In Specified Namespaces	In Specified Namespaces
Application Developers	No	No	In Specified Namespaces

Crossing Namespace Boundaries¶

Gateway API provides new ways to cross namespace boundaries. These cross-namespace capabilities are quite powerful but need to be used carefully to avoid accidental exposure. As a rule, every time we allow a namespace boundary to be crossed, we require a handshake between namespaces. There are 2 different ways that can occur:

1. Route Binding¶

Routes can be connected to Gateways in different namespaces. To accomplish this, The Gateway owner must explicitly allow Routes to bind from additional namespaces. This is accomplished by configuring allowedRoutes within a Gateway listener to look something like this:

namespaces:
  from: Selector
  selector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - foo
      - bar

This will allow routes from the "foo" and "bar" namespaces to attach to this Gateway listener.

Risks of Other Labels¶

Although it's possible to use other labels with this selector, it is not quite as safe. While the kubernetes.io/metadata.name label is consistently set on namespaces to the name of the namespace, other labels do not have the same guarantee. If you used a custom label such as env, anyone that is able to label namespaces within your cluster would effectively be able to change the set of namespaces your Gateway supported.

2. ReferenceGrant¶

There are some cases where we allow other object references to cross namespace boundaries. This includes Gateways referencing Secrets and Routes referencing Backends (usually Services). In these cases, the required handshake is accomplished with a ReferenceGrant resource. This resource exists within a target namespace and can be used to allow references from other namespaces.

For example, the following ReferenceGrant allows references from HTTPRoutes in the "prod" namespace to Services that are deployed in the same namespace as the ReferenceGrant.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-prod-traffic
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: prod
  to:
  - group: ""
    kind: Service

For more information on ReferenceGrant, refer to our detailed documentation for this resource.

Advanced Concept: Limiting Namespaces Where a GatewayClass Can Be Used¶

Some infrastructure providers or cluster operators may wish to limit the namespaces where a GatewayClass can be used. At this point, we do not have a solution for this built into the API. In lieu of that, we recommend using a policy agent such as Open Policy Agent and Gatekeeper to enforce these kinds of policies. For reference, we've created an example of configuration that could be used for this.