sigs.k8s.io/gateway-api@v1.0.0/site-src/concepts/security-model.md (about)

     1  # Security Model
     2  
     3  ## Introduction
     4  Gateway API has been designed to enable granular authorization for each role in
     5  a typical organization.
     6  
     7  ## Resources
     8  Gateway API has 3 primary API resources:
     9  
    10  * **GatewayClass** defines a set of gateways with a common configuration and
    11    behavior.
    12  * **Gateway** requests a point where traffic can be translated to Services
    13    within the cluster.
    14  * **Routes** describe how traffic coming via the Gateway maps to the Services.
    15  
    16  ## Roles and personas
    17  
    18  There are 3 primary roles in Gateway API, as described in [roles and personas]:
    19  
    20  - **Ian** (he/him): Infrastructure Provider
    21  - **Chihiro** (they/them): Cluster Operator
    22  - **Ana** (she/her): Application Developer
    23  
    24  [roles and personas]:/concepts/roles-and-personas
    25  
    26  ### RBAC
    27  
    28  RBAC (role-based access control) is the standard used for Kubernetes
    29  authorization. This allows users to configure who can perform actions on
    30  resources in specific scopes. RBAC can be used to enable each of the roles
    31  defined above. In most cases, it will be desirable to have all resources be
    32  readable by most roles, so instead we'll focus on write access for this model.
    33  
    34  #### Write Permissions for Simple 3 Tier Model
    35  | | GatewayClass | Gateway | Route |
    36  |-|-|-|-|
    37  | Infrastructure Provider | Yes | Yes | Yes |
    38  | Cluster Operators | No | Yes | Yes |
    39  | Application Developers | No | No | Yes |
    40  
    41  #### Write Permissions for Advanced 4 Tier Model
    42  | | GatewayClass | Gateway | Route |
    43  |-|-|-|-|
    44  | Infrastructure Provider | Yes | Yes | Yes |
    45  | Cluster Operators | Sometimes | Yes | Yes |
    46  | Application Admins | No | In Specified Namespaces | In Specified Namespaces |
    47  | Application Developers | No | No | In Specified Namespaces |
    48  
    49  ## Crossing Namespace Boundaries
    50  Gateway API provides new ways to cross namespace boundaries. These
    51  cross-namespace capabilities are quite powerful but need to be used carefully to
    52  avoid accidental exposure. As a rule, every time we allow a namespace boundary
    53  to be crossed, we require a handshake between namespaces. There are 2 different
    54  ways that can occur:
    55  
    56  ### 1. Route Binding
    57  Routes can be connected to Gateways in different namespaces. To accomplish this,
    58  The Gateway owner must explicitly allow Routes to bind from additional
    59  namespaces. This is accomplished by configuring allowedRoutes within a Gateway
    60  listener to look something like this:
    61  
    62  ```yaml
    63  namespaces:
    64    from: Selector
    65    selector:
    66      matchExpressions:
    67      - key: kubernetes.io/metadata.name
    68        operator: In
    69        values:
    70        - foo
    71        - bar
    72  ```
    73  
    74  This will allow routes from the "foo" and "bar" namespaces to attach to this
    75  Gateway listener.
    76  
    77  #### Risks of Other Labels
    78  Although it's possible to use other labels with this selector, it is not quite
    79  as safe. While the `kubernetes.io/metadata.name` label is consistently set on
    80  namespaces to the name of the namespace, other labels do not have the same
    81  guarantee. If you used a custom label such as `env`, anyone that is able to
    82  label namespaces within your cluster would effectively be able to change the set
    83  of namespaces your Gateway supported.
    84  
    85  ### 2. ReferenceGrant
    86  There are some cases where we allow other object references to cross namespace
    87  boundaries. This includes Gateways referencing Secrets and Routes referencing
    88  Backends (usually Services). In these cases, the required handshake is
    89  accomplished with a ReferenceGrant resource. This resource exists within a
    90  target namespace and can be used to allow references from other namespaces.
    91  
    92  For example, the following ReferenceGrant allows references from HTTPRoutes in
    93  the "prod" namespace to Services that are deployed in the same namespace as
    94  the ReferenceGrant.
    95  
    96  ```yaml
    97  {% include 'standard/reference-grant.yaml' %}
    98  ```
    99  
   100  For more information on ReferenceGrant, refer to our [detailed documentation
   101  for this resource](/api-types/referencegrant).
   102  
   103  ## Advanced Concept: Limiting Namespaces Where a GatewayClass Can Be Used
   104  Some infrastructure providers or cluster operators may wish to limit the
   105  namespaces where a GatewayClass can be used. At this point, we do not have a
   106  solution for this built into the API. In lieu of that, we recommend using a
   107  policy agent such as Open Policy Agent and
   108  [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) to enforce these
   109  kinds of policies. For reference, we've created an [example of
   110  configuration](https://github.com/open-policy-agent/gatekeeper-library/pull/24)
   111  that could be used for this.