前言

介绍Kubernetes到现在我们都还没提及到Kubernetes cluster是如何去区分不同使用者与其所属全限，但在讲述这些之前我必须先提及一个东西，那就是namespace命名空间。

What is namespace ?

何谓namespace命名空间呢？ 其实我们一直在使用，当我们在不指定namespace的情况下会预设为default namespace。Namespace命名空间提供了抽象群集的概念。我们能根据专案的不同、商业逻辑不同或是其他原由将原本拥有所有实体资源的Kubernetes cluster切分成n个virtual cluster，也就是namespace。

Special namespace

这边我先透过kubectl get ns 来介绍几个较为特殊的namespace

$ kubectl get ns 
NAME                   STATUS   AGE
default                Active   17d
kube-node-lease        Active   17d
kube-public            Active   17d
kube-system            Active   17d
kubernetes-dashboard   Active   15d

• default: 预设的namespace，当你没指定namespace时，都会使用该namespace。
• kube-public: 有点像是全域namespace的概念，存放在这的物件都能被所有使用者读取。
• kube-system: 在Kubernetes中，通常会将系统相关资源放在此namespace。
• kube-node-lease: 在v1.17後才release stable版本的namespace，node-lease 功能让节点使用kube-node-lease namespace 中的Lease 资源，该资源将定期更新。先前用於心跳反馈的控制平面功能的NodeStatus 仅在更改时更新。这减少了在大型集群的控制平面上的负载。

How to use namespace ?

namespace具有以下几个特点:

• namespace name必须独一无二，不能重复。
• 当namespace被删除时，该namespace中的所有物件都会一并被删除。
• 每个namespace中的可用资源都是可以透过Resource Quotas限制。

Create namespace

kubectl create namespace <namespace_name>

$ kubectl create namespace newspace
namespace/newspace created

Check objects in specific namespace

kubectl command -n

$ kubectl get pod -n newspace
No resources found in newspace namespace.

Delete namespace

kubectl delete namespace <namespace_name>

$ kubectl delete namespace newspace
namespace "newspace" deleted

Resource quotas with namespace

newspace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: newspace
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: newspace-quotas-1
  namespace: newspace
spec:
  hard:
    requests.cpu: "1"
    limits.cpu: "1"
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: newspace-quotas-2
  namespace: newspace
spec:
  hard:
    services: "3"
    secrets: "3"
    configmaps: "3"
    replicationcontrollers: "10"

Here is an example set of resources users may want to put under object count quota:

• count/persistentvolumeclaims
• count/services
• count/secrets
• count/configmaps
• count/replicationcontrollers
• count/deployments.apps
• count/replicasets.apps
• count/statefulsets.apps
• count/jobs.batch
• count/cronjobs.batch
• count/deployments.extensions

若想知道更多关於resource quotas的话，请参阅https://kubernetes.io/docs/concepts/policy/resource-quotas/

What is Rbac ?

说完namespace後，我们就来谈论Kubernetes去如何做到权限划分的。
Kubernetes在1.8之後正式引入rbac，rbac全名为Role-Base Access Control 基於角色的访问控制，它也是种管制访问Kubernetes API的机制，管理员可以透过rbac.authorization.k8s.io 对授权进行动态的调配与设定。

也就是说Kubernetes的所有资源对象都是模组化後的API对象，允许执行CRUD，也就是以下资源:

• Pod
• ReplicaSet
• Deployment
• Service
• ConfigMap
• Secret

...等

而Rbac就是去限制使用者对於这些物件访问的授权调配。

那接下来就要介绍Rbac的几位小老弟 Role, ClusterRole, RoleBinding, ClusterRoleBinding与serviceAccount

Architecture in Rbac

在rbac当中，我们透过ClusterRoleBinding、RoleBinding去绑定不同的ClusterRole、Role与ServiceAccount去限制每个Account所能在指定namespace下对物件进行的操作。

What is Role ?

Role是用来定义在某个namespace下的角色，对於该namespace下物件的操作权限，我们直接以yaml来解说。

role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: newspace
  name: jenkins-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list", "watch"]

• metadata.namespace: 该role能够访问的namespace。
• metadata.name: role name
• rules.apiGroups: 预设为v1，也就是""。这里指的是apiVersion。只有在对beta功能进行限制时才需要设定apiGroups。
• resources: 限制访问权限的物件
• verbs: 对於该物件能够进行的动作。

我们这边的Role他的权限只能

• 在 namespace newspace下。
• 对於Pod进行ＣＲＵＤ操作。
• 对於Service只有Read-Only权限。

What is ServiceAccount ?

那麽再来我们将在role.yaml添加上serviceAccount，service Account是个让外部访问者使用的帐号，主要让来让像是CICD工具等进行访问时设定的帐号，此外service account将会binding role来限制他的访问权限。

role.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins
  namespace: newspace

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: newspace
  name: jenkins-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list", "watch"]

这边我们建立一个名为jenkins的service account

What is RoleBinding ?

如其名描述，就是用来binding role的物件，那我们一样将RoleBinding加入role.yaml其中。

role.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins
  namespace: newspace

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: newspace
  name: jenkins-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list", "watch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-rolebinding
  namespace: newspace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: jenkins-role
subjects:
  - kind: ServiceAccount
    name: jenkins
    namespace: newspace

Deployment with serviceAccount, role and roleBinding

$ kubectl apply -f role.yaml
serviceaccount/jenkins created
role.rbac.authorization.k8s.io/jenkins-role created
rolebinding.rbac.authorization.k8s.io/jenkins-rolebinding created

$ kubectl get rolebinding -n newspace
NAME                  ROLE                AGE
jenkins-rolebinding   Role/jenkins-role   26s

What is ClusterRole ?

ClusterRole与Role相似，但他是属於丛集通用角色的，也就是在该丛集内所有的namespace都通用该权限。也因此，它能比Role多配置

1. Cluster Resources: 像是Node
2. 非资源类型API: 像是/healthz
3. 跨命名空间的资源，例如 kubectl get pods --all-namespace

OK, 那我们来写ClusterRole的yaml吧

clusterrole.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-global
  namespace: newspace

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: newspace
  name: jenkins-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["get", "list", "watch"]

这边就不在赘述，他与Role相似，只是cluster role可以比role更多一些凌驾於namespace之上的资源进行权限配置。

What is ClusterRoleBinding ?

人如其名，就是用来binding ClusterRole的object，那我们也将它加进clusterrole.yaml吧

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-global

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: newspace
  name: jenkins-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: jenkins-rolebinding
  namespace: newspace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: jenkins-role
subjects:
  - kind: ServiceAccount
    name: jenkins-global
    namespace: newspace

那这边我们就结束了role与clusterrole的基本介绍。

Github Repo

本篇章所有程序码将放在下面的github project当中的branch day-28

後记

这篇章让我们了解Kubernetes cluster在抽象层面是如何有效地区分不同使用者对於不同物件的权限设定，这在往後我们使用些CICD工具进行持续性交付与自动化布署时，不会让这些工具拥有太多的权限，产生安全性上的疑虑。

Reference

https://www.weave.works/blog/optimizing-cluster-resources-for-kubernetes-team-development

https://medium.com/better-programming/k8s-tips-using-a-serviceaccount-801c433d0023

https://kubernetes.io/docs/reference/access-authn-authz/rbac/