Role-Based Access Control

There are three types of users with different levels of access to the Kubernetes cluster(s) and the Kubernetes APIs which they can use.

The three types of users are:

  • Kubernetes administrator — Has full access to the cluster(s) to perform any action.
  • Kubernetes user — Has limited access to the cluster(s) to perform restricted actions.
  • Non-Kubernetes user — Has no need (and therefore, no permission) to access the cluster(s) directly or perform any action.

An administrator can give other users limited access to the cluster(s). This can be configured using methods such as role-based access control (RBAC). One example is read-only access, where these other users are prevented from creating resources, deleting resources, or running commands directly on pods.

Another example is that the user responsible for Helm deployments is not an administrator, and should only be given the minimal permissions to perform Helm installations and upgrades. For more information, see the discussion about required Helm role access permissions.

RBAC role creation can be enabled or disabled for the following components:

  • CAMEL Gateway
  • MATRIXX Engine
  • ActiveMQ Connector
  • SBA Gateway
  • Network Enabler
  • Pricing Controller

RBAC Configuration Properties describes the properties that control RBAC creation for components.

Table 1. RBAC Configuration Properties
Property Description
sub_chart_name.rbac.createRole When set to true, the role is created for the component. Roles cannot be created more than once per namespace, so you might need to set this property to false if performing multiple installations. The default value is true.
sub_chart_name.rbac.createRoleBinding When set to true, the role binding to the service account is created for the component. The role binding can not be created more than once per service account in the same namespace, so you might need to set this property to false if performing multiple installations. The default value is true.