k8s的安全管理

前言

  • 部署态的安全控制
    • 认证
    • 鉴权
    • Admission(准入控制)
    • pod securitycontext
  • 运行态的安全控制
    • network policy

众所周知,kubernetes API是kubernetes的核心组件,kubernetes API以REST接口的形式将Pods、Service、Deployment等信息定义为资源,而这些资源我们又是怎样操作它们的呢?在kubernetes 1.6之后社区逐渐使用RBAC的认证模式,下面将会详细介绍这种认证模式。

1.k8s的认证

认证方式有:X509、service account、Authentication proxy、WebHook、username/password等等

1.x509认证

  • kube-apiservver的启动参数 --client-ca-file=ca.pem 指定x509的根证书公钥,请求中需要带有该根证书签名的证书,才能认证通过
  • 客户端签署的证书里包含user、group信息

2.Service Account(为k8s必选认证方式)

  • kube-apiserver的启动参数 --service-account-key-file=ca-key.pem 指定pem文件,用以生成 bearer token: “--service-account-lookup=true/false”表示在删除service account后其token是否被吊销
  • serviceaccount admission默认给pod打上servicea count,当然用户也可以自行指定所需要的service account

2.k8s的鉴权之RBAC

1.基本概念

RBAC(Role-Based Access Control,基于角色的访问控制)在k8s v1.5中引入,在v1.6版本时升级为Beta版本,并成为kubeadm安装方式下的默认选项,相对于其他访问控制方式,新的RBAC具有如下优势:

  • 对集群中的资源和非资源权限均有完整的覆盖
  • 整个RBAC完全由几个API对象完成,同其他API对象一样,可以用kubectl或API进行操作
  • 可以在运行时进行调整,无需重启API Server
  • 要使用RBAC授权模式,需要在API Server的启动参数中加上--authorization-mode=RBAC

2 K8S之RBAC原理

RBAC引入了4个新的顶级资源对象:Role、ClusterRole、RoleBinding、ClusterRoleBinding。同其他API资源对象一样,用户可以使用kubectl或者API调用等方式操作这些资源对象。

  • 一共有三种对象,分别是账户、角色、权限。
  • 在定义角色时赋予权限,然后角色绑定给账户,那么账户就有了相应的权限,一个账户可以绑定多个角色,可以方便进行多权限的灵活控制。
  • 一个角色都唯一对应了secret,然后通过查看secret的详细信息,找到token字段,使用token的值进行登录,那么就有了这个角色所对应的权限
    • kubectl get secret -n kube-system #查看secret
    • kubectl describe secret kubernetes-dashboard-token-xnvct -n kube-system #查看指定secret的详细信息,并复制token值,进行登录
  • 账户分为用户账户和服务账户
  • 角色分为role和clusterrole。
  • 绑定角色就有两种,分别是rolebinding和clusterrolebinding

3.RBAC中的资源对象

3.1角色(Role)

   一个角色就是一组权限的集合,这里的权限都是许可形式的,不存在拒绝的规则。在一个命名空间中,可以用角色来定义一个角色,如果是集群级别的,就需要使用ClusterRole了。

   角色只能对命名空间内的资源进行授权,下面的例子中定义的角色具备读取Pod的权限:··

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
    namespace: default
    name: pod-reader

rules:
- apiGroups: [""]  # 空字符串表示核心API群
  resource: ["pods"]
  verbs: ["get", "watch", "list"]

rules中的参数说明:

  • apiGroup:支持的API组列表,例如:APIVersion: batch/v1、APIVersion: extensions:v1、apiVersion:apps/v1等
"","apps", "autoscaling", "batch"
  • resources:支持的资源对象列表,例如:pods、deployments、jobs等
"services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs","nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets","horizontalpodautoscalers","replicationcontrollers","cronjobs"
  • verbs:对资源对象的操作方法列表,例如:get、watch、list、delete、replace、patch等
"get", "list", "watch", "create", "update", "patch", "delete", "exec","redirect","proxy","deletecollection"

3.2 集群角色(ClusterRole)

集群角色除了具有和角色一致的命名空间内资源的管理能力,因其集群级别的范围,还可以用于以下特殊元素的授权。

Role会指定namespace,ClusterRole不需要指定namespace,因为它作用于整个namespace上。

ClusterRole与Role的主要区别有:

  • 可以针对集群资源(如nodes)
  • 可以作用于非资源类型endpoints(如/healthz)
  • 可以作用于整个namespace上(如kubectl get pods--all-namespaces上的资源)

下面的集群角色可以让用户有权访问任意一个或所有命名空间的secrets:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

3.3 角色绑定(RoleBinding)

RoleBinding或ClusterRoleBinding主要的作用是将主体(如user、serviceaccount等)与Role或ClusterRole进行绑定,这样就可以使得user、group或serviceAccount主体具有指定角色的权限规则。

1)Role绑定 RoleBinding

RoleBinding可以引用Role进行授权,下例中的RoleBinding将在default命名空间中把pod-reader角色授予用户wanglei,可以让wanglei用户读取default命名空间的Pod:

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: wanglei # Name is case sensitive
  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 bind to
  apiGroup: rbac.authorization.k8s.io

subjects为作用的主体可以为user或者serviceAccount,roleRef代表与Role或者ClusterRole进行绑定,这样jane用户就具有pod-reader对应的权限了。

需要注意的是,如果想通过更改当前Role或者ClusterRole中的规则来改变权限规则,这样是错误的,可以通过删除现有规则重新绑定的方法来实现。可以使用kubectl auth命令更新现有规则。

可以使用kubectl get role, rolebinding -n kube-system查看现有集群role使用情况

2)ClusterRole绑定 RoleBinding

RoleBinding也可以引用ClusterRole,对属于同一命名空间内ClusterRole定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组角色(ClusterRole),然后在多个命名空间中重复使用这些ClusterRole。

使用RoleBinding绑定集群角色secret-reader,使dave只能读取development命名空间中的secret:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development

subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

如果集群中有多个namespace分配给不同的管理员,但是他们的权限是一样的,那么这样可以先定义一个ClusterRole,然后通过RoleBinding将不同namespace的管理员做绑定,这样可以解决多次定义Role的问题。

3.4 集群角色绑定(ClusterRoleBinding)

集群角色绑定中的角色只能是集群角色,用于进行集群级别或者对所有命名空间都生效的授权。

允许manager组的用户读取任意namespace中的secret

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
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

4.RBAC-

4.1对资源的引用方式

多数资源可以用其名称的字符串来表达,也就是Endpoint中的URL相对路径,例如pods。然后,某些Kubernetes API包含下级资源,例如Pod的日志(logs)。Pod日志的Endpoint是GET /api/v1/namespaces/{namespaces}/pods/{name}/log

Pod是一个命名空间内的资源,log就是一个下级资源。要在一个RBAC角色中体现,则需要用斜线/来分割资源和下级资源。若想授权让某个主体同时能够读取Pod和Pod log,则可以配置resources为一个数组:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

资源还可以通过名字(ResourceName)进行引用。在指定ResourceName后,使用get、delete、update、patch动词的请求,就会被限制在这个资源实例范围内。例如下面的声明让一个主体只能对一个叫my-configmap的configmap进行get和update操作:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

4.2 Aggregated ClusterRoles聚合类ClusterRoles

在1.9版本之后,ClusterRoles可以使用aggregationRule规则,将具有相同标签的规则作为统一主体完成授权操作。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # Rules are automatically filled in by the controller manager.

通过aggregationRule选项,将匹配matchLabels中包含monitoring标签的规则。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# These rules will be added to the "monitoring" role.
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

可以通过这种标签聚会的方式,将多个ClusterRole聚会成统一的规则策略。

5.RBAC-常见的Role示例

5.1 允许读取核心API组中Pod的资源:

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

5.2 允许读写"extensions"和"apps"两个API组中的deployment资源

rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

5.3 允许读写pods及读写jobs

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

5.4 允许读取一个名为my-config的ConfigMap(必须绑定到一个RoleBinding来限制到一个namespace下的ConfigMap):

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

5.5 读取核心组的node资源(Node属于集群级别的资源,必须放在ClusterRole中,并使用ClusterRoleBinding进行绑定):

rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

5.6 允许对非资源端点/healthz及其所有子路径进行GET/POST操作(必须使用ClusterRole和ClusterRoleBinding):

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"]
  verbs: ["get", "post"]

6.常用的角色绑定

6.1. 用户名wanglei@example.com

subjects:
- kind: User
  name: "wanglei@example.com"
  apiGroup: rbac.authorization.k8s.io

6.2 组名frontend-admins

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

6.3 kube-system命名空间中的默认Service Account

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

6.4 qa命名空间中的所有Service Account

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

6.5 所有Service Account

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

6.6 所有认证用户

subjects:
- kind: Group
  name: system:authentication
  apiGroup: rbac.authorization.k8s.io

6.7 所有未认证用户

subjects:
- kind: Group
  name: system:unauthentication
  apiGroup: rbac.authorization.k8s.io

6.8 全部用户

subjects:
- kind: Group
  name: system:authentication
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthentication
  apiGroup: rbac.authorization.k8s.io

7 默认的角色和角色绑定

API Server会创建一套默认的ClusterRole和ClusterRoleBinding对象,其中很多是以system:为前缀的,以表明这些资源属于基础架构,对这些对象的改动可能造成集群故障。

所有默认的ClusterRole和RoleBinding都会用标签kubernetes.io/bootstrapping=rbac-defaults进行标记。

常见的系统角色如下:

有些默认角色不是以system:为前缀的,这部分角色是针对用户的,其中包含超级用户角色cluster-admin,有的用于集群一级的角色cluster-status,还有针对namespace的角色admin、edit、view

常见的用户角色如下:

核心Master组件角色

8 授权注意事项:预防提权和授权初始化

RBAC API拒绝用户利用编辑角色或者角色绑定的方式进行提权。这一限制是在API层面做出的,因此即使RBAC没有启用也仍然有效。

  用户只能在拥有一个角色的所有权限,且与该角色的生效范围一致的前提下,才能对角色进行创建和更新。例如用户user-1没有列出集群中所有secret的权限,就不能创建具有这一权限的集群角色。要让一个用户能够创建或更新角色,需要以下权限:

  • 为其授予一个允许创建/更新Role或ClusterRole资源对象的角色;
  • 为用户授予角色,要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或者集群角色,则该API调用会被禁止。

如果一个用户的权限包含了一个角色的所有权限,那么就可以为其创建和更新角色绑定;或者如果被授予了针对某个角色的绑定授权,则也有权完成此操作。

  例如:user1没有列出集群内所有secret的权限,就无法为一个具有这样权限的角色创建集群角色绑定。要使用户能够创建、更新这一角色绑定,则需要有如下做法:

  • 为其授予一个允许创建和更新角色绑定或者集群角色绑定的角色

   为其授予绑定某一角色的权限,有隐式或显式两种方法

  • 隐式:让其具有所有该角色的权限
    • 显式:让用户授予针对该角色或集群角色绑定操作的权限

让user-1有对user-1-namespace命名空间中的其他用户授予admin、edit及view角色

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  resourceNames: ["admin", "edit", "view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user-1

3 Admission(准入控制)

  • kube-apiserver 的启动参数 --admission-control=podsecuritypolicy 新增podsecuritypolicyadmission
  • admin用户创建podsecuritypolicy策略,决定能创建什么样的pod
  • 创建pod的用户也必须赋予它能使用podsecuritypolicy策略的权限

4.Pod Security Context 安全上下文

5.Network Policy

posted @ 2020-10-27 16:45  大葱丁  阅读(196)  评论(0编辑  收藏  举报