There are certain times when we don’t want to expose our namespaces resources to everyone in the project. It’s particularly true in a microservices architecture, where you will want to test your app in an isolated environment before releasing it for other teams to use.
You can achieve that level of isolation with Kubernetes using namespaces.
Namespaces are a way to divide cluster resources between multiple users.
In this post, we will create a namespace, and then create a service account that only has access to that particular namespace, using Kubernetes’s Role-Based Access Control (RBAC) system. Then finally, we will export the config needed to access that namespace.
Prerequisites :
A Kubernetes cluster with enough access to create namespaces and service accounts.
STEPS :
Create Namespace :
kubectl create namespace mynamespace
Create Service Account with permissions :
Open a new file. Let’s call it access.yaml
. We’re going to create the user (service account), a role, and attach that role to that user.
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: mynamespace-user
namespace: mynamespace
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: mynamespace-user-full-access
namespace: mynamespace
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: mynamespace-user-view
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: mynamespace-user
namespace: mynamespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: mynamespace-user-full-access
As you can see, in the Role
definition, we add full access to everything in that namespace, including batch types like jobs or cronjobs. As it is a Role
, and not a ClusterRole
, it is going to be applied to a single namespace: mynamespace
. For more details about roles in Kubernetes, check out the official documentation.
Now, let’s create all of this:
kubectl apply -f access.yaml
You should see the three components being created.
Get Secrets :
The first thing we need to do now is to get the name of the service account’s secret. Run the following command and copy the name of the secret.
kubectl describe sa mynamespace-user -n mynamespace
For this tutorial, let’s say that the secret is named mynamespace-user-token-xxxxx
.
We now need to get the service account’s Token and the Certificate Authority. For this, we are going to read them using kubectl
. Now, as Kubernetes secrets are base64 encoded, we’ll also need to decode them.
Here’s how you get the User Token:
kubectl get secret mynamespace-user-token-xxxxx -n mynamespace -o "jsonpath={.data.token}" | base64 -D
And here’s how you get the Certificate:
kubectl get secret mynamespace-user-token-xxxxx -n mynamespace -o "jsonpath={.data['ca\.crt']}"
You might get “%” at the end of both Token and Certificate from above commands, so just remove it before copying and using it in the next step.
Create Kube config :
We now have everything we need. The only thing remaining is creating the Kube config file, with the data we previously gathered:
apiVersion: v1
kind: Config
users:
- name: mynamespace-user
user:
token: <replace this with user token info>
clusters:
- cluster:
certificate-authority-data: <replace this with certificate-authority-data info>
server: <replace this with server info>
name: my-cluster
contexts:
- context:
cluster: my-cluster
user: mynamespace-user
name: mynamespace-user-context
current-context: mynamespace-user-context
To get API server of the cluster you can do kubectl cluster-info
.
Note: Another way to write the Kube config is to use kubectl
directly. See kubectl config command reference.
You can now give this file to the user you wanted to give access to.
REFERENCES :
https://jeremievallee.com/2018/05/28/kubernetes-rbac-namespace-user.html
http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/