sigs.k8s.io/gateway-api@v1.0.0/site-src/concepts/roles-and-personas.md (about)

     1  # Roles and personas
     2  
     3  ## Introduction
     4  
     5  In the original design of Kubernetes, Ingress and Service resources were based
     6  on a usage model in which the developers who create Services and Ingresses
     7  controlled all aspects of defining and exposing their applications to their
     8  users.
     9  
    10  In practice, though, clusters and their infrastructure tend to be shared,
    11  which the original Ingress model doesn't capture very well. A critical factor
    12  is that when infrastructure is shared, not everyone using the infrastructure
    13  has the same concerns, and to be successful, an infrastructure project needs
    14  to address the needs of all the users.
    15  
    16  This raises a fundamental challenge: how do you provide the flexibility needed
    17  by the users of the infrastructure, while also maintaining control by the
    18  owners of the infrastructure?
    19  
    20  The Gateway API defines several distinct roles, each with an associated
    21  _persona_, as a tool for surfacing and discussing the differing needs of
    22  different users in order to balance usability, flexibility, and control.
    23  Design work within the Gateway API is deliberately cast in terms of these
    24  personas.
    25  
    26  Note that, depending on the environment, a single human may end up taking on
    27  multiple roles, as discussed below.
    28  
    29  ## Roles and Personas
    30  
    31  The Gateway API defines three roles and personas:
    32  
    33  * **Ian**<a name="ian"></a> (he/him) is an _infrastructure provider_,
    34    responsible for the care and feeding of a set of infrastructure that permits
    35    multiple isolated clusters to serve multiple tenants. He is not beholden to
    36    any single tenant; rather, he worries about all of them collectively. Ian
    37    will often work for a cloud provider (AWS, Azure, GCP, ...) or for a PaaS
    38    provider.
    39  
    40  * **Chihiro**<a name="Chihiro"></a> (they/them) is a _cluster operator_,
    41    responsible for managing clusters to ensure that they meet the needs of
    42    their several users. Chihiro will typically be concerned with policies,
    43    network access, application permissions, etc. Again, they are beholden to no
    44    single user of any cluster; rather, they need to make sure that the clusters
    45    serve all users as needed.
    46  
    47  * **Ana**<a name="ana"></a> (she/her) is an _application developer_,
    48    responsible for creating and managing an application running in a cluster.
    49    From the Gateway API's point of view, Ana will need to manage configuration
    50    (e.g. timeouts, request matching/filter) and Service composition (e.g. path
    51    routing to backends). She is in a unique position among the Gateway API
    52    personas, since her focus is on the business needs her application is meant
    53    to serve, _not_ Kubernetes or the Gateway API. In fact, Ana is likely to
    54    view the Gateway API and Kubernetes as pure friction getting in her way to
    55    get things done.
    56  
    57  Depending on the environment, multiple roles can map to the same user:
    58  
    59  - Giving a single user all the above roles replicates the self-service model,
    60    and may actually happen in a small startup running Kubernetes on bare metal.
    61  
    62  - A more typical small startup would use clusters from a cloud provider. In
    63    this situation, Ana and Chihiro may be embodied in the same person, with Ian
    64    being an employee (or automated process!) within the cloud provider.
    65  
    66  - In a much larger organization, we would expect each persona above to be
    67    embodied by a distinct person (most likely working in different groups,
    68    perhaps with little direct contact).
    69  
    70  ## RBAC
    71  
    72  RBAC (role-based access control) is the standard used for Kubernetes
    73  authorization. This allows users to configure who can perform actions on
    74  resources in specific scopes. We anticipate that each persona will map
    75  approximately to a `Role` in the Kubernetes Role-Based Authentication (RBAC)
    76  system and will define resource model responsibility and separation.
    77  
    78  RBAC is discussed further in the [Security Model] description.
    79  
    80  [Security Model]: /concepts/security-model#rbac