小楼一夜听春雨，深巷明朝卖杏花

通过以普通用户身份启动Docker镜像中的服务，我们可以有效降低潜在的安全风险，并提高容器的可移植性和可重用性。在Dockerfile中创建一个普通用户，并使用USER命令切换到该用户，然后使用CMD命令定义容器启动时要运行的命令。最后，通过构建和运行容器来启动服务。这些步骤可以帮助我们以更安全和可靠的方式在Docker中运行服务。

或者你的应用长时间不去更新，之前有些安全的保障手段，随着时间的推移就变的不安全了，那么这个时候容器镜像也会面临风险，比如openssl 1.0，随着时间的推移都被证明不安全，其实都是有安全漏洞和版本问题才会向前演进。我有应用装到容器里面来了，那么为了保证容器镜像的安全，我就要去看除了应用本身是否安全，我还要看应用所依赖的中间件是否安全，我还要看它基础镜像，比如一个操作系统的话，我还要知道这个操作系统安装的这些包是不是安全的。如果是依赖的基础服务本身有安全问题，那么这个容器镜像也是不安全的。

限制pod使用安全相关的特性 已经介绍了如何在部署 pod时在任一宿主节点上做任何想做 的事。 比如， 部署一个特权模式的 pod 。 很明显， 需要有一种机制阻止用户使用其中的部分功能。 集群管理入员可以通过创建 PodSecurityPolicy资源来限制对以上提到的安全相关的特性的使用。PodSecurityPolicy资源介绍 PodSecurityPolicy 是一种集群级别（无命名空间）的资源， 它定义了用户能否在 pod 中使用各种安全相关的特性。 维护 PodSecu

容器使用不同用户运行时共享存储卷使用存储卷在pod的不同容器中共享数据。可以顺利地在一个容器中写入数据，在另 一个容器中读出这些数据。但这只是因为两个容器都以root用户运行，对存储卷中的所有文件拥有全部权限。现在假设使用前面介绍的runAsUser选项。你可能需要在一个pod中用两个不同的用户运行两个容器（可能是两个第三方的容器，都以它们自己的特定用户运行进程）。如果这样的两个容器通过存储卷共享文件，它们不一定能够读取或写入另 一个容器的文件。因此，Kubemetes允许...

过去， 传统的 UNIX 实现只区分特权和非特权进程， 但是经过多年的发展， Linux已经可以通过内核功能支持更细粒度的权限系统。相比于让容器运行在特权模式下以给予其无限的权限， 一个更加安全的做法是只给予它使用真正需要的内核功能的权限。Kubernetes允许为特定的容器添加内核功能， 或禁用部分内核功能， 以允许对容器进行 更加精细的权限控制， 限制攻击者潜在侵入的影响。例如， 一个容器通常不允许修改系统时间（硬件时钟的时间）。 可以通过在pod-with-defaults-pod中修.

使用特权模式运行 pod有时pod 需要做它们的宿主节点上能够做的任何事，例如操作被保护的系统设备，或使用其他在通常容器中不能使用的内核功能 ，这种 pod 个样例就是 kube-proxy pod ，该 pod需要修改宿主机的 iptables规则来让 kubernetes 中的服务规生效。使用 kubeadm 部署集群时，你会看到每个节点上都运行了 kube-proxy pod，并且可 以查 YAML描述文件中所有使用到的特殊特性。[root@k8s-master ~]# ..

配置节点的安全上下文 除了让 pod 使用宿主节点的 Linux 命名空间，还可以在 pod 或其所属容器的描述中通过 security Context 边项配置其他与安全性相关的特性。这个选项可以运用于整个 pod ，或者每个 pod 中单独的容器。了解安全上下文中可以配置的内容，配置安全上下文可以允许你做很多事 指定容器中运行进程的用户（用户ID ）。 阻止容器使用 root 户运行（容器的默认运行用户通常在其镜像中指定，所以可能需要阻止容器 root 用户运行 使用特权模式运行

k8s 内置的集群角色 systemk8s为了让用户使用某些特定的权限，给大家预留了四个集群角色，这个是可以是直接使用的。以system开头的都是k8s内置的，不要随便删除，删除了可能导致集群功能不正常[root@k8s-master ~]# kubectl get clusterroleNAME CREATED ATsystem:aggregate-to-.

What are Kubernetes audit logs?Audit logsrecord requests to theKubernetes API. Because the API server processes all changes to Kubernetes state—and serves as the gatekeeper to the backend database that stores this state—the API server is an ideal po.....

本文将主要分享以下五方面的内容：缘起：安全容器的命名 间接层：安全容器的精髓 Kata Containers：云原生化的虚拟化 gVisor：进程级虚拟化 安全容器：不止于安全一、缘起：安全容器的命名Phil Karlton 有一句名言：“计算机科学界只有两个真正的难题——缓存失效和命名。”对我们容器圈而言，我相信「命名」绝对配得上这句话。这毫无疑问是一件让老开发者沉默、让新人落泪的事情。仅就系统软件而言，我们当今比较通行地称为「Linux 容器技术」这个概念，它曾经用过的名字还.

分析容器系统调用：SysdigSysdig：一个非常强大的系统监控、分析和故障排查工具。 汇聚 strace+tcpdump+htop+iftop+lsof 工具功能于一身！(核心的功能就是将工具整合在一块)sysdig 除了能获取系统资源利用率、进程、网络连接、系统调用等信息， 还具备了很强的分析能力，例如： • 按照CPU使用率对进程排序 • 按照数据包对进程排序 • 打开最多的文件描述符进程 • 查看进程打开了哪些文件 • 查看进程的HTTP请求报文 • 查看机器

Admission Webhook：准入控制器Webhook是准入控制插件的一种，用于拦截所有向APISERVER发送的请求，并且可以修改请求或拒绝请求。 Admission webhook为开发者提供了非常灵活的插件模式，在kubernetes资源持久化之前，管理员通过程序可以对指定资源做校验、修改等操作。例如为资源自动打标签、pod设置默认SA，自动注入sidecar容器等。 相关Webhook准入控制器： • MutatingAdmissionWebhook：修改资源，理论上可以监

检查YAML文件安全配置：kubesec kubesec：是一个针对K8s资源清单文件进行安全配置评估的工具，根据安全配置最佳实践来验证并给出建议。 官网：https://kubesec.io 项目地址：https://github.com/controlplaneio/kubesec[root@master ~]# mv kubesec /usr/bin/下面每个id给你标识了安全建议 ，下面给出了配置的最佳实践示例： [root@master k8s]# kubes

可信任软件供应链概述 可信任软件供应链：指在建设基础架构过程中，涉及的软件都是可信任的。在K8s领域可信软件供应链主要是指镜像，因为一些软件交付物都是镜像，部署的最小载体。镜像构建要写dockefile去构建，默认收以root账号权限去运行的，如果你不清楚这一块，那么这块的风险就已经放开了构建镜像Dockerfile文件优化 • 减少镜像层：一次RUN指令形成新的一层，尽量Shell命令都写在一行，减少镜像层。 • 清理无用文件：清理对应的残留数据，例如yum缓存，减..

已经测试过的应用和工具：https://gvisor.dev/docs/user_guide/compatibility/这里可以看到现有的哪些应用可以使用gvisor，因为官方已经给你测试了。除此之外不能够百分之百去使用。除此之外还有哪些工具是可以使用的。安全沙箱运行容器：gVisor与Containerd集成由docker切换到containerd容器引擎（安装conatinerd------>kubelet安装containerd----->最后验证）在切换之..

现在容器通过什么技术实现的隔离1.使用Linux namespace和cgroup技术隔离容器2.Linux内核是共享的使用的容器不是强隔离的环境，和虚拟机是无法媲美的，虚拟机从硬件到软件，再到内核是完全的隔离，而容器只隔离了一部分。降低容器的安全风险：（1）AppArmor:限制容器中的进程访问系统文件权限（2）Seccomp:过滤容器当中的进程对linux的系统调用（3）Capabilities:限制容器中的进程对Linux的内核系统调用能力（root权限进行逻辑划分，针

在 Kubernetes 中安全地运行工作负载是很困难的，有很多配置都可能会影响到整个 Kubernetes API 的安全性，这需要我们有大量的知识积累来正确的实施。Kubernetes 在安全方面提供了一个强大的工具securityContext，每个 Pod 和容器清单都可以使用这个属性。在本文中我们将了解各种securityContext的配置，探讨它们的含义，以及我们应该如何使用它们。securityContext设置在PodSpec和ContainerSpec规范中都有定义，...

在 Kubernetes 中安全地运行工作负载是很困难的，有很多配置都可能会影响到整个 Kubernetes API 的安全性，这需要我们有大量的知识积累来正确的实施。Kubernetes 在安全方面提供了一个强大的工具securityContext，每个 Pod 和容器清单都可以使用这个属性。在本文中我们将了解各种securityContext的配置，探讨它们的含义，以及我们应该如何使用它们。securityContext设置在PodSpec和ContainerSpec规范中都有定义，...

通过这种方式在yaml文件里面来指定mysql的密码现然是不安全的，mysql可以读取注入的变量MYSQL_ROOT_PASSWORD值作为其密码，以为describe一下就能够看得到。Secret是一个用于存储敏感数据的资源，所有的数据要经过base64编码，数据实际会存储在K8s中Etcd， 然后通过创建Pod时引用该数据。• generic：从文件、目录或者字符串创建，例如存储用户名密码。• docker-registry：存储镜像仓库认证信息。• tls：存储证书，例如HTTPS证书。

什么是 Pod 安全策略？Pod 安全策略（Pod Security Policy）是集群级别的资源，它能够控制 Pod 规约 中与安全性相关的各个方面。PodSecurityPolicy对象定义了一组 Pod 运行时必须遵循的条件及相关字段的默认值，只有 Pod 满足这些条件 才会被系统接受。 Pod 安全策略允许管理员控制如下方面：控制的角度 字段名称 运行特权容器 privileged 使用宿主名字空间 hostPID、hostIPC 使用宿主的网络和端口...

第一步PodSecurityPolicy（简称PSP）：Kubernetes中Pod部署时重要的安全校验手段，能够 有效地约束应用运行时行为安全。 使用PSP对象定义一组Pod在运行时必须遵循的条件及相关字段的默认值，只有Pod满足这 些条件才会被K8s接受。（在部署的时候去校验的，在运行的时候是不管的，当你创建podd的时候会去校验）Pod安全策略限制维度Pod安全策略限制维度：在之前的行为在yaml里面写一些安全配置都是有意识的去选择，如果k8s集群是别人使..

安全上下文（Security Context）：K8s对Pod和容器提供的安全机制，可以设置Pod特权和访问控制。背景：容器中的应用程序默认以root账号运行的，这个root与宿主机root账号是相同的， 拥有大部分对Linux内核的系统调用权限，这样是不安全的，所以我们应该将容器以普 通用户运行，减少应用程序对权限的使用。（容器是宿主机上面的进程，该进程有r非常大的权限，容器只是在宿主机上面封装了状态，也是一个实际进程）可以通过两种方法设置普通用户： • Dockerfi

Seccomp（Secure computing mode） 是一个 Linux 内核安全模块，可用于应用进程允许使用的系统调用。 容器实际上是宿主机上运行的一个进程，共享宿主机内核，如果所有容器都具有任何系统调用的能力，那么容器如果被入侵，就很轻松绕过容器隔离更改宿主机系统权限或者进入宿主机。 这就可以使用Seccomp机制限制容器系统调用，有效减少攻击面。 Linux发行版内置：CentOS、Ubuntu在Kubernetes中使用Seccomp：Seccomp在K8

最小特权原则（POLP） 最小特权原则 (Principle of least privilege，POLP) ：是一种信息安全概念，即为用户提供执行其工作职责所需的最小权限等级或许可。 最小特权原则被广泛认为是网络安全的最佳实践，也是保护高价值数据和资产的特权访问的基本方式。最小特权原则 (POLP) 重要性• 减少网络攻击面：当今，大多数高级攻击都依赖于利用特权凭证（提权）。通过限制超级用户和管理员权限，最小权限执行有助于减少总体网络攻击面。 • 阻止恶意软件的传播：

资源配额 LimitRange默认情况下，K8s集群上的容器对计算资源没有任何限制，可能会导致个别容器资源过大导致影响其他容器正常工作，这时可以使用LimitRange定义容器默认CPU和内存请求值或者最大上限。(默认是使用宿主机上面所有的资源)在哪个命名空间下面创建，那么就是应用在哪个命名空间。LimitRange限制维度： • 限制容器配置requests.cpu/memory，limits.cpu/memory的最小、最大值 • 限制容器配置requests.cpu/

网络策略介绍 默认情况下，Kubernetes 集群网络没任何网络限制，Pod 可以与任何其他 Pod 通信，在某 些场景下就需要进行网络控制，减少网络攻击面，提高安全性，这就会用到网络策略。 网络策略（Network Policy）：是一个K8s资源，用于限制Pod出入流量，提供Pod级别和 Namespace级别网络访问控制。 网络策略的应用场景： • 应用程序间的访问控制，例如项目A不能访问项目B的Pod • 开发环境命名空间不能访问测试环境命名空间Pod • 当P

CIS安全基准 互联网安全中心（CIS，Center for Internet Security），是一个非盈利组织，致力为互联网提供免费的安全防御解决方案。 官网：https://www.cisecurity.org/ Kubernetes CIS基准：https://www.cisecurity.org/benchmark/kubernetes/对每个组件定义了安全配置，针对每个组件都有具体的规则和建议如何更加规范的配置保证集群的安全。CIS基准测试工具 下载.

• 安全运维的重要性 • SecDevOps • K8s提供的安全机制 • K8s安全运维实践思路

Security Context 的使用CVE-2019-5736通过对 GitHub 上的统计结果可以看到，主流的业务镜像有 82.4% 是以 root 用户来启动的。通过这个调查可以看到对 Security Context 的相关使用是不容乐观的。Kubernetes Runtime 安全策略经过对上面的分析结果可以看出来，如果我们对业务容器配置安全合适的参数，其实攻击者很难有可乘之机。那么我们究竟应该在部署 Kubernetes 集群中的业务容器做哪些 runtime 运行时.

认证与授权对任何安全系统来说都至关重要，Kubernetes 也不例外。即使我们不是安全工作人员，也需要了解我们的 Kubernetes 集群是否具有足够的访问控制权限。Kubernetes 社区也越来越关注容器的安全评估（包括渗透测试，配置审计，模拟攻击），如果你是应用安全工程师，或者是安全感知的 DevOps 工程师，最好了解一下 Kubernetes 的授权模型。Kubernetes 的授权控制原则与大多数系统一样：在授予访问权限时采用最小授权原则。例如，如果某个 Pod 使用了特定的servi.

ServiceAccount 介绍接下来，我们讲一下 ServiceAccount。ServiceAccount 首先是用于解决 pod 在集群里面的身份认证问题，身份认证信息是存在于 Secret 里面。[root@k8s-master ~]# kubectl get secretNAME TYPE DATA AGEdefault-token-j9294 kubernetes.io/s

本文将主要分享以下三方面的内容：Kubernetes API 请求访问控制 Kubernetes 认证 Kubernetes RBAC Security Context 的使用一、Kubernetes API 请求访问控制访问控制大家都知道访问控制是云原生中的一个重要组成部分。也是一个 Kubernetes 集群在多租户环境下必须要采取的一个基本的安全架构手段。那么在概念上可以抽象的定义为谁在何种条件下可以对什么资源做什么操作。这里的资源就是在 Kubernetes 中我们.

你已经学会了使用kubectl命令行，或者直接发送 REST 请求，以及使用各种语言的 client 库来跟 APIServer 进行交互。那么你是否知道在这其中Kubernetes 是如何对这些请求进行认证、授权的呢？这节课，我们就来一探究竟。任何请求访问 Kubernetes 的 kube-apiserver 时，都要依次经历三个阶段：认证（Authentication，有时简写成 AuthN）、授权（Authorization，有时简写成 AuthZ）和准入控制（Admission Contr..

在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式。以kubectl为例介绍kubeconfig的配置。kubectl只是个go编写的可执行程序，只要为kubectl配置合适的kubeconfig，就可以在集群中的任意节点使用。kubectl默认会从$HOME/.kube目录下查找文件名为config的文件，也可以通过设置环境变量KUBECONFIG或者通过设置--kubeconfig...

kubeconfig配置文件在node节点上可以执行kubectl命令吗？[root@k8s-node1 ~]# kubectl get nodeThe connection to the server localhost:8080 was refused - did you specify the right host or port?localhost:8080这个端口是k8s api（kube-apiserver非安全端口）的端口，在master上面可以执行成功其...

机制说明Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的。Kubernetes 使用了认证（Authentication）、鉴权（Authorization）、准入控制（AdmissionControl）三步来保证API Server的安全。当用户或者pod访问apiserver的时候来镜像身份的识别，这