Enterprise Kubernetes, delivered

Tectonic ships with CoreOS's signature automated operations, runs multi-cloud, and is the fastest, most secure path to Kubernetes.

User Management through Tectonic Identity

Overview

Tectonic Identity is an authentication service for both Tectonic Console and kubectl and allows these components to talk to the API server on an end user's behalf. All Tectonic clusters also enable roles based access control (RBAC) which uses the user information produced by Identity to enforce permissions.

This document describes managing users and access control in Tectonic.

Identity Configuration

Tectonic Identity pulls all its configuration options from a config file stored in a ConfigMap, which admins can view and edit using kubectl. As a precaution, it's recommended to use the administrative kubeconfig in their downloaded assets.zip when editing Identity's config in case of misconfiguration.

First, backup the existing config using kubectl:

kubectl get configmaps tectonic-identity --namespace=tectonic-system -o yaml > identity-config.yaml.bak

Edit the current ConfigMap with the desired changes:

kubectl edit configmaps tectonic-identity --namespace=tectonic-system

Trigger a rolling update using kubectl. Identity's deployment is intended to be resilient against invalid config files, but admins should verify the new state and restore the ConfigMap backup if Identity enters a crash loop. The following command will cause an update:

kubectl patch deployment tectonic-identity \
    --patch "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}" \
    --namespace tectonic-system

The update's success can then be inspecting by watching the pods in the tectonic-system namespace.

kubectl get pods --namespace=tectonic-system

Add static user

Static users are those defined directly in the Identity ConfigMap. They provide a mechanism for authenticating users without a connection to a backend Identity provider. To add a new static user, update the tectonic-identity ConfigMap with a new staticPasswords entry.

    staticPasswords:
    # All the following fields are required.
    - email: "test1@example.com"
      # Bcrypt hash for string "password"
      hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"
      # username to display. NOT used during login.
      username: "test1"
      # Randomly generated using uuidgen.
      userID: "1d55c7c4-a76d-4d74-a257-31170f2c4845"

A Bcrypt encoded hash of the user's password can be generated using the using the coreos/bcrypt-tool.

To ensure the static user has been added successfully try and login with the new user from the Tectonic console.

Change Password for Static User

To change the password of an exisiting user, generate a bcrypt hash for the new password (using coreos/bcrypt-tool) and plug in this value into the tectonic-identity ConfigMap for the selected user.

    staticPasswords:
    # Existing user entry.
    - email: "test1@example.com"
      # Newly generated Bcrypt hash
      hash: "$2a$10$TcWtvcw0N8.xK8nKdBw80uzYij6cJwuQhtfYnEf/hEC9bRTzlWdIq"
      username: "test1"
      userID: "1d55c7c4-a76d-4d74-a257-31170f2c4845"

After the config changes are applied, the user can login to the console using the new password.

Add ClusterRoleBindings with Role Based Access Control (RBAC)

ClusterRoles grant access to types of objects in any namespace in the cluster. Tectonic comes preloaded with three ClusterRoles:

  1. user
  2. readonly
  3. admin

ClusterRoles are applied to a User, Group or ServiceAccount via a ClusterRoleBinding. A ClusterRoleBinding can be used to grant permissions to users in all namespaces across the entire cluster, where as a RoleBinding is used to grant namespace specific permissions. The following ClusterRoleBinding resource definition adds an exisiting user to the admin role.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: admin-test
# subjects holds references to the objects the role applies to.
subjects:
  # May be "User", "Group" or "ServiceAccount".
  - kind: User
    # Preexisting user's email
    name: test1@example.com
# roleRef contains information about the role being used.
# It can only reference a ClusterRole in the global namespace.
roleRef:
  kind: ClusterRole
  # name of an existing ClusterRole, either "readonly", "user", "admin",
  # or a custom defined role.
  name: admin
  apiVersion: rbac.authorization.k8s.io/v1alpha1

The above ClusterRoleBinding RBAC resource definition can be applied through kubectl.

kubectl create -f admin-test.yaml

The new ClusterRoleBinding can viewed on the Tectonic Console under the Administration tab.

The ClusterRoleBinding can be deleted to revoke users' permissions.

kubectl delete -f admin-test.yaml

For additional details see the Kubernetes RBAC documentation.