Role-based access control configurations

Blackbird cluster (powered by Telepresence) allows you to manage permissions for components in a cluster for security purposes using role-based access control (RBAC). RBAC is a security model used to restrict system access based on a user's role within an organization. Instead of assigning permissions directly to individuals, RBAC assigns permissions to roles, and users are then assigned to those roles.

Using this page, you can learn about:

• Editing your kubeconfig file
• Administrative access configurations
• Cluster-wide access configurations
• Namespace access configurations

Note: This page uses service accounts to assign roles and bindings, but there are other methods of RBAC administration and enforcement available. For more information, see Using RBAC Authorization in the Kubernetes documentation.

Prerequisites

• You have a version of Kubernetes that's 1.16 or higher.
• You have cluster administration permissions to apply RBAC.
• You're using a kubeconfig file that's specified by the KUBECONFIG environment variable.

Editing your kubeconfig file

Your kubeconfig file is a YAML file that contains the cluster's API endpoint information and the user data that's supplied for authentication. In the example below, the service account name is tp-user. You can replace this name with any value, as long as references to the service account are consistent throughout the YAML file. After an administrator has applied the RBAC configuration, the user needs to create a config.yaml in their current directory. Use the following example as a template.

The cluster administrator can obtain the service account token after they create the user's service account. Creating the service account will create an associated Secret in the same namespace with the format <service-account-name>-token-<uuid>. Your cluster administrator can obtain this token by running kubectl get secret -n ambassador <service-account-secret-name> -o jsonpath='{.data.token}' | base64 -d.

After the user creates a config.yaml in their current directory, they can export the file's location to KUBECONFIG by running export KUBECONFIG=$(pwd)/config.yaml. Then, they can switch to this context by running kubectl config use-context my-context.

Administrative access configurations

Administrating Blackbird clusters (powered by Telepresence) requires permissions for creating Namespaces, ServiceAccounts, ClusterRoles, ClusterRoleBindings, Secrets, Services, and MutatingWebhookConfiguration, along with the ability to deploy the traffic-manager, which is typically done by a full cluster administrator. The following permissions are required for administration.

Cluster-wide user access

Administrators can allow a user to make intercepts across all namespaces with more limited kubectl permissions using the following ServiceAccount, ClusterRole, and ClusterRoleBinding RBAC configurations. This provides full blackbird cluster intercept functionality.

Note: To use the following RBAC configurations, you must have a Traffic Manager deployment set up by an administrator.

Traffic Manager connect permissions

Along with cluster-wide permissions, the client must have the following namespace-scoped permissions in the Traffic Manager's namespace to set up the necessary port forward.

Namespace access configurations

Administrators can also implement RBAC configurations for multi-tenant environments where multiple development teams share a single cluster, with users restricted to a specific namespace.

Note: To use the following RBAC configurations, you must have a Traffic Manager deployment set up by an administrator and Traffic Manager connect permissions.

For each accessible namespace: