kubernetes基于角色的安全控制学习笔记

【认证和授权】

    任何资源提供使用是认证和授权是必不可少的功能，用于身份鉴别，授权是实现权限分配。

kubernetes基于插件实现这两种功能，另外也支持准入控制，补充授权机制实现精准的访问控制

    API SERVER做为集群的网关，所有的访问请求都是经过它，并对每一次请求都经过验证和权限控制。

所有检查均正常才能访问或者存储数据到后端存储系统etcd中

[用户账户和用户组]
请求有两种类型

1    人    kubectl   rest接口    User Account 用户账号
    独立于集群之外的服务管理的账号，例如管理员分发的账号密钥，keystone一类的用户存储以及用户名密码
    通常用于复杂的业务逻辑控制，它作用与系统全局，因此需要全局唯一
2    pod    客户端库    Service Account 服务账号
    用于k8s api管理的账号，用于pod中的服务进程访问k8s api提供的身份验证
    隶属于名称空间，仅仅用于实现特定的操作任务。

system:unauthenticated： 未能通过任何一个授权插件检验的账号，即未通过认证测试的用户所属的组
system:authenticated： 认证成功的用户自动加入的组，用于快捷引用所有正常通过认证的用户账号
system:serviceaccount : 当前系统上所有的sa账号组
system:serviceaccounts:： 特定名称空间内所有的Service Account对象

api的请求要么与普通用户或者服务用户绑定，要么是匿名用户请求
认证插件： 负责鉴定用户身份，授权插件用于权限许可鉴别。
准入控制： 用于资源的创建、删除、更新和连接操作时进行许可检查。
kubernetes使用验证机制对api的请求进行身份验证。认证的方式：

    1    客户端证书
    2    承载令牌
    3    身份验证代理

以下属性与访问请求相关联,至少为username和serviceaccount启用一个验证插件，如果验证不通过返回401给客户端
成功验证后的用户需要检验是否有权限操作

    1    username
    2    uid
    3    group
    4    extra

api支持的权限控制主要包含以下几种

    1    node  基于pod的目标调度节点来实现对kubelete的访问控制
    2    ABAC 基于属性的访问控制
    3    RBAC 基于角色的访问控制
    4    webhook： 基于http回调机制通过外部rest服务就按察确认用户授权的访问控制
    还有两种  AlwaysAllow和AlwaysDeny，而且自1.9版本起，External Admission Webhooks被分为MutatingAdmission-Webhook和ValidatingAdmissionWebhook两种类型，分别用于在API中执行对象配置的变异和验证操作

[服务账号关联和应用]

服务账号就是： 用于让pod对象内的容器进程访问其他服务时提供的身份认证信息的账户，一个service account资源一般由用户名和secret组成
创建服务账号：serviceaccount是api servers上的一种资源，隶属于某个名称空间，用于pod与对象内部的应用程序在于api-server通讯时完成认证
每个pod对象均可附加其所属名称空间中的一个serviceaccount，且只能附加一个。不过一个service account资源可由所属命令空间中的多个pod对象共同使

[创建服务账号]

    kubectl  create service-account 命令进行创建，或者用声明式读取yaml文件进行创建
    apiVersion: v1
    kind: ServiceAccount
    metadata:
        name: sa-demo
        nameapace: default

[K8S的SSL/TLS认证]

    k8s集群的api server做为整个集群的通讯网关，contraller-manager、scheduler、kubelet以及kube-proxy均通过api server和etcd进行状态更新和存储，master的各组件需要ssl向外提供服务，集群内的各组件间进行通讯时还需要进行双向认证，各节点的通讯以及与客户端的通讯都应该以加密的方式进行身份验证

etcd集群内的对等节点通讯： 基于tcp的2380端口进行事务通讯，对等网络peer类型的数字证书实现通讯安全
etcd集群与客户端的通讯： rest api基于ssl通讯，监听2379端口,支持双向认证。
api server与客户端通讯基于https，有三种形式

       master： kube-schduler 和 kube-controller-manager
       node： 各kubelet和kube-proxy在启动的时候由master节点进行数字签名和办法
       kubelet及其他形式的客户端

[kubeconfig]
/etc/kubernetes/admin.conf是kubeconfig的文件，由kubeadm init自动生成。
使用kubectl config view命令可以查看当前使用配置文件路径

[root@master .kube]# kubectl config view
apiVersion: v1
clusters:

• cluster:

  certificate-authority-data: DATA+OMITTED
  server: https://172.20.128.0:6443

  name: kubernetes

contexts:

• context:

  cluster: kubernetes
  user: kubernetes-admin

  name: kubernetes-admin@kubernetes

current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:

• name: kubernetes-admin
  user:

  client-certificate-data: REDACTED
  client-key-data: REDACTED
  

apiserver的客户端程序 kubectl kubelet kube-controller-manager都可以基于kubeconfig配置文件接入多个集群

kubeconfig常用命令

    - kubectl config set-cluster：设置kubeconfig的clusters配置段。
    - kubectl config set-credentials：设置kubeconfig的users配置段。
    - kubectl config set-context：设置kubeconfig的contexts配置段。
    - kubectl config use-context：设置kubeconfig的current-context配置段

[TLS bootstrapping机制]

    - kubelet使用TLS bootstrap token的kubeconfig文件向kube-apiserver发送请求。
    - kubelet自行生成私钥和签署请求，而后发给集群上的证书签署进程，由控制器自动完成签署过程，即称为k8s bootstrap 。
    - kubeadm启动了节点加入集群时的证书自动签署功能因此加入过程中kubeadm init命令成功后即完成。

[基于角色的访问控制]

RBAC是一种授权的机制，用于界定谁能够或者不能够操作哪个或哪类资源。

    谁： useraccount  或者 serviceaccount
    操作： 要执行的具体操作，增删改查。1.5版本引进，1.6版本为beta版本，1.8版本为稳定版

优点：

    1、对资源型和非资源型的url资源完美覆盖
    2、整个RBAC有少数的几个api对象实现，与其他的资源一样可以基于kubectl和api进行操作
    3、支持进程运行时操作，不需要重启api server即可生效

类型：

    支持Role和ClusterRole两种类型
    Role: 支持名称空间内的资源权限集合
    ClusterRole ： 支持集群级别的资源权限控制，一般作用于整个集群
    对这两种资源进行赋权的时候用到RoleBinding和ClusterRoleBinding
    RoleBinding:  用于将Role许可权益绑定到一个用户和一组用户上
    ClusterRoleBinding:  把ClusterRole中定义的许可权限绑定在一个或一组用户之上

【Role和RoleBinding】

除了还可以用配置清单创建Role，还可以使用命令快速创建
kubectl create role services-admin --verb="" --resource="services,services/" -n testing

RoleBinding

kubectl config use-context kube-user1@kubernetes
kubectl get pod -n testing
kubectl get service -n testing 可以看到为拒绝状态

快速创建RoleBinding的命令
kubectl create rolebinding admin-services --role=service-admin --user=kube-user1 -n testing

【ClusterRole和ClusterRoleBinding】

ClusterRole

ClusterRole是集群级别的资源，它不属于名称空间，故在此处其配置不应该使用metadata.namespace字段，这也可以通过获取nodes-reader的状态信息来进行验证。kube-user1用户此前绑定的pods-reader和services-admin角色属于名称空间，它们无法给予此用户访问集群级别nodes资源的权限，所有的非名称空间级别的资源都无法通过RoleBinding绑定至用户并赋予用户相关的权限，这些是属于ClusterRoleBinding的功能。

【limitRange资源limitRange准入控制器】
未指定资源限制属性的容器可能会因故吞掉所有工作节点上的所有可用计算资源，妥当的做法是使用limitRange资源为每个名称空间指定最小和最大计算资源用量
在名称空间上定义了LimitRange对象之后，客户端提交创建或修改的资源对象将受到LimitRanger控制器的检查，任何违反LimitRange对象定义的资源最大用量的请求将被直接拒绝。

LimitRange支持三种资源的限制：
容器 ， pod和 persistentVolumeClaim，pod和容器主要是cpu和内存的限制。persistentVolumeClaim是对存储空间的限制范围。

【ResourceQuota资源与准入控制器】

尽管LimitRange资源能限制单个容器、Pod及PVC等相关计算资源或存储资源的用量，但用户依然可以创建数量众多的此类资源对象进而侵占所有的系统资源。于是，Kubernetes提供了ResourceQuota资源用于定义名称空间的对象数量或系统资源配额，它支持限制每种资源类型的对象总数，以及所有对象所能消耗的计算资源及存储资源总量等。
用户创建或更新资源的操作违反配额约束将导致请求失败，APIServer以HTTP状态代码“403 FORBIDDEN”作为响应，并显示一条消息以提示可能违反的约束

【PodSecurityPolicy】
是集群级别的资源类型，用于控制用户在配置pod资源的期望状态时可以设定的特权类的属性
如是否可以使用特权容器，根命名空间、和主机文件系统等，以及可以使用的主机忘了和端口，卷类型和linux capabilities。