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
view raw rbac.yaml hosted with ❤ by GitHub

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
view raw createConfig.sh hosted with ❤ by GitHub