《Kubernetes权威指南》——Kubelet运行机制与安全机制
1 Kubelet运行机制[*]Kubenetes集群中的每个Node节点都会启动一个Kubelet服务进程用于处理Master下发到该节点的任务，管理Pod及其中的容器
[*]Kubelet进程在API Server上注册信息，定期向Master节点汇报Node资源情况，并通过cAdvise监控容器和节点资源
1.1 节点管理
[*]Kubelet进程在启动时设置参数--register-node=true设置向APIServer主动注册节点信息
[*]当设置非自动注册时，需要配置Node的资源信息以及给Kubelet指定API Server位置
[*]Kubelet启动参数
--api-server //设置api server位置
--kubeconfig //设置访问api server的证书
--cloud-provider //如何从云服务读取相关元数据
--node-status-update-frequency//向api server报告的间隔时间，默认10s
1.2 Pod管理
[*]非API Server方式创建的Pod称为Static Pod，Kubelet将Static Pod状态汇报给API Server，而后API Server为该Static Pod创建一个Mirror Pod与其相匹配
[*]Kubelet监听etcd中所有对Pod的操作
[*]Kubelet读取到创建和修改Pod任务处理：
[*]为该Pod创建一个数据目录
[*]从API Server读取该Pod清单
[*]为该Pod挂载外部卷(Extenal Volume)
[*]下载Pod用到的Secret
[*]检查已经运行在节点中的Pod，如果Pod没有容器或Pause容器没有启动则停止Pod中所有容器进程。如果Pod中有需要删除的容器则删除
[*]用Pause镜像为每个Pod创建一个容器，其用于接管Pod中所有其他容器的网络
[*]为Pod中的每个容器做如下处理：
[*]校验容器的hash值
[*]如果容器被中止且容器没有指定restartPolicy则不做任何处理
[*]调用Docker Client下载容器镜像，运行容器
1.3 容器健康检查
[*]LivenessProbe探针用于判断容器是否健康，如果不健康则Kubelet将删除该容器并根据重启策略进行处理，实现方式有：
[*]ExecAction：在容器内部执行一个命令如果命令退出状态码为0则容器健康
[*]TCPSocketAction：通过容器IP和端口执行TCP检测
[*]HTTPGetAction：通过容器IP和端口及路径调用HTTP Get方法，判断响应的状态码
[*]Readiness探针用于判断容器是否启动完成，且准备接受请求。如果检测失败则Pod状态将被修改，Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的条目
2 安全机制原理
集群的安全性必须考虑如下几个目标：
[*]保证容器与其所在宿主机的隔离
[*]限制容器给基础设施及其他容器带来的消极影响的能力
[*]最小权限原则——合理限制所有组件的权限
[*]明确组件间边界的划分
[*]划分普通用户和管理员用户
[*]在必要时允许将管理员权限赋给普通用户
[*]允许拥有Secret数据(Keys,Certs,Passwords)的应用在集群中运行
2.1 Authentication认证
Kubelet对API的调用使用如下方式：
[*]CA，使用HTTPS方式，在API Server启动参数--client_ca_file=SOMEFILE 设定CA的认证授权文件
[*]Token，通过API Server启动参数--token_auth_file=SOMEFILE 指定存储Token的文件。Token文件格式为一个包含三列的CSV文件，该文件第一列为Token，第二列为用户名，第三列为用户UID。同时访问时HTTP请求头中的Authorization域必须包含Bearer SOMETOKEN指定该用户的Token
[*]HTTP Base，通过API Server启动参数--basic_auth_file=SOMEFILE 指定存储用户和密码的基本认证文件。该文件为CSV文件，第一列为密码，第二列为用户名，第三列为UID。HTTP请求头中的Authorization域必须包含Basic BASE64ENCODEDUSER:PASSWORD 即base64加密后的用户名和密码
2.2 Authorization授权
[*]授权(Authorization)是认证(Authentication)后的一个独立步骤，作用于API Server主要端口的所有HTTP访问
[*]授权流程通过访问策略比较请求上下文属性，通过API访问资源之前必须通过访问策略进行校验，配置如下：
--authorization_mode=AlwaysDeny //表示拒绝所有请求
--authorization_mode=AlwaysAllow //接受所有请求
--authorization_mode=ABAC //使用用户配置的授权策略去管理访问API Server的请求，ABAC(Attribute-Based Access Control)基于属性的访问控制
[*]Kubernetes中HTTP请求包含如下4个能被授权进程识别的属性：
[*]用户名
[*]是否是只读请求(REST中的GET操作均为只读)
[*]被访问的是哪一类资源
[*]被访问对象所属Namespace
[*]如果请求中不带对应的某个属性则默认零值
[*]选择ABAC模式则需要在API Server启动时设置--authorization_polic_file=SOMEFIME 指定授权策略的JSON文件，文件的每一行为一个JSON的Map对象且不包含List，主要包含以下属性：
[*]user(用户名)，字符串类型
[*]readonly，布尔型，为true时表示只接受GET访问
[*]resource，字符串来自于URL的资源
[*]namespace，字符串表明该策略允许访问的某个Namespace
[*]授权文件中一个未设置的属性表示匹配HTTP请求中该属性的任何值
[*]对请求的4个属性和授权文件的策略对象逐个匹配，如果至少有一个策略对象被匹配上则该请求被授权通过
2.3 Admission Control准入控制
用于拦截所有经过认证和鉴权后的访问API Server请求的可插入代码，这些插件运行在API Server进程中，每个Admission Control插件按照配置顺序执行，如果其中任意一个插件拒绝该请求，则API Server将拒绝请求
[*]配置API Server启动参数admission_control,该参数中加入需要的插件列表，逗号隔开
2.4 Secret私密凭据
主要作用是保管私密数据，如密码、OAuth Token、SSH Keys等，将这些私密信息放在Secret对象比直接放入Pod或Docker Image中要安全。
[*]如果Pod指定了Service Account则该Pod自动添加包含凭证信息的Secrets，用于访问API Server和下载Image
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data: //全部是Base64编码值
password: 123 //Base64编码值
username: 123
[*]Secret被使用的方式：
[*]在创建Pod时通过为Pod指定Service Account来自动使用该Secret
[*]通过挂载Secret到Pod，spec.volumes.secret指定
[*]在创建Pod时，指定Pod的spec.ImagePullSecret来引用
[*]目前Secret只支持API Server创建
[*]在使用Mount方式挂载Secret时，容器中Secret的data域中的各个key值作为目录中的文件，value值被Base64编码后存储在相应的文件中
[*]通过API Server创建Pod时不会校验引用的Secret是否存在，只有当Pod被调度时将试着去获取Secret，如果此时获取不到则将按一定时间间隔定期重试，并发送一个Event解释Pod没启动的原因
[*]Secret包括Opaque、ServiceAccount和Dockercfg三种类型
2.5 Service Account
Service Account是多个Secret的集合，包含普通Secret用于访问API Server和imagePullSecret用于下载容器镜像
apiVersion: v1
kind: ServiceAccount
metadata:
name: myserviceaccount
secrets:
-kind: Secret
name: secret1
apiVersion: v1
-kind: Secret
name: secret2
apiVersion: v1
imagePullSecrets:
-name: secret1
[*]如果创建Pod时没指定ServiceAccount则将在对应Namespace中制定一个名为default的ServiceAccount
页:
[1]