Role-based Access Control

Kf provides a set of Kubernetes roles that allow multiple teams to share a Kf cluster. This page describes the roles and best practices to follow when using them.

When to use Kf roles

Kf roles allow multiple teams to share a Kubernetes cluster with Kf installed. The roles provide access to individual Kf Spaces.

Use Kf roles to share access to a cluster if the following are true:

  • The cluster is used by trusted teams.
  • Workloads on the cluster share the same assumptions about the level of security provided by the environment.
  • The cluster exists in a Google Cloud project that is tightly controlled.

Kf roles will not:

Kf roles

The following sections describe the Kubernetes RBAC Roles provided by Kf and how they interact with Google Kubernetes Engine (GKE) IAM.

Predefined roles

Kf provides several predefined Kubernetes roles to help you provide access to different subjects that perform different roles. Each predefined role can be bound to a subject within a Kubernetes Namespace managed by a Kf Space.

When a subject is bound to a role within a Kubernetes Namespace, their access is limited to objects that exist in the Namespace that match the grants listed in the role. In Kf, some resources are defined at the cluster scope. Kf watches for changes to subjects in the Namespace and grants additional, limited, roles at the cluster scope.

Role Title Description Scope
space-auditor Space Auditor Allows read-only access to a Space. Space
space-developer Space Developer Allows application developers to deploy and manage applications within a Space. Space
space-manager Space Manager Allows administration and the ability to manage auditors, developers, and managers in a Space. Space
SPACE_NAME-manager Dynamic Space Manager Provides write access to a single Space object, automatically granted to all subjects with the space-manager role within the named Space. Cluster
kf-cluster-reader Cluster Reader Allows read-only access to cluster-scoped Kf objects, automatically granted to all space-auditor, space-developer, and space-manager. Cluster

Information about the policy rules that make up each predefined role can be found in the Kf roles reference documentation.

IAM roles

Kf roles provide access control for objects within a Kubernetes cluster. Subjects must also be granted an IAM role to authenticate to the cluster:

  • Platform administrators should be granted the roles/container.admin IAM role. This will allow them to install, upgrade, and delete Kf as well as create, and delete cluster scoped Kf objects like Spaces or ClusterServiceBrokers.

  • Kf end-users should be granted the roles/container.viewer IAM role. This role will allow them to authenticate to a cluster with limited permissions that can be expanded using Kf roles.

IAM offers additional predefined Roles for GKE to solve more advanced use cases:

Role Title Description Lowest resource
roles/container.admin Kubernetes Engine Admin

Provides access to full management of clusters and their Kubernetes API objects.

To set a service account on nodes, you must also have the Service Account User role (roles/iam.serviceAccountUser) on the user-managed service account that your nodes will use.

  • Project
roles/container.clusterAdmin Kubernetes Engine Cluster Admin

Provides access to management of clusters.

To set a service account on nodes, you must also have the Service Account User role (roles/iam.serviceAccountUser) on the user-managed service account that your nodes will use.

  • Project
roles/container.clusterViewer Kubernetes Engine Cluster Viewer

Provides access to get and list GKE clusters.

roles/container.developer Kubernetes Engine Developer

Provides access to Kubernetes API objects inside clusters.

  • Project
roles/container.hostServiceAgentUser Kubernetes Engine Host Service Agent User

Allows the Kubernetes Engine service account in the host project to configure shared network resources for cluster management. Also gives access to inspect the firewall rules in the host project.

roles/container.viewer Kubernetes Engine Viewer

Provides read-only access to resources within GKE clusters, such as nodes, pods, and GKE API objects.

  • Project

Mapping Cloud Foundry roles to Kf

Cloud Foundry provides roles are similar to Kf's predefined roles. Cloud Foundry has two major types of roles:

  • Roles assigned by the User Account and Authentication (UAA) subsystem that provide coarse-grained OAuth scopes applicable to all Cloud Foundry API endpoints.
  • Roles granted within the Cloud Controller API (CAPI) that provide fine-grained access to API resources.

UAA roles

Roles provided by UAA are most similar to project scoped IAM roles:

  • Admin users in Cloud Foundry can perform administrative activities for all Cloud Foundry organizations and spaces. The role is most similar to the roles/container.admin IAM role.
  • Admin read-only users in Cloud Foundry can access all Cloud Foundry API endpoints. The role is most similar to the roles/container.admin IAM role.
  • Global auditor users in Cloud Foundry have read access to all Cloud Foundry API endpoints except for secrets. There is no equivalent IAM role, but you can create a custom role with similar permissions.

Cloud Controller API roles

Roles provided by CAPI are most similar to Kf roles granted within a cluster to subjects that have the roles/container.viewer IAM role on the owning project:

  • Space auditors in Cloud Foundry have read-access to resources in a CF space. The role is most similar to the space-auditor Kf role.
  • Space developers in Cloud Foundry have the ability to deploy and manage applications in a CF space. The role is most similar to the space-developer Kf role.
  • Space managers in Cloud Foundry can modify settings for the CF space and assign users to roles. The role is most similar to the space-manager Kf role.

What's next