Kubernetes集群安全机制

概述

当我们访问K8S集群时,需要经过三个步骤完成具体操作

  • 认证
  • 鉴权【授权】
  • 准入控制

进行访问的时候,都需要经过 apiserver, apiserver做统一协调,比如门卫

  • 访问过程中,需要证书、token、或者用户名和密码
  • 如果访问pod需要serviceAccount

认证

对外不暴露8080端口,只能内部访问,对外使用的端口6443

客户端身份认证常用方式

  • https证书认证,基于ca证书
  • http token认证,通过token来识别用户
  • http基本认证,用户名 + 密码认证

鉴权

基于RBAC进行鉴权操作

基于角色访问控制

准入控制

就是准入控制器的列表,如果列表有请求内容就通过,没有的话 就拒绝

RBAC介绍

基于角色的访问控制,RBAC将角色和角色绑定分开,角色指的是一组定义好的操作集群资源的权限,而角色绑定是将角色和用户、组或者服务账号实体绑定,从而赋予这些实体权限。可以看出 RBAC 这种授权方式很灵活,要赋予某个实体权限只需要绑定相应的角色即可。

针对 RBAC 机制,k8s 提供了四种 API 资源:Role、ClusterRole、RoleBinding、ClusterRoleBinding。

k8s中有默认的几个角色

  • role:特定命名空间访问权限
  • ClusterRole:所有命名空间的访问权限

角色绑定

  • roleBinding:角色绑定到主体
  • ClusterRoleBinding:集群角色绑定到主体

主体

  • user:用户
  • group:用户组
  • serviceAccount:服务账号

RBAC实现鉴权

创建命名空间

kubectl get namespace

 然后我们创建一个自己的命名空间 roledemo

kubectl create ns roledemo

命名空间创建Pod

为什么要创建命名空间?因为如果不创建命名空间的话,默认是在default下

kubectl run nginx --image=nginx -n roledemo

创建角色

  • Role: 只能用于授予对某一单一命名空间中资源的访问权限,因此在定义时必须指定 namespace;

       以下示例描述了 default 命名空间中的一个 Role 对象的定义,用于授予对 pod 的读访问权限:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: roledemo
name: pod-reader
rules:
- apiGroups: [""] # 空字符串""表明使用core API group
resources: [
"pods"]
verbs: [
"get", "watch", "list"]

 

tip:这个角色只对pod 有 get、list权限

然后通过 yaml创建我们的role

# 创建
kubectl apply -f rbac-role.yaml
# 查看
kubectl get role -n roledemo
  • ClusterRole:针对集群范围的角色,能访问整个集群的资源;

下面示例中的 ClusterRole 定义可用于授予用户对某一特定命名空间,或者所有命名空间中的 secret(取决于其绑定方式)的读访问权限:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # 鉴于ClusterRole是集群范围对象,所以这里不需要定义"namespace"字段
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

创建角色绑定

  • RoleBinding:将 Role 和用户实体绑定,从而赋予用户实体命名空间内的权限,同时也支持 ClusterRole 和用户实体的绑定;

下面示例中定义的 RoleBinding 对象在 default 命名空间中将 pod-reader 角色授予用户 jane。 这一授权将允许用户 jane 从 default 命名空间中读取pod:

# 以下角色绑定定义将允许用户"jane"从"default"命名空间中读取pod。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: roledemo
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role    # this must be Role or ClusterRole
  name: pod-reader   #this must match the name of the Role or ClusterRole you wish to bing to
  apiGroup: rbac.authorization.k8s.io

然后创建我们的角色绑定

# 创建角色绑定
kubectl apply -f rbac-rolebinding.yaml
# 查看角色绑定
kubectl get role, rolebinding -n roledemo
  • ClusterRoleBinding:将 ClusterRole 和用户实体绑定,从而赋予用户实体集群范围的权限;

下面示例中所定义的 ClusterRoleBinding 允许在用户组 manager 中的任何用户都可以读取集群中任何命名空间中的 secret:

# 以下`ClusterRoleBinding`对象允许在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

使用证书识别身份

我们首先得有一个 rbac-user.sh 证书脚本

 

 这里包含了很多证书文件,在TSL目录下,需要复制过来

通过下面命令执行我们的脚本

./rbac-user.sh

最后我们进行测试

# 用get命令查看 pod 【有权限】
kubectl get pods -n roledemo
# 用get命令查看svc 【没权限】
kubectl get svc -n roledmeo

 关于 RBAC 更详细的讲解见这里:https://jimmysong.io/kubernetes-handbook/concepts/rbac.html

原文地址:https://www.cnblogs.com/fat-girl-spring/p/14149579.html