Role-Based Access Control (RBAC)

Role & ClusterRole

Roles/ClusterRoles are an essential resource for the Authorisation story of Application Manager. Roles/ClusterRoles define a set of rules which describe the resources that you can interact with in Application Manager, and the operations you can perform on them.

Roles are a Namespaced resource, whereas ClusterRoles are a top level resource and thus are independent of Namespacing. The distinction being that Roles can only be used in the Namespace in which they are targeting. Whereas ClusterRoles can be used in any Namespace they are bound, making them suitable for creating default policies to bootstrap access to the cluster. They can later be bound in the respective Namespace. Or in the case of a ClusterRoleBinding, across Namespaces.

Permission Rules

Each Role/ClusterRole contains rules which represent a set of permissions granting access to operations on resources. Permissions are strictly additive; It is not possible to deny access. Rules refer to resources by a string representation of their name as used in the REST API URL and to operations by their respective HTTP verbs.

Verbs

  • GET: Permits to retrieve a single resource or a list of resources.
  • POST: Permits to create a new resource.
  • PATCH: Permits to change an existing resource.
  • DELETE: Permits to delete a resource.
  • *: Permits any operation.

Resources

  • api-tokens
  • cluster-roles
  • cluster-role-bindings
  • deployments
  • deployment-targets
  • events
  • jobs
  • namespaces
  • roles
  • role-bindings
  • savepoints
  • secret-values
  • status: Permits access to the status REST API endpoint returning information about the running Application Manager instance. Note that access to status is required by the Application Manager Web User Interface and always has to be granted in addition to web-ui. Supports only GET operations.
  • web-ui: Permits access to the Web User Interfaces of the Application Manager, Swagger, Flink and Grafana and Kibana if installed. Supports only GET operations.
  • *: Permits access to any resource.

Examples

The following are examples of a Role and a ClusterRole that are created automatically on the first run of Application Manager. They are granting full access to the Application Manager Web User Interface and the resources accessible from it in the default namespace.

kind: Role
apiVersion: v1
metadata:
  id: 040dad5d-0955-4e71-9030-4349220caddd
  name: bootstrap-default
  namespace: default
  createdAt: 2018-09-06T09:49:05.269Z
  modifiedAt: 2018-09-06T09:49:05.269Z
  labels:
    generatedBy: system
  resourceVersion: 1
spec:
  rules:
  - resources:
    - deployments
    - events
    - jobs
    - savepoints
    - secret-values
    verbs:
    - '*'
kind: ClusterRole
apiVersion: v1
metadata:
  id: 8512d79d-3a3e-4114-8e04-5037cb24fca4
  name: bootstrap-default
  createdAt: 2018-09-06T09:49:05.267Z
  modifiedAt: 2018-09-06T09:49:05.267Z
  labels:
    generatedBy: system
  resourceVersion: 1
spec:
  rules:
  - resources:
    - deployment-targets
    - web-ui
    - status
    verbs:
    - '*'

Note

Currently, there are no privilege escalation checks performed when a user creates or updates a Role or ClusterRole. This means that a user that can modify these resources, can grant herself more permissions than she currently holds. Therefore, make sure to only grant permissions to modify Role or ClusterRole resources to trusted users.

RoleBinding & ClusterRoleBinding

A RoleBinding grants the permissions in a Role or ClusterRole to a set of subjects. RoleBindings are bound to a Namespace whereas ClusterRoleBindings apply to every Namespace and resources not bound to a Namespace. RoleBindings may reference Roles and ClusterRoles, while ClusterRoleBindings are restricted to ClusterRoles.

Subjects

Each RoleBinding and ClusterRoleBinding defines as set of subject to grant permission in a Role or ClusterRole.

User

A user may be referenced by the username as provided from the configured authentication provider. When using OpenID Connect the default is to users E-Mail.

kind: USER
name: user@example.com

Group

If the authentication provider supports groups, a group may be referenced by its name.

Besides authenticated users are being assigned to the system:authenticated group, whereas unauthenticated users are assigned to system:unauthenticated.

kind: GROUP
name: system:authenticated

API Token

API Token may be referenced by their name. The name is set on creation of a token and may not be changed.

kind: TOKEN
name: my-token

Examples

The following are examples of a RoleBinding and a ClusterRoleBinding that are created automatically on the first run of Application Manager. They grant authenticated users access to the resources defined in the bootstrap-default roles, which contain full access to the Application Manager Web User Interface and the resources accessible from it in the default namespace.

kind: RoleBinding
apiVersion: v1
metadata:
  id: 0d84673e-a2a0-4fd0-8e8b-153a3068f8dc
  name: bootstrap-default
  namespace: default
  createdAt: 2018-09-06T09:49:05.274Z
  modifiedAt: 2018-09-06T09:49:05.274Z
  labels:
    generatedBy: system
  resourceVersion: 1
spec:
  subjects:
  - kind: GROUP
    name: system:authenticated
  roleRef:
    kind: ROLE
    name: bootstrap-default
kind: ClusterRoleBinding
apiVersion: v1
metadata:
  id: 4b51d0db-b90c-4bc6-8179-6ad19baaf2df
  name: bootstrap-default
  createdAt: 2018-09-06T09:49:05.273Z
  modifiedAt: 2018-09-06T09:49:05.273Z
  labels:
    generatedBy: system
  resourceVersion: 1
spec:
  subjects:
  - kind: GROUP
    name: system:authenticated
  roleRef:
    kind: CLUSTERROLE
    name: bootstrap-default

Note

Currently, there are no privilege escalation checks performed when a user creates or updates a RoleBinding or ClusterRoleBinding. This means that a user that can modify these resources, can grant herself more permissions than she currently holds. Therefore, make sure to only grant permissions to modify RoleBinding or ClusterRoleBinding resources to trusted users.