☰
Navigation :

Gloo Mesh Role-based API

This feature is available in Gloo Mesh Enterprise only.

At a high level, Gloo Mesh manages control planes by translating networking policy configuration (networking.mesh.gloo.solo.io CRD objects) into service-mesh-specific configuration. Each networking policy object targets specified discovered mesh entities (represented by discovery.mesh.gloo.solo.io CRD objects).

Gloo Mesh's role-based API allows organizations to restrict access to policy configuration (i.e. creation, updating, and deletion of policy configuration objects) based on the roles of individual users, represented by a Role CRD. Similar to the Kubernetes RBAC model, Gloo Mesh users are bound to one or more roles. A user may create, update, or delete a networking policy if they are bound to at least one role that permits access for that policy.

Roles

The Role CRD structure allows for fine-grained permission definition. Because Gloo Mesh's networking policies target different discovery entities (some combination of workloads, traffic targets, meshes, and virtual meshes), permissions for each networking policy CRD are represented by separate scopes. A bound user is permitted to configure a policy if and only if all actions (if applicable) and scopes present on the policy are permitted by the role. The semantics for whether actions or scopes are permitted are described below.

Scopes

Permission scopes are defined against networking policy selectors. These selectors, in the context of networking policies, control the mesh entities that are affected by the policy. Each networking policy CRD has a different combination of selectors depending on which mesh entities it can affect. We detail the different scopes and their associated selectors below.

TrafficPolicyScope: TrafficPolicies operate on routes between workloads and traffic targets. Thus, the TrafficPolicyScope defines the set of permitted WorkloadSelectors and TrafficTargetSelectors. In other words, a TrafficPolicyScope represents permission for creating TrafficPolicies that configure a specific set of workloads and associated traffic targets.

AccessPolicyScope: AccessPolicies operate on routes between identities (which represent a set of workloads) and traffic targets. Thus, the AccessPolicyScope defines the set of permitted IdentitySelectors and TrafficTargetSelectors. In other words, an AccessPolicyScope represents permission for creating AccessPolicies that configure a specific set of identities and associated traffic targets.

VirtualMeshScope: VirtualMeshes operate on discovered meshes. Thus, the VirtualMeshScope defines the set of permitted meshes by reference (name and namespace of the corresponding Mesh object). In other words, a VirtualMeshScope represents permission for creating VirtualMeshes that group a set of discovered meshes.

FailoverServiceScope: FailoverServices operate on discovered meshes and traffic targets. Thus, the FailoverServiceScope defines the set of permitted meshes by reference (name and namespace of the corresponding Mesh object) and backing traffic targets. In other words, a FailoverServiceScope represents permission for creating FailoverServices that creates a failover service visible on a specified set of meshes, consisting of a set of backing traffic targets.

Scope Action Semantics

The set of actions defined on a scope (if applicable to the policy type) describes the set of actions bound users are permitted to configure. Actions are enums which map onto the correspondingly named policy field (i.e. for TrafficPolicyScope, TRAFFIC_SHIFT maps onto the traffic_shift field).

Scope Selector Semantics:

The set of selectors (WorkloadSelector, TrafficTargetSelector, or IdentitySelector) defined on a scope describes, verbatim, the selectors that the bound users are permitted to use, with the important exception of omitted fields. Omitted/empty selector fields carry wildcard semantics, allowing any value for that field.

The following TrafficTargetSelector allows only the verbatim list of selectors:

trafficTargetSelectors:
- kubeServiceMatcher:
    name: foobar
    namespace: foobar-namespace
    clusters:
    - remote-cluster

However, if we modify the selector to the following:

trafficTargetSelectors:
- kubeServiceMatcher:
    namespace: foobar-namespace
    clusters:
      - remote-cluster

It permits TrafficTargetSelectors to select any specific name or to omit the name altogether. The following TrafficTargetSelectors would be permitted for a TrafficPolicy:

destinationSelector:
- kubeServiceMatcher:
    name: foobar
    namespace: foobar-namespace
    clusters:
    - remote-cluster
  kubeServiceMatcher:
    namespace: foobar-namespace
    clusters:
    - remote-cluster

Example Roles / Personas

The following examples demonstrate common personas one might encounter in organizations and how they can be represented using Gloo Mesh Roles.

System Administrator

System administrators are responsible for operating and maintaining infrastructure across the entirety of an organization. They require the broadest possible permission set.

apiVersion: rbac.enterprise.mesh.gloo.solo.io/v1alpha1
kind: Role
metadata:
  name: admin-role
  namespace: gloo-mesh
spec:
  trafficPolicyScopes:
    - trafficPolicyActions:
        - ALL
      trafficTargetSelectors:
        - kubeServiceMatcher:
            labels:
              "*": "*"
            namespaces:
              - "*"
            clusters:
              - "*"
        - kubeServiceRefs:
            services:
              - name: "*"
                namespace: "*"
                clusterName: "*"
      workloadSelectors:
        - labels:
            "*": "*"
          namespaces:
            - "*"
          clusters:
            - "*"
  virtualMeshScopes:
    - virtualMeshActions:
        - ALL
      meshRefs:
        - name: "*"
          namespace: "*"
  accessPolicyScopes:
    - identitySelectors:
        - kubeIdentityMatcher:
            namespaces:
              - "*"
            clusters:
              - "*"
          kubeServiceAccountRefs:
            serviceAccounts:
              - name: "*"
                namespace: "*"
                clusterName: "*"
    - trafficTargetSelectors:
        - kubeServiceMatcher:
            labels:
              "*": "*"
            namespaces:
              - "*"
            clusters:
              - "*"
        - kubeServiceRefs:
            services:
              - name: "*"
                namespace: "*"
                clusterName: "*"
  failoverServiceScopes:
    - meshRefs:
        - name: "*"
          namespace: "*"
      backingServices:
        - kubeService:
            name: "*"
            namespace: "*"
            clusterName: "*"

This role allows complete access for configuring any aspect of any service mesh entity.

Mesh Owner

Mesh owners are administrators responsible for operating and maintaining a service mesh instance. They require complete permissions for a set of specified service meshes.

apiVersion: rbac.enterprise.mesh.gloo.solo.io/v1alpha1
kind: Role
metadata:
  name: mesh-owner-role
  namespace: gloo-mesh
spec:
  trafficPolicyScopes:
    - trafficPolicyActions:
        - ALL
      trafficTargetSelectors:
        - kubeServiceMatcher:
            labels:
              "*": "*"
            namespaces:
              - "*"
            clusters:
              - "mgmt-cluster"
        - kubeServiceRefs:
            services:
              - name: "*"
                namespace: "*"
                clusterName: "mgmt-cluster"
      workloadSelectors:
        - labels:
            "*": "*"
          namespaces:
            - "*"
          clusters:
            - "mgmt-cluster"
  # An empty virtualMeshScopes field means that no virtual mesh actions are allowed
  accessPolicyScopes:
    - identitySelectors:
        - kubeIdentityMatcher:
            namespaces:
              - "*"
            clusters:
              - "mgmt-cluster"
          kubeServiceAccountRefs:
            serviceAccounts:
              - name: "*"
                namespace: "*"
                clusterName: "mgmt-cluster"
    - trafficTargetSelectors:
        - kubeServiceMatcher:
            labels:
              "*": "*"
            namespaces:
              - "*"
            clusters:
              - "mgmt-cluster"
        - kubeServiceRefs:
            services:
              - name: "*"
                namespace: "*"
                clusterName: "mgmt-cluster"
  failoverServiceScopes:
    - meshRefs:
        - name: istiod-istio-system-mgmt-cluster
          namespace: gloo-mesh
      backingServices:
        - kubeService:
            name: "*"
            namespace: "*"
            clusterName: "*"

Assuming that the istiod-istio-system-mgmt-cluster mesh is the only control plane present on the mgmt-cluster cluster, this role allows access for configuring TrafficPolicies and AccessPolicies that affect only traffic targets controlled by the istiod-istio-system-mgmt-cluster mesh, and only FailoverServices that exist on that mesh.

Traffic Target Publisher

Traffic target publishers own and operate traffic targets (also referred to as services or microservices) that may be consumed by other workloads throughout the organization. They require permissions for configuring server-side networking policies for their traffic targets, regardless of the origin of incoming traffic.

apiVersion: rbac.enterprise.mesh.gloo.solo.io/v1alpha1
kind: Role
metadata:
  name: traffic-target-owner-role
  namespace: gloo-mesh
spec:
  trafficPolicyScopes:
    - trafficPolicyActions:
        - ALL
      trafficTargetSelectors:
        # The absence of kubeServiceMatcher disallows selecting traffic targets by kubeServiceMatcher
        - kubeServiceRefs:
            services:
              - name: ratings
                namespace: gloo-mesh
                clusterName: mgmt-cluster
              - name: ratings
                namespace: gloo-mesh
                clusterName: remote-cluster
      workloadSelectors:
        - labels:
            "*": "*"
          namespaces:
            - "*"
          clusters:
            - "*"
  # An empty virtualMeshScopes field means that no virtual mesh actions are allowed
  # An empty failoverServiceScopes field means that no failover services can be applied by this role bearer
  accessPolicyScopes:
    - identitySelectors:
        - kubeServiceAccountRefs:
            serviceAccounts:
              - name: ratings
                namespace: bookinfo
                clusterName: "*"
    - trafficTargetSelectors:
        # The absence of kubeServiceMatcher disallows selecting traffic targets by kubeServiceMatcher
        - kubeServiceRefs:
            services:
              - name: ratings
                namespace: bookinfo
                clusterName: "*"

This role allows configuration of TrafficPolicies and AccessPolicies that affect the ratings traffic target in both the mgmt-cluster and remote-cluster, with no restrictions on actions.

Traffic Target Consumer

Traffic target consumers own and operate workloads that originate requests to a set of traffic targets. They require permissions for configuring client-side networking policies affecting the route between their workload(s) and the relevant traffic targets.

apiVersion: rbac.enterprise.mesh.gloo.solo.io/v1alpha1
kind: Role
metadata:
  name: traffic-target-consumer-role
  namespace: gloo-mesh
spec:
  # A traffic target consumer has the ability to configure policies that affect the network edge between
  # a specific workload and an upstream traffic target.
  trafficPolicyScopes:
    - trafficPolicyActions:
        - RETRIES
        - REQUEST_TIMEOUT
        - FAULT_INJECTION
      trafficTargetSelectors:
        # The absence of kubeServiceMatcher disallows selecting traffic targets by kubeServiceMatcher
        - kubeServiceRefs:
            services:
              - name: ratings
                namespace: bookinfo
                clusterName: "*"
      workloadSelectors:
        - labels:
            app: productpage
            version: v1
          namespaces:
            - bookinfo
          clusters:
            - "*"
  # An empty virtualMeshScopes field means that no virtual mesh actions are allowed
  # An empty failoverServiceScopes field means that no failover services can be applied by this role bearer
  accessPolicyScopes:
    - identitySelectors:
        - kubeServiceAccountRefs:
            serviceAccounts:
              - name: "productpage"
                namespace: "bookinfo"
                clusterName: "*"
    - trafficTargetSelectors:
        # The absence of kubeServiceMatcher disallows selecting traffic targets by kubeServiceMatcher
        - kubeServiceRefs:
            services:
              - name: ratings
                namespace: bookinfo
                clusterName: "*"

This role allows configuration of TrafficPolicies (only request timeouts, retries, and fault injections) and AccessPolicies that affect traffic originating from the productpage workload to the ratings traffic target on both mgmt-cluster and remote-cluster. We assume that the productpage-service-account service account identity applies only to the productpage workload (and no other workloads).

Next Steps

To test drive the Role-based API for yourself, we recommend following our guide on the topic.