Role-Based Access Control (“RBAC”) is a mechanism for controlling access to the Kubernetes API, and since its beta in 1.6, many Kubernetes clusters and provisioning strategies have enabled it by default.
By default, any users in a kubernetes environment running Kubernetes have access to all the resources within Kubernetes. Enabling Kubernetes RBAC allows owners of environments to restrict access to the various resources within Kubernetes to specific users in the environment. Kubernetes 1.8 represents a significant milestone for the role-basedaccess control (RBAC) authorizer, which was promoted to GA in this release.
Better support for user objects in kubernetes api is still in the pipeline. Easiest way we can create user right now are service account.
kubectl apply -f rbac.yml
Save following content in rbac.yml and run above command.
apiVersion: v1 | |
kind: Namespace | |
metadata: | |
name: goglides | |
--- | |
apiVersion: v1 | |
kind: ServiceAccount | |
metadata: | |
labels: | |
app: microservice | |
name: goglidescustomsa | |
namespace: goglides | |
--- | |
kind: Role | |
apiVersion: rbac.authorization.k8s.io/v1beta1 | |
metadata: | |
name: goglidedeployerrole | |
namespace: goglides | |
rules: | |
- apiGroups: ["apps"] | |
resources: ["deployments"] | |
verbs: ["get", "list", "watch", "create", "delete", "update", "patch"] | |
- apiGroups: [""] # "" indicates the core API group | |
resources: ["configmaps", "secrets"] | |
verbs: ["get", "list", "watch", "create", "delete", "update", "patch"] | |
- apiGroups: [""] # "" indicates the core API group | |
resources: ["pods"] | |
verbs: ["get", "list", "watch"] | |
--- | |
apiVersion: rbac.authorization.k8s.io/v1beta1 | |
kind: RoleBinding | |
metadata: | |
name: goglidedeployerrole | |
namespace: goglides | |
roleRef: | |
apiGroup: rbac.authorization.k8s.io | |
kind: Role | |
name: goglidedeployerrole | |
subjects: | |
- kind: ServiceAccount | |
name: goglidescustomsa | |
namespace: goglides |
Now create config file using following,
#!/usr/bin/env bash | |
# Service account created using above manifest file | |
serviceaccount=goglidescustomsa | |
namespace=goglides | |
# Get related Secrets for this Service Account | |
secret=$(kubectl get sa $serviceaccount -n $namespace -o json | jq -r .secrets[].name) | |
# Get ca.crt from secret (using OSX base64 with -D flag for decode) | |
kubectl get secret $secret -n $namespace -o json | jq -r '.data["ca.crt"]' | base64 -D > ca.crt | |
# Get service account token from secret | |
user_token=$(kubectl get secret $secret -n $namespace -o json | jq -r '.data["token"]' | base64 -D) | |
# Get information from your kubectl config, this will use current context. Your kubeconfig file may have multiple context. | |
context=`kubectl config current-context` | |
# get cluster name of context | |
name=`kubectl config get-contexts $context | awk '{print $3}' | tail -n 1` | |
# get endpoint of current context | |
endpoint=`kubectl config view -o jsonpath="{.clusters[?(@.name == \"$name\")].cluster.server}"` | |
# Set cluster (run in directory where ca.crt is stored) | |
kubectl config set-cluster $serviceaccount-$context \ | |
--embed-certs=true \ | |
--server=$endpoint \ | |
--certificate-authority=./ca.crt | |
# Set user credentials | |
kubectl config set-credentials $serviceaccount-$context --token=$user_token | |
# Define the combination of user with the cluster | |
kubectl config set-context $serviceaccount-$context \ | |
--cluster=$serviceaccount-$context \ | |
--user=$serviceaccount-$context \ | |
--namespace=$namespace | |
# Switch current-context to $serviceaccount-$context for the user | |
kubectl config use-context $serviceaccount-$context |