携手创造，一起生长！这是我参与「日新方案 8 月更文应战」的第十天， <<点击检查活动概况>>
今天叶秋学长带领我们学习云原生系列三：10大K8s运用安全加固技能~
本文译自Top 10 Kubernetes Application Security Hardening Techniques[1]。作者：Rory McCune
修改
将运用部署到K8s集群时，开发者面对的主要应战是怎么管理安全危险。快速解决此问题的一个好办法是在开发进程中对运用清单进行安全加固。本文，将介绍10种开发者能够对运用程序运用加固的办法。
以下技能答应在开发进程中测验强化版别，从而降低在出产环境中运用的控件对运转作业负载形成晦气影响的危险。此外，没有强制性操控的集群中，比如Pod安全战略，自愿加固能够协助降低容器打破攻击的危险。
一般办法
在编写K8s作业负载清单时，无论是pod目标仍是部署daemonset之类的更高等级的东西，清单中都有一个名为securityContext的部分，答应您指定应该运用于作业负载的安全参数。
例如，下面的代码显现了一个更改其功用
修改
下面将具体介绍这些不同部分的作业原理，但从这儿你能够看到运用的一般结构。
runAsUser, runAsGroup
默许情况下，Docker容器以root用户的身份运转，从安全视点看这并不理想。尽管对容器内部的拜访权限仍有约束，但在过去一年中，出现了多个容器缝隙，只有在容器以root用户身份运转时才能运用这些缝隙，保证一切容器以非root用户身份运转是一个很好的加固进程。
在基本层面上，在pod清单中装备这个是适当简略的。最好的办法是将security Context中的runAsUser和runAsGroup字段设置为非0值。
修改
可是，在执行此操作时，重要的是要保证容器在以非root用户身份运转时能够正常作业。假如原始容器镜像被规划为以root身份运转，并且有约束性的文件权限，或许会导致运用程序的运转出现问题。
最好的办法是保证在容器的Dockerfile中设置相同的UID/GID组合，以便在整个开发和测验进程中运用该组合运转。能够经过在Dockerfile中设置USER指令来做到这一点。按照上面的示例，此行将设置相同的 UID和GID组合：
修改
Privileged
Docker和类似的容器运转时供给Privileged标志，作为从容器中移除安全阻隔的快捷办法。这不应该在运用作业负载中运用，而应该只在完全必要的情况下运用。
一般来说，Linux容器有适当灵敏的安全模型，因此假如容器的运转需求特定的权限，则能够增加该权限，而无需运用总括Privileged设置。
在规划容器清单时，关键是在每个清单的 securityContext 中默许将 privileged 设置为 false，这样就能够清楚地看到它应该在没有这些权限的情况下运转。
修改
Capabilities
Linux才能是用于为进程供给传统上为root用户保留的一个或多个方面的权限。默许情况下，Docker和其他容器运转时将为容器供给可用才能的子集。
一个好的加固进程是仅答应运用程序特别需求的才能。假如你的运用程序规划为以非root用户身份运转，那么它根本不需求任何才能。
一般来说，对才能的处理办法应该是首要删去一切的才能，假如你的运用需求这些才能，再把特定的才能加回来。举个比如，假如你需求CHOWN才能，你会有这样的securityContext：
修改
Read Only Root File system
你能够运用这个设置来运用容器的短暂性。一般，运转中的容器不应该在容器文件体系中存储有关运用程序的任何状态。这是由于它们或许随时被降速并在集群的其他地方创建新版别。
在这种情况下，你能够在作业负载清单中设置readOnlyRootFilesystem标志，这将使容器的根文件体系成为只读。这或许会让那些在发现运用缝隙后企图在容器中安装工具的攻击者感到懊丧。
与此设置有关的一个常见问题是怎么处理运用程序进程运转时需求的临时文件。处理这些的最佳办法是在容器中挂载一个 emptyDir 卷，答应文件被写入某个位置，然后在容器被销毁时自动删去。
设置 readOnlyRootFilesystem 是 securityContext 中一个简略的布尔值。
修改
AllowPrivilegeEscalation
Linux内核揭露的另一个安全设置，这一般是一个很好的、低影响的加固选项。此标志操控子进程是否能够获得比其父进程更多的权限，关于在容器中运转的运用进程来说，它们的运转很少需求这样做。
修改
Seccomp
清单最终一个值得重视的安全层是Seccomp。Seccomp装备文件能够阻止拜访或许导致安全危险的特定Linux体系调用。默许情况下，Docker等容器运转时供给了一个体系调用过滤器，能够阻止对一些特定调用的拜访。可是，在K8s下运转时，该过滤器在默许情况下是禁用的。
因此，保证从头启用过滤器是对作业负载清单的重要补充。你能够运用运转时的默许装备文件，或许（如AppArmor和SELinux）供给一个自定义的装备文件。
修改
在1.19及更高版别中，seccomp过滤器已被集成到securityContext字段中，因此要设置一个pod运用默许的seccomp过滤器，你能够运用下面的办法：
修改
Resource limits
由于K8s作业负载共享底层节点，因此保证单个容器不能运用节点上的一切资源非常重要，这或许会导致集群中运转的其他容器出现性能问题。在容器层面，能够设置资源约束，指定容器所需的资源数量以及答应的资源数量约束。
一个容器资源恳求的示例如下。这不是在 securityContext 中设置的，而是在通用容器规范中设置的。
修改尽管内存恳求和约束是适当直截了当的，但CPU的约束或许不那么显着。它们实际上是以 “毫秒 “为单位的，其中1,000等于一个CPU中心或超线程。因此，在上面的比如中，恳求是针对一个中心的25%，而约束是针对一个内核的50%。规划资源约束时要注意的另一件事是，容器运转时超出约束将怎么反应。关于CPU来说，进程将受到约束，有效地降低了它的性能。可是，假如超过了内存约束，容器或许会终止进程，所以保证约束契合运用程序在正常操作中或许合理的恳求内容非常重要。
imageTag
Docker风格的容器一般是经过供给镜像名称和标签名称来指定。Docker有一个特殊情况，便是假如没有指定标签，就会运用 “latest “标签。可是，跟着镜像注册表的更新，运用的确切的镜像或许会改变。例如，假如一个操作体系有了新的版别，最新的标签或许会改变为新版别。
这种缺少固定目标的情况下使得指定要在pod中运用的容器镜像时，运用未指定的标签或特别是 “latest “标签是个坏主意。相反，运用一个明确的标签，你能够运用注册表中存在的命名标签，或许运用唯一标识它的SHA-256哈希值来指定一个镜像，来做到这一点。
运用第一个选项，为每个容器指定镜像和标签。这种办法，仍然依赖于维护者不以损害部署的方法修改镜像，由于标签一般是可变的指针，能够被重定向到另一个镜像。
修改假如你指定了SHA-256哈希值，则仅运用与该哈希值特别对应的镜像。但这是一个高维护选项，由于每次修补镜像时都有必要更新清单以反映新的哈希值。
在编撰本文时，与上述指定镜像等效的是：
修改
AppArmor
该选项适用于运用AppArmor的Linux发行版（主要是Debian衍生的发行版别）。AppArmor能够增加一个强制性的安全执行等级，即便其他阻隔层失败或被攻击者绕过，也能供给保护。
假如你不指定AppArmor战略，容器运转时的默许值将适用，因此在许多情况下，无需向运用程序清单增加明确的声明。可是，假如你的确想增加自定义的AppArmor装备文件来进一步加固你的容器，则需求注意的是，与大多数其他加固设置不同，它不在securityContext字段中设置。相反，它是经过清单元数据中的自定义注解来完结的（在K8s的未来版别中有一个更改此行为的提案）。
指定的装备文件有必要提早放在集群节点上，然后在下面的比如中代替指定。
修改
SELinux
这个选项适用于运用SELinux的Linux发行版（主要是Red Hat系列）。SELinux的作业方法类似于AppArmor，为进程增加了额定的安全层。
可是，装备战略稍微复些，而且它将取决于容器运转时和主机操作体系的组合是否启用。
与AppArmor一样，创建自定义SELinux战略在安全性更高的环境中或许很有用，但在大多数情况下，运用默许战略将供给有用的额定安全层。
总结
创建一个安全的K8s环境有很多方面，从操控平面到集群上运转的运用程序。主动加固用于部署作业负载的K8s清单是这一进程的重要组成部分，假如在开发生命周期的前期完结，能够明显进步安全性并降低缝隙危险。
引证链接
[1]
原文链接:blog.aquasec.com/kubernetes-…
本期分享到期停止，重视博主不迷路，叶秋学长带你上高速~~
