Access Control

Connect uses Role-Based Access Control (RBAC) to govern who can perform actions on which resources. Policies are enforced server-side.

Principals

A principal is the entity whose access is being controlled. Connect supports two principal types:

• User — identified by the sub (subject) claim in a JWT issued by the configured identity provider.
• Group — identified by a group claim value in the JWT (e.g. a groups array entry).

Workloads are identified internally by their SPIFFE ID but cannot be the subject of a role binding.

Resources

In the RBAC model, resources have a type and an ID. For example, a trust zone has a resource type TrustZone. The ID is the unique ID of the trust zone, e.g. tz-uhuVJIB7anLFUSW609Nbb.

Resources are arranged in a type hierarchy:

graph TD
    System --> Organization
    Organization --> AttestationPolicy[Attestation Policy]
    Organization --> TrustZone[Trust Zone]
    TrustZone --> AttestationPolicyBinding[Attestation Policy Binding]
    TrustZone --> Federation
    TrustZone --> FederatedService[Federated Service]
    TrustZone --> Cluster
    TrustZone --> ExchangePolicy[Exchange Policy]
    TrustZone --> TrustZoneServer[Trust Zone Server]
    Cluster --> Agent
    Cluster --> Workload
    Cluster --> Identity

System is a meta-resource with a single global instance that is an ancestor of all other resources.

Permissions

A permission is expressed as Resource.verb, for example TrustZone.create or Cluster.list. They are assigned to roles and enforced internally by the policy engine.

Roles

A role is a named collection of permissions. Only predefined roles are supported — custom roles cannot be created.

Roles are separated into owner and viewer roles. As a general rule, a <resource-type>-owner role allows read-only access to a <resource-type> resource, and read-write access to its direct child resources. Similarly, a <resource-type>-viewer role allows read-only access to a <resource-type> resource and its direct child resources.

Role	Scope	Description
admin	System	Full read-write access to all resource types (excludes agent registration)
System-owner	System	Read-write access to organizations
System-viewer	System	Read-only access to organizations
Organization-owner	Organization	Read-only access to organizations; Read-write access to trust zones and attestation policies
Organization-viewer	Organization	Read-only access to organizations, trust zones and attestation policies
TrustZone-owner	Trust Zone	Read-only access to trust zones; read-write access to attestation policy bindings, clusters, exchange policies, federations, federated services, and trust zone servers
TrustZone-viewer	Trust Zone	Read-only access to trust zones, attestation policy bindings, clusters, exchange policies, federations, federated services, and trust zone servers
Cluster-owner	Cluster	Read-only access to clusters; read-write access to identities and workloads
Cluster-viewer	Cluster	Read-only access to clusters, identities, and workloads
RoleBinding-owner	System, Organization, Trust Zone, Cluster	Read-write access to role bindings on the target resource
RoleBinding-viewer	System, Organization, Trust Zone, Cluster	Read-only access to role bindings on the target resource

Role Bindings

A role binding associates a principal (user or group) with a role on a specific resource. Permissions are inherited down the resource hierarchy: for example, a TrustZone-owner binding on a trust zone automatically grants cluster management permissions for all clusters within that trust zone. Role bindings can be applied further up the hierarchy: for example a TrustZone-owner role could be bound to an organization, granting permissions on all trust zones in the organization.

A single principal can hold multiple role bindings across different resources.

Role bindings can be applied to the following resources:

• System
• Organization
• Trust Zone
• Cluster

Bootstrap

When a Connect deployment is first initialised, an initial set of role bindings must be configured using the configuration file. These can be used to enable the creation of other role bindings using the API. See the connect.initialRBAC value in the cofide-connect Helm chart. The following example would allow [email protected] to add further role bindings using the API:

connect:
  initialRBAC:
    version: 1
    roleBindings:
      - roleID: RoleBinding-owner
        resourceType: System
        resourceID: global
        user:
          subject: [email protected]