|
| 1 | +--- |
| 2 | +authors: Matt Richerson <matthew.richerson@hpe.com> |
| 3 | +categories: setup |
| 4 | +--- |
| 5 | + |
| 6 | +# RBAC for Users |
| 7 | + |
| 8 | +This document shows how to create a kubeconfig file with RBAC set up to restrict access to view only for resources. |
| 9 | + |
| 10 | +## Overview |
| 11 | + |
| 12 | +RBAC (Role Based Access Control) determines the operations a user or service can perform on a list of Kubernetes resources. RBAC affects everything that interacts with the kube-apiserver (both users and services internal or external to the cluster). More information about RBAC can be found in the Kubernetes [***documentation***](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). |
| 13 | + |
| 14 | +User access to a Kubernetes cluster is defined through a kubeconfig file. This file contains the address of the kube-apiserver as well as the key and certificate for the user. Typically this file is located in `~/.kube/config`. When a kubernetes cluster is created, a config file is generated for the admin that allows unrestricted access to all resources in the cluster. This is the equivalent of `root` on a Linux system. |
| 15 | + |
| 16 | +The goal of this document is to create a new kubeconfig file that allows view only access to Kubernetes resources. This kubeconfig file can be shared between the HPE employees to investigate issues on the system. This involves: |
| 17 | + |
| 18 | +- Generating a new key/cert pair for an "hpe" user |
| 19 | +- Creating a new kubeconfig file |
| 20 | +- Adding RBAC rules for the "hpe" user to allow read access |
| 21 | + |
| 22 | +## Generate a Key and Certificate |
| 23 | + |
| 24 | +The first step is to create a new key and certificate so that HPE employees can authenticate as the "hpe" user. This will likely be done on one of the master nodes. The `openssl` command needs access to the certificate authority file. This is typically located in `/etc/kubernetes/pki`. |
| 25 | + |
| 26 | +```bash |
| 27 | + |
| 28 | +# make a temporary work space |
| 29 | +mkdir /tmp/hpe |
| 30 | +cd /tmp/hpe |
| 31 | + |
| 32 | +# generate a new key |
| 33 | +openssl genrsa -out hpe.key 2048 |
| 34 | + |
| 35 | +# create a certificate signing request for the "hpe" user |
| 36 | +openssl req -new -key hpe.key -out hpe.csr -subj "/CN=hpe" |
| 37 | + |
| 38 | +# generate a certificate using the certificate authority on the k8s cluster. This certificate lasts 500 days |
| 39 | +openssl x509 -req -in hpe.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out hpe.crt -days 500 |
| 40 | + |
| 41 | +``` |
| 42 | + |
| 43 | +## Create a kubeconfig |
| 44 | + |
| 45 | +After the keys have been generated, a new kubeconfig file can be created for the "hpe" user. The admin kubeconfig `/etc/kubernetes/admin.conf` can be used to determine the cluster name kube-apiserver address. |
| 46 | + |
| 47 | +```bash |
| 48 | + |
| 49 | +# create a new kubeconfig with the server information |
| 50 | +kubectl config set-cluster {CLUSTER_NAME} --kubeconfig=/tmp/hpe/hpe.conf --server={SERVER_ADDRESS} --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true |
| 51 | + |
| 52 | +# add the key and cert for the "hpe" user to the config |
| 53 | +kubectl config set-credentials hpe --kubeconfig=/tmp/hpe/hpe.conf --client-certificate=/tmp/hpe/hpe.crt --client-key=/tmp/hpe/hpe.key --embed-certs=true |
| 54 | + |
| 55 | +# add a context |
| 56 | +kubectl config set-context hpe-context --kubeconfig=/tmp/hpe/hpe.conf --cluster={CLUSTER_NAME} --user=hpe |
| 57 | +``` |
| 58 | + |
| 59 | +The kubeconfig file should be placed in a location where HPE employees have read access to it. |
| 60 | + |
| 61 | +## Create ClusterRole and ClusterRoleBinding |
| 62 | + |
| 63 | +The next step is to create ClusterRole and ClusterRoleBinding resources. The ClusterRole provided allows viewing all cluster and namespace scoped resources, but disallows creating, deleting, or modifying any resources. |
| 64 | + |
| 65 | +ClusterRole |
| 66 | +```yaml |
| 67 | +apiVersion: rbac.authorization.k8s.io/v1 |
| 68 | +kind: ClusterRole |
| 69 | +metadata: |
| 70 | + name: hpe-viewer |
| 71 | +rules: |
| 72 | + - apiGroups: [ "*" ] |
| 73 | + resources: [ "*" ] |
| 74 | + verbs: [ get, list ] |
| 75 | +``` |
| 76 | +
|
| 77 | +ClusterRoleBinding |
| 78 | +```yaml |
| 79 | +apiVersion: rbac.authorization.k8s.io/v1 |
| 80 | +kind: ClusterRoleBinding |
| 81 | +metadata: |
| 82 | + name: hpe-viewer |
| 83 | +subjects: |
| 84 | +- kind: User |
| 85 | + name: hpe |
| 86 | + apiGroup: rbac.authorization.k8s.io |
| 87 | +roleRef: |
| 88 | + kind: ClusterRole |
| 89 | + name: hpe-viewer |
| 90 | + apiGroup: rbac.authorization.k8s.io |
| 91 | +``` |
| 92 | +
|
| 93 | +Both of these resources can be created using the `kubectl apply` command. |
| 94 | + |
| 95 | +## Testing |
| 96 | + |
| 97 | +Get, List, Create, Delete, and Modify operations can be tested as the "hpe" user by setting the KUBECONFIG environment variable to use the new kubeconfig file. Get and List should be the only allowed operations. Other operations should fail with a "forbidden" error. |
| 98 | + |
| 99 | +```bash |
| 100 | +export KUBECONFIG=/tmp/hpe/hpe.conf |
| 101 | +``` |
0 commit comments