14.基于Kubernetes和Istio的安全保证

1.理解传统安全架构的挑战

2.掌握零信任架构的意义和机遇

3.掌握Kubernetes平台本身的安全保证手段

4.学习如何基于Kubernetes和Istio实现对应用的隔离和安全保证

1.云原生语境下的安全保证

        容器运行时的安全保证

        Kubernetes的安全保证
2.Taint
3.NetworkPolicy

        依托于 Calico 的 NetworkPolicy

4.零信任架构(ZTA)

5.基于Istio的安全保证。

        认证
        鉴权

1.云原生语境下的安全保证

云原生语境下的安全保证

- 安全保证是贯穿软件整个生命周期的重要部分
- 安全与效率有时候是相违背的。
- 如何将二者统一起来，提升整体效率是关键。
- 这需要我们将安全思想贯穿到软件开发运维的所有环节

云原生层次模型
软件的生命周期:开发->分发->部署-> 运行

开发环节的安全保证
saas应用的12-factor 设计原则的一些理念与云原生安全不谋而合
传统的安全三元素 CIA (Confidentiality, Integrity 和 Availability) ，在云原生安全中被充分应用，如对工作负载的完整性保护，与I(Integrity) 完整性保护相对应。
        ·机密性(Confidentiality) 指只有授权用户可以获取信息。
        完整性(Integrity)指信息在输入和传输的过程中，不被非法授权修改和破坏，保证数据的一致性。
        可用性(Availability) 指保证合法用户对信息和资源的使用不会被不正当地拒绝
基础设施即代码 (Infrastructure as Code,简称 laC) 也与云原生的实践紧密相关
这些方法和原则，都强调通过早期集成安全检测，以确保对过程的控制，使其按预期运行。
通过早期检测的预防性成本，降低后续的修复成本，提升了安全的价值。

开发

 分发环节的安全保证
云原生应用生命周期中的分发阶段不仅需要包括验证工作负载本身的完整性的方法，还需要包括创建工作负载的过程和操作手段。
对于软件生产周期流水线中产生的工件(如容器镜像)，需要进行持续的自动扫描和更新来确保安全，防止漏洞、恶意软件、不安全的编码和其他不安全的行为。
在完成这些检查后，更重要的是对产品进行加密签名，以确保产品的完整性及不可抵赖性

分发

 部署环节的安全保证
在整个开发和集成发布阶段，应对候选工作负载的安全性进行实时和持续的验证，如，对签名的工件进行校验，确保容器镜像安全和运行时安全，并可验证主机的适用性。安全工作负载的监控能力，应以可信的方式监控日志和可用指标，与工作负载一同部署来完善整体的安全性。

部署

运行前检查
镜像签名及完整性
镜像运行策略(如没有恶意软件或严重的漏洞)
容器运行策略(如无过度权限)
主机安全漏洞和合规性控制
工作负载、应用程序和网络安全策略

运行时环节的安全保证
应用程序通常由多个独立和单一职责的微服务组成，容器编排层使得这些微服务通过服务层抽象进行相互通信。
确保这种相互关联的组件架构安全的最佳实践，包括以下几点:
1.只有经过批准的进程能在容器命名空间内运行
2.禁止并报告未经授权的资源访问;
3.监控网络流量以检测恶意的活动;
服务网格是另一种常见的服务层抽象，它为已经编排的服务提供了整合和补充功能，而不会改4.
变工作负载软件本身(例如，AP 流量的日志记录、传输加密、可观察性标记、认证和授权)。

运行环境

容器运行时的安全保证

以Non-root身份运行容器
在 Dockerfile 中通过 USER 命令切换成非 root 用户原因分析:
防止某些坏的镜像窃取主机的root 权限并造成危害。有些运行时容器内部的 root用户与主机的 rot 用户是同一个用户，如不进行用户切换很可能因为权限过大引发严重的问题，比如一个最简单的 case，主机上的重要文件夹被 mount 到容器内部，并被容器修改配置。
即使在容器内部也应该进行权限隔离，比如当我们希望构建不可变配置的容器镜像时，应该将运行容器的用户切换为非root 用户，并且限制其读写权限和读写目录。

FROM ubuntu
RUN user add patrick
USER patrick

 User Namespace 利rootless container
User Namespace:
        依赖于User namespace，任何容器内部的用户都会映射成主机的非 root 用户
        但该功能未被默认enable，因其引入配置复杂性，比如系统不知道主机用户和容器用户的映射关系在mount文件的时候无法设置适当的权限。
Rootless container:
        rootlesscontainer 是指容器运行时以非root 身份启动。
        在该配置下，即使容器被突破，在主机层面获得的用户权限也是非 root 身份的用户，这确保了安全

        Docker 和其他运行时本身的后台 Daemon (如Docker Daemon)需要root 身份运行，然后其他用户的容器才能以rootless 身份运行。
        一些运行时，比如 Podman，无需 Daemon 进程，因为可以完全不需要 root 身份。

集群的安全性保证

·保证容器与容器之间、容器与主机之间隔离，限制容器对其他容器和主机的消极影响。

·保证组件、用户及容器应用程序都是最小权限，限制它们的权限范围。

·保证集群的敏感数据的传输和存储安全。

·常用手段

·Pod安全上下文(Pod Security Context)

·API Server的认证、授权、审计和准入控制

·数据的加密机制等

Kubernetes 的安全保证

Kubernetes 期望集群中所有的 API通信在默认情况下都使用 TLS 加密，大多数安装方法也允许创建所需的证书并且分发到集群组件中，

控制面安全保证

认证。
小型的单用户集群可能希望使用简单的证书或静态承载令牌方法。
更大的集群则可能希望整合现有的、OIDC、LDAP 等允许用户分组的服务器
所有 API客户端都必须经过身份验证，即使它是基础设施的一部分，比如节点、代理、调度程序和卷插件。这些客户端通常使用服务帐户或 X509 客户端证书，并在集群启动时自动创建或是作为集群安装的一部分进行设置。
授权
与身份验证一样，简单而广泛的角色可能适合于较小的集群，但是随着更多的用户与集群交互，可能需要将团队划分成有更多角色限制的单独的命名空间。
配额
资源配额限制了授予命名空间的资源的数量或容量。这通常用于限制命名空间可以分配的 CPU、内存或持久磁盘的数量，但也可以控制每个命名空间中有多少个 Pod、服务或卷的存在。 

NodeRestriction
准入控制器限制了 kubelet 可以修改的 Node 和 Pod 对象，kubelet 只可修改自己的 Node API对象，只能修改绑定到节点本身的 Pod 对象。
NodeRestriction 准入插件可防止 kubelet 删除 Node AP| 对象。
防止 kubelet 添加/删除/更新带有 node-restriction.kubernetes.io/前缀的标签将来的版本可能会增加其他限制，以确保 kubelet 具有正常运行所需的最小权限集，
思考为什么?
降低获得 kubelet kubeconfig 的人能做成的破坏。。
存储加密

runAsUser
SecurityContext
PodsecurityPolicy
MustRunAs
MustRunAsNonRoot

Security Context

Pod 定义包含了一个安全上下文，用于描述允许它请求访问某个节点上的特定 Linux用户(如root)、获得特权或访问主机网络，以及允许它在主机节点上不受约束地运行的其它控件。Pod 安全策略可以限制哪些用户或服务帐户可以提供危险的安全上下文设置。例如:Pod 的安全策略可以限制卷挂载，尤其是 hostpath，这些都是 Pod 应该控制的一些方面。
一般来说，大多数应用程序需要限制对主机资源的访问，他们可以在不能访问主机信息的情况下成功以根进程(UID0)运行。但是，考虑到与root用户相关的特权，在编写应用程序容器时你应该使用非 root 用户运行。
类似地，希望阻止客户端应用程序逃避其容器的管理员，应该使用限制性的 Pod 安全策略。
Kubernetes 提供了三种配置 Security context 的方法:
Container-levelSecurity Context:仅应用到指定的容器。。
Pod-levelSecurity context:应用到 Pod 内所有容器以及 Volume.
Pod security Policies(PSP):应用到集群内部所有 Pod 以及 Volume. 

Container-level Security Context

Pod-level Security Context

Pod Security Policy(PSP)

PSP示例

2.Taint

为节点增加taint

Taint
可以以租户为粒度，为不同租户的节点增加 Taint，使得节点彼此隔离。Taint 的作用是让租户独占节点，无对应 Toleration 的 Pod 无法被调度到 Taint 节点上，实现了应用部署的隔离。

3. NetworkPolicy

NetworkPolicy

如果你希望在 IP 地址或端口层面(OSI第3层或第4层)控制网络流量，则你可以考虑为集群中特定应用使用 Kubernetes网络策略(NetworkPolicy)。Pod 可以通信的 Pod 是通过如下三个标识符的组合来辩识的:
其他被允许的 Pods;。
被允许的名字空间;.
IP 组块。。
网络策略通过网络插件来实现。要使用网络策略，你必须使用支持NetworkPolicv的网络解决方案。创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。

隔离和非隔离的 Pod
默认情况下，Pod 是非隔离的，它们接受任何来源的流量，
Pod 在被某 NetworkPolicy 选中时进入被隔离状态。
一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，该 Pod 会拒绝该 NetworkPolicy 所不允许的连接网络策略不会冲突，它们是累积的。如果任何一个或多个策略选择了一个 Pod，则该 Pod 受限于这些策略的入站(Ingress)/出站(Egress)规则的并集。因此评估的顺序并不会影响策略的结果。为了允许两个 Pods 之间的网络数据流，源端 Pod 上的出站(Eqress)规则和目标端 Pod 上的入站(Ingress)规则都需要允许该流量。如果源端的出站(Egress)规则或目标端的入站(Ingress)规则拒绝该流量，则流量将被拒绝。 

安全策略属性
spec:NetworkPolicy规约中包含了在一个名字空间中定义特定网络策略所需的所有信息。podSelector:
每个 NetworkPolicy都包括一个 podSelector，它对该策略所适用的一组 Pod 进行选择。
空的 podSelector 选择名字空间下的所有 Pod.
policyTypes:
每个 NetworkPolicy都包含一个 policyTypes 列表，其中包含 Ingress 或 Egress 或两者兼具。。如果 NetworkPolicy 未指定 policyTypes 则默认情况下始终设置 Ingress;如果 NetworkPolicy 有任何出口规则的话则设置 Egress。
安全策略属性
Ingress:
·每个 NetworkPolicy 可包含一个Ingress 规则的白名单列表。
每个规则都允许同时匹配 from 和 ports 部分的流量。。
Egress:
·每个 NetworkPolicy 可包含一个 Eqress 规则的白名单列表。
每个规则都允许匹配 to 和 port 部分的流量。。

NetworkPolicy

默认策略

依托于 Calico 的 NetworkPolicy

NetworkPolicy
NetworkPolicy是命名空间级别资源。规则应用于与标签选择器匹配的endpoint 的集合。

GlobalNetworkPolicy
GlobalNetworkPolicy与 NetworkPolicy 功能一样，是整个集群级别的资源。
GlobalNetworkPolicy 会在集群中所有 Namespace 生效，并且能限制主机(HostEndpoint)。 

创建 NetworkPolicy 并查看结果
创建 networkpolicy
kubectl apply-f module14/networkpolicy.yaml·

查看创建结果
kubectl get po -n ns-calico-01
·登陆toolbox 容器
kubectl exec -it toolbox-68f79dd5f8-4664n bash
测试网络
ping 192.168.119.84

PING 192.168.119.84(192.168.119.84)56(84) bytes of data.

---192.168.119.84 ping statistics ---

理解 Calico 的防火墙规则

创建 NetworkPolicy 并查看结果

 创建规则允许ICMP
创建规则允许ICMP 协议
kubectlapply-fmodule14/allow-icmp-incluster.yaml·

查看结果
nsenter-t 5989 -n

ping 192.168.119.84

PING 192.168.119.84(192.168.119.84)56(84)bytes
of data.

64 bytes from 192.168.119.84:icmp seg=1 ttl=63

time=0.061 ms

64 bytes from 192.168.119.84:icmp seg=2 ttl=63

time=0.071 ms

查看规则变化

4.零信任架构(ZTA)

传统安全模型

DMZ 模式
传统的网络安全架构理念是基于边界的安全架构，企业构建网络安全体系时，首先寻找安全边界，把网络划分为外网、内网、DMZ(DeMilitarized Zone)区等不同的区域然后在边界上部署防火墙、入侵检测、WAF 等产品。
这种网络安全架构假设或默认了内网比外网更安全，在某种程度上预设了对内网中的人、设备和系统的信任，忽视加强内网安全措施。
不法分子一旦突破企业的边界安全防护进入内网，会像进入无人之境，将带来严重的后果。
传统的认证，即信任、边界防护、静态访问控制、以网络为中心。

零信任架构(Zero Trust Architecture,ZTA)
随着云计算、大数据、物联网、移动办公等新技术与业务的深度融合，网络安全边界也逐渐变得更加模糊，传统边界安全防护理念面临巨大挑战。
零信任核心原则:从不信任，始终验证
动态安全架构:
以身份为中心.
以识别、持续认证、动态访问控制、授权、审计以及监测为链条
以最小化实时授权为核心
以多维信任算法为基础
认证达末端。.

 
零信任架构(ZTA)

与边界模型的“信任但验证”不同，零信任的核心原则是“从不信任、始终验证”根据 Evan Gilman《Zero Trust Networks》书中所述，零信任网络建立在五个假设前提之下:应该始终假设网络充满威胁;。
外部和内部威胁每时每刻都充斥着网络。
不能仅仅依靠网络位置来确认信任关系;
所有设备、用户、网络流量都应该被认证和授权
访问控制策略应该动态地基于尽量多的数据源进行计算和评估。 

ZTA 安全模型

零信任架构的三大技术“SIM”
零信任架构的三大技术“SIM”，即
软件定义边界(SDP,Software Defined Perimeter)
身份识别与访问管理(IAM,Identityand Access Management)
微隔离(MSG,Micro Seamentation).

软件定义边界(SDP)
SDP 旨在使应用程序所有者能在需要时部署安全边界，以便将服务与不安全的网络隔离开SDP将物理设备替换为在应用程序所有者控制下运行的逻辑组件，仅在设备验证和身份验证后才允许访问企业应用基础架构。
基于 SDP 的系统通常会实施控制层与数据层的分离:
控制流阶段，用户及其设备进行预认证来获取丰富的属性凭据作为身份主体，以此结合基。于属性的预授权策略，映射得到仅供目标访问的特定设备和服务;
数据传输阶段直接建立相应安仝连接并传输数据。

身份识别与访问管理(IAM)
零信任强调基于身份的信任链条，即该身份在可信终端，该身份拥有权限才可对资源进行请求。传统的 IAM 系统可以协助解决身份唯一标识、身份属性、身份全生命周期管理的功能问题，通过 IAM 将身份信息(身份吊销离职、身份过期、身份异常等)传递给零信任系统后，零信任系统可以通过 IAM 系统的身份信息来分配相应权限。
通过 IAM 系统对身份的唯一标识，可有利于零信任系统确认用户可信，通过唯一标识对用户身份建立起终端、资源的信任关系，并在发现风险时实施针对关键用户相关的访问连接进行阻断等控制。 

微隔离(MSG)
微隔离本质上是一种网络安全隔离技术
能够在逻辑上将数据中心划分为不同的安全段，一直到各个工作负载级别，。为每个独立的安全段定义访问控制策略，
它主要聚焦在云平台东西向流量的隔离
一是区别传统物理防火墙的隔离作用;
二是更加贴近云计算环境中的真实需求
微隔离将网络边界安全理念发挥到极致，将网络边界分割到尽可能的小，能够很好的缓解传统边界安全理念下的边界过度信任带来的安全风险。

SDS
Istio 供应身份是通过 secret discovery service(sDs)来实现的:
istiod 提供 GRPC服务以接受证书签名请求(CSRS)当工作负载启动时，Envoy通过秘密发现服务(SDS)AP|向同容器内的 istio-agent 发送证书和密钥请求。在收到 SDS 请求后，istio-agent 创建私钥和 CSR,然后将 CSR 及其凭据发送到 istiod CA 进行签名。
istiod CA 验证 CSR 中携带的凭据，成功验证后签署CSR 以生成证书。
istio-agent 通过 Envoy SDS API将私钥和从 lstio CA收到的证书发送给 Envoy。
istio-agent 会监工作负载证书的有效期。上述 CSR过程会周期性地重复，以处理证书和密钥轮换。

5.基于 lstio 的安全保证

微服务架构下的安全挑战
为了抵御中间人攻击，需要流量加密。
为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略
要确定谁在什么时候做了什么，需要审计工具。

lstio 的安全保证
Istio 安全功能提供:
身份识别;
灵活策略;
透明的 TLS 加密
认证，授权和审计(AAA)工具来保护你的服务和数据。
lstio 安全的目标是:
默认安全:应用程序代码和基础设施无需更改。 

深度防御:与现有安全系统集成以提供多层防御。
零信任网络:在不受信任的网络上构建安全解决方案，

 高层架构
用于密钥和证书管理的证书颁发机构(CA)。
配置 API服务器分发给代理:
·认证策略
授权策略。
安全命名信息
Sidecar 和边缘代理作为 Policy Enforcement Points(PEPS)以保护客户端和服务器之间的通信安全。
-组 Envoy 代理扩展，用于管理遥测和审计。

lstio 安全架构

lstio 身份
身份是任何安全基础架构的基本概念。
在工作负载间通信开始时，双方必须交换包含身份信息的凭证以进行双向验证，在客户端，根据安全命名信息检查服务器的标识，以查看它是否是该服务的授权运行程序。在服务器端，服务器可以根据授权策略确定客户端可以访问哪些信息，审计谁在什么时间访问了什么，根据他们使用的工作负载向客户收费，并拒绝任何未能支付账单的客户访问工作负载。lstio 身份模型使用 service identity(服务身份)来确定一个请求源端的身份。 
lstio 身份
Kubernetes:Kubernetes 服务帐户
GKE/GCE:可以使用 GCP 服务帐户
GCP:GCP 服务帐户
AWS:AWS IAM 用户/角色帐户
0n-premises(非 Kubernetes):用户帐户、自定义服务帐户、服务名称、lstio 服务帐户或 GCP 服务帐户。
Istio 安全与 SPIFFE:
Istio 和 SPIFFE 共享相同的身份文件:SVID(SPIFFE 可验证身份证件)。例如:在 Kubernetes 中。议X.509 证书的 UR|字段格式为 spiffe://<domain>/ns/<namespace>/sa/<serviceaccount>。使 lstio 服务能够建立和接受与其他 SPIFFE 兼容系统的连接。

认证

基于 lstio 的认证
lstio 通过客户端和服务器端 Policy Enforcement Points(PEPS)建立服务到服务的通信通道,PEPS 在lstio 架构中的实现是 Envoy。
Peer authentication :
。用于服务到服务的认证，以验证进行连接的客户端。
lstio 提供双向 TLS 作为传输认证的全栈解决方案，无需更改服务代码就可以启用它。这个解决方案为:为每个服务提供强大的身份，表示其角色，以实现跨群集和云的互操作性。
保护服务到服务的通信。
提供密钥管理系统，以自动进行密钥和证书的生成，分发和轮换，
Request authentication
用于最终用户认证，以验证附加到请求的凭据。
lstio 使用JSON Web Token(JWT)验证启用请求级认证，并使用自定义认证实现或任何0penID Connect 的认证实现(例如下面列举的)来简化的开发人员体验。

Istio 认证架构
未设置模式的网格范围的 peer 认证策略默认使用 PERMISSIVE 模式。
发送请求的客户端服务负责遵循必要的认证机制。
RequestAuthentication
应用程序负责获取 JWT 凭证并将其附加到请求，PeerAuthentication
Istio 会自动将两个 PEPS 之间的所有流量升级为双向 TLS。
如果认证策略禁用了双向 TLS 模式，则 lstio 将继续在 PEPS 之间使用纯文本。
要覆盖此行为，destination rules 显式禁用双向TLS 模式。

双向 TLS 认证
当一个工作负载使用双向 TLS 认证向另一个工作负载发送请求时，该请求的处理方式如下:
。lstio 将出站流量从客户端重新路由到客户端的本地 sidecar Envoy。
客户端 Envoy 与服务器端 Envoy 开始双向 TLS 握手。在握手期间，客户端 Envoy 还做了安全命名检查，以验证服务器证书中显示的服务帐户是否被授权运行目标服务
客户端 Envoy 和服务器端 Envoy 建立了一个双向的 TLS 连接，lstio 将流量从客户端 Envoy转发到服务器端 Envoy。
授权后，服务器端 Envoy 通过本地 TCP 连接将流量转发到服务器服务。

宽容模式(permissive mode)
允许服务同时接受纯文本流量和双向 TLS 流量:
这个功能极大地提升了双向 TLS 的入门体验
在运维人员希望将服务移植到启用了双向 TLS 的 lstio 上时，许多非 lstio 客户端和非 lstio 服务端通信时会产生问题，
通常情况下，运维人员无法同时为所有客户端安装 lstio sidecar，甚至没有这样做的权限。即使在服务端上安装了 Istio sidecar，运维人员也无法在不中断现有连接的情况下启用双向 TLS。

安全命名
服务器身份(serveridentities)被编码在证书里，但服务名称(servicenames)通过服务发现或 DNS 被检索。
安全命名信息将服务器身份映射到服务名称。
身份 A到服务名称 B的映射表示“授权A运行服务 B”
控制平面监视 apiserver，生成安全命名映射，并将其安全地分发到 PEPS。以下示例说明了为什么安全命名对身份验证至关重要，

认证策略
认证策略是对服务收到的请求生效的;
要在双向 TLS 中指定客户端认证策略 需要在 DetinationRule 中设置 TLSSettings.

认证策略
相应的需要通过 PeerAuthentication 配置服务端接受何种认证方式 

认证与未认证身份

 RequestAuthentication

鉴权

授权架构
每个 Envoy 代理都运行一个授权引擎该引擎在运行时授权请求，
当请求到达代理时，授权引擎根据当前授权策略评估请求上下文，并返回授权结果 ALLOW 或 DENY。
授权策略支持 ALLOW 和 DENY 动作拒绝策略优先于允许策略。
如果将任何允许策略应用于工作负载则默认情况下，不符合该策略的访问都将被禁止。

 授权策略(AuthorizationPolicy)

selector字段指定策略的目标
action 字段指定允许还是拒绝请求
rules 指定何时触发动作
rules 下的 from 字段指定请求的来源
·rules 下的 to 字段指定请求的操作
rules下的 when 字段指定应用规则所需的条件

策略目标

值匹配

全部允许和默认全部拒绝授权策略

 自定义条件

在普通 TCP 协议上使用lstio 授权
如果您授权策略中对 TCP 工作负载使用了任何只适用于 HTTP 的字段，lstio 将会忽略它们。