基于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 身份。