深入理解Kubernetes 4A - Audit源码解析

本文是关于Kubernetes 4A解析的第4章 深入理解Kubernetes 4A - Authentication源码解析 深入理解Kubernetes 4A - Authorization源码解析 深入理解Kubernetes 4A - Admission Control源码解析 深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证 所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A Overview 审计是信息系统中非常重要的一部分,Kubernetes 1.11中也增加了审计 (Auditing) 功能,通过审计功能获得 deployment, ns,等资源操作的事件。 objective: 从设计角度了解Auditing在kubernets中是如何实现的 了解kubernetes auditing webhook 完成实验,通过webhook来收集审计日志 如有错别字或理解错误地方请多多担待,代码是以1.24进行整理,实验是以1.19环境进行,差别不大。 Kubernetes Auditing 根据Kubernetes官方描述审计在kubernetes中是有控制平面 kube-apiserver 中产生的一个事件,记录了集群中所操作的资源,审计围绕下列几个维度来记录事件的: 发生了什么 发生的事件 谁触发的 发生动作的对象 在哪里检查到动作的 从哪触发的 处理行为是什么 审计生命周期开始于组件 kube-apiserver 准入控制阶段,在每个阶段内都会产生审计事件并经过预处理后写入后端,目前后端包含webhook与日志文件。 审计日志功能增加了 kube-apiserver 的内存消耗,因为会为每个请求存储了审计所需的上下文。内存的消耗取决于审计日志配置 [1]。 审计事件设计 审计的schema不同于资源API的设计,没有 metav1.ObjectMeta 属性,Event是一个事件的结构体,Policy是事件配置,属于kubernetes资源,在代码 k8s.io/apiserver/pkg/apis/audit/types.go 可以看到 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 type Event struct { metav1....

 ·  · 

深入理解Kubernetes 4A - Authorization源码解析

本文是关于Kubernetes 4A解析的第2章 深入理解Kubernetes 4A - Authentication源码解析 深入理解Kubernetes 4A - Authorization源码解析 深入理解Kubernetes 4A - Admission Control源码解析 深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证 所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A Overview 在 Kubernetes 中,当一个访问请求通过了登录阶段(Authentication),必须还需要请求拥有该对象的访问权限,而授权部分也是Kubernetes API 访问控制中的第二个部分 Authorization . Authorization 在 Kubernetes中是以评估发起请求的用户,根据其身份特性评估这次请求是被 ”拒绝“ 还是 “允许”,同访问控制三部曲中其他两个插件 (Authentication, Adminssion Control) 一样,Authorization 也可以同时配置多个,当收到用户的请求时,会依次检查这个阶段配置的所有模块,如果任何一个模块对该请求授予权限(拒绝或允许),那么该阶段会直接返回,当所有模块都没有该用户所属的权限时,默认是拒绝,在Kubernetes中,被该插件拒绝的用户显示为HTTP 403。 如有错别字或理解错误地方请多多担待,代码是以1.24进行整理,实验是以1.19环境进行,差别不大 objective: 了解kubernetes Authorization机制 了解授权系统的设计 完成实验,使用 OPA 作为 Kubernetes 外部用户,权限认证模型 RBAC 的替代品 Kubernetes是如何对用户授权的 kubernetes对用户授权需要遵守的shema必须拥有下列属性,代码位于pkg\apis\authorization\types.go go 1 2 3 4 5 6 7 8 9 type SubjectAccessReview struct { // API必须实现的部分 metav1....

 ·  · 

深入理解Kubernetes 4A - Authentication源码解析

本文是关于Kubernetes 4A解析的第1章 深入理解Kubernetes 4A - Authentication源码解析 深入理解Kubernetes 4A - Authorization源码解析 深入理解Kubernetes 4A - Admission Control源码解析 深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证 所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A Overview 本章主要简单阐述kubernetes 认证相关原理,最后以实验来阐述kubernetes用户系统的思路 objective: 了解kubernetes 各种认证机制的原理 了解kubernetes 用户的概念 了解kubernetes authentication webhook 完成实验,如何将其他用户系统接入到kubernetes中的一个思路 如有错别字或理解错误地方请多多担待,代码是以1.24进行整理,实验是以1.19环境进行,差别不大。 Kubernetes 认证 在Kubernetes apiserver对于认证部分所描述的,对于所有用户访问Kubernetes API(通过任何客户端,客户端库,kubectl 等)时都会经历 验证 (Authentication) , 授权 (Authorization), 和准入控制 (Admission control) 三个阶段来完成对 “用户” 进行授权,整个流程正如下图所示 图:Kubernetes API 请求的请求处理步骤图 Source:https://www.armosec.io/blog/kubernetes-admission-controller/ 其中在大多数教程中,在对这三个阶段所做的工作大致上为: Authentication 阶段所指用于确认请求访问Kubernetes API 用户是否为合法用户,拒绝为401 Authorization 阶段所指的将是这个用户是否有对操作的资源的权限,拒绝为403 Admission control 阶段所指控制对请求资源进行控制,通俗来说,就是一票否决权,即使前两个步骤完成...

 ·  · 

漏桶算法与令牌桶算法

Principle of token bucket 随着互联网的发展,在处理流量的方法也不仅仅为 first-come,first-served,而在共享网络中实现流量管理的基本机制就是排队。而公平算法则是实现在优先级队列中基于哪些策略来排队的 “公平队列” 。Token Bucket 则是为公平排队提供了替代方案。Fair Queue 与 Token Bucket的区别主要在,对于Fair Queue来讲,如果请求者目前空闲,Queue会将该请求者的带宽分配给其他请求者;而 Token Bucket 则是分配给请求者的带宽是带宽的上限。 通过例子了解算法原理 假设出站带宽是 4个数据包/ms,此时有一个需求为,为一个特定的发送端 A 来分配 1个数据包/ms的带宽。此时可以使用公平排队的方法分给发送 A 25%的带宽。 此时存在的问题是我们希望可以灵活地允许 A 的数据包以无规则的时间间隔发送。例如假设 A 在每个数据包发送后等待1毫秒后再开始下一个数据包的发送。 sence1:此时假设 A 以 1ms 的间隔去发送数据包,而由于某种原因导致应该在 t=6 到达的数据包却在 t=6.5 到达。随后的数据包在 t=7 准时到达,在这种情况下是否应该保留到t=7.5? sence2:或者是否允许在 t=6.5 发送一个迟到的数据包,在 t=7 发送下一个数据包,此时理论上平均速率仍然还是 1 个数据包/ms? 显然sence2是合理的,这个场景的解决方法就是令牌桶算法,规定 A 的配额,允许指定平均速率和突发容量。当数据包不符合令牌桶规范,那么就认为其不合理,此时会做出一下相应: delay,直到桶准备好 drop mark,标记为不合规的数据包 delay 被称为 整形 shaping , shaping 是指在某个时间间隔内发送超过 Bc(Committed Burst)的大小,Bc 在这里指桶的尺寸。由于数据流量是突发性的,当在一段时间内不活动后,再次激活后的在一个间隔内发送的数量大于 Bc ,那么额外的流量被称为Be (burst excess)。 将流量丢弃或标记超额流量,保持在一个流量速率限制称为 “管制” policing。...

 ·  · 

Kubernetes Pod网络排错思路

本文是关于深入理解Kubernetes网络原理系列第4章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Overview 本文将引入一个思路:“在Kubernetes集群发生网络异常时如何排查”。文章将引入Kubernetes 集群中网络排查的思路,包含网络异常模型,常用工具,并且提出一些案例以供学习。 Pod常见网络异常分类 网络排查工具 Pod网络异常排查思路及流程模型 CNI网络异常排查步骤 案例学习 Pod网络异常 网络异常大概分为如下几类:...

 ·  ·