We are bringing the best of Tectonic to Red Hat OpenShift to build the most secure, hybrid Kubernetes application platform.
This guide covers using the Tectonic Console to grant cluster-wide or namespace-specific access for human users. For programmatic access for your software, see Creating Service Accounts.
First, create Roles which define rules of access. Then, associate users with Roles using "Role Bindings".
Role Bindings can be used to associate a single user with a Role, or a group of users with a Role.
Permissions granted an individual user are an aggregate of permissions for all roles assigned the user account, and all permissions granted the roles for all groups to which the user belongs.
Individual users may be part of multiple groups.
User authentication must be enabled before defining user roles. Use Tectonic Identity to integrate with your existing authentication system. For more information, see:
In Tectonic Console, go to Administration > Role Bindings and click Create Binding to open the Create Role Binding page.
Enter a Name for the Role Binding. Meaningful names are easy for others to audit.
If creating a Namespace Role Binding, select the Namespace to which the Role Binding grants access.
Select a Role Name for the binding. The Role must preexist in the Tectonic cluster. Use the Administration > Roles page to define Roles. For more information, see Defining Tectonic user roles.
Select the type of Subject for the Role Binding:
ClusterRoles
grant access to objects in any namespace in the cluster. Tectonic offers four default ClusterRoles
:
For more information on these roles, see Default Roles in Tectonic User-facing Roles in the Kubernetes documentation.
ClusterRoles
are applied to a User
, Group
or ServiceAccount
through a ClusterRoleBinding
. A ClusterRoleBinding
can be used to grant permissions to users in all namespaces across the entire cluster, whereas a RoleBinding
is used to grant namespace specific permissions.
The following ClusterRoleBinding
resource definition grants an existing user the admin role.
First, create a YAML file called admin-test.yaml
with the following content:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: admin-test
subjects: # holds references to the objects the role applies to.
- kind: User # May be "User", "Group" or "ServiceAccount".
name: test1@example.com # Preexisting user's email
roleRef: # contains information about the role being used.
# It can only reference a ClusterRole in the global namespace.
kind: ClusterRole
# name of an existing ClusterRole, either "readonly", "user", "admin",
# or a custom defined role.
name: admin
apiGroup: rbac.authorization.k8s.io
Then, use kubectl to apply the ClusterRoleBinding
RBAC resource definition, and create the account:
$ kubectl create -f admin-test.yaml
clusterrolebinding "admin-test" created
In Tectonic Console, go to Administration > Role Bindings to view the new ClusterRoleBinding
.
The ClusterRoleBinding
may be deleted to revoke users' permissions.
$ kubectl delete -f admin-test.yaml
Changes to a Role or Role Binding will take place immediately. Revoking access to a user may not be fully complete until the user's session token expires. The default expiration time is 24 hours.
For more information see the Kubernetes RBAC documentation.