Kubernetes 最佳安全实践指南

原文连接：fuckcloudnative.io/posts/secur…

对于大部分 Kubernetes 用户来讲，安全是可有可无的，或者说没那么紧要，就算考虑到了，也只是敷衍一下，草草了事。实际上 Kubernetes 提供了很是多的选项能够大大提升应用的安全性，只要用好了这些选项，就能够将绝大部分的攻击抵挡在门外。为了更容易上手，我将它们总结成了几个最佳实践配置，你们看完了就能够开干了。固然，本文所述的最佳安全实践仅限于 Pod 层面，也就是容器层面，于容器的生命周期相关，至于容器以外的安全配置（好比操做系统啦、k8s 组件啦），之后有机会再唠。

1. 为容器配置 Security Context

大部分状况下容器不须要太多的权限，咱们能够经过 Security Context 限定容器的权限和访问控制，只需加上 SecurityContext 字段：

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
  image: <image>
+   securityContext:
复制代码

2. 禁用 allowPrivilegeEscalation

allowPrivilegeEscalation=true 表示容器的任何子进程均可以得到比父进程更多的权限。最好将其设置为 false，以确保 RunAsUser 命令不能绕过其现有的权限集。

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
  image: <image>
    securityContext:
  +   allowPrivilegeEscalation: false
复制代码

3. 不要使用 root 用户

为了防止来自容器内的提权攻击，最好不要使用 root 用户运行容器内的应用。UID 设置大一点，尽可能大于 3000。

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  securityContext:
+   runAsUser: <UID higher than 1000>
+   runAsGroup: <UID higher than 3000>
复制代码

4. 限制 CPU 和内存资源

这个就不用多说了吧，requests 和 limits 都加上。

5. 没必要挂载 Service Account Token

ServiceAccount 为 Pod 中运行的进程提供身份标识，怎么标识呢？固然是经过 Token 啦，有了 Token，就防止假冒伪劣进程。若是你的应用不须要这个身份标识，能够没必要挂载：

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
+ automountServiceAccountToken: false
复制代码

6. 确保 seccomp 设置正确

对于 Linux 来讲，用户层一切资源相关操做都须要经过系统调用来完成，那么只要对系统调用进行某种操做，用户层的程序就翻不起什么风浪，即便是恶意程序也就只能在本身进程内存空间那一分田地晃悠，进程一终止它也如风消散了。seccomp（secure computing mode）就是一种限制系统调用的安全机制，能够能够指定容许那些系统调用。

对于 Kubernetes 来讲，大多数容器运行时都提供一组容许或不容许的默认系统调用。经过使用 runtime/default 注释或将 Pod 或容器的安全上下文中的 seccomp 类型设置为 RuntimeDefault，能够轻松地在 Kubernetes 中应用默认值。

apiVersion: v1
kind: Pod
metadata:
  name: <name>
  annotations:
  + seccomp.security.alpha.kubernetes.io/pod: "runtime/default"
复制代码

默认的 seccomp 配置文件应该为大多数工做负载提供足够的权限。若是你有更多的需求，能够自定义配置文件。

7. 限制容器的 capabilities

容器依赖于传统的Unix安全模型，经过控制资源所属用户和组的权限，来达到对资源的权限控制。以 root 身份运行的容器拥有的权限远远超过其工做负载的要求，一旦发生泄露，攻击者能够利用这些权限进一步对网络进行攻击。

默认状况下，使用 Docker 做为容器运行时，会启用 NET_RAW capability，这可能会被恶意攻击者进行滥用。所以，建议至少定义一个PodSecurityPolicy(PSP)，以防止具备 NET_RAW 功能的容器启动。

经过限制容器的 capabilities，能够确保受攻击的容器没法为攻击者提供横向攻击的有效路径，从而缩小攻击范围。

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  securityContext:
  + runAsNonRoot: true
  + runAsUser: <specific user>
  capabilities:
  drop:
  + -NET_RAW
  + -ALL
复制代码

若是你对 Linux capabilities 这个词一脸懵逼，建议去看看个人脑残入门系列：

• Linux Capabilities 入门教程：概念篇
• Linux Capabilities 入门教程：基础实战篇
• Linux Capabilities 入门教程：进阶实战篇

8. 只读

若是容器不须要对根文件系统进行写入操做，最好以只读方式加载容器的根文件系统，能够进一步限制攻击者的手脚。

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
  image: <image>
  securityContext:
  + readOnlyRootFilesystem: true
复制代码

9 总结

总之，Kubernetes 提供了很是多的选项来加强集群的安全性，没有一个放之四海而皆准的解决方案，因此须要对这些选项很是熟悉，以及了解它们是如何加强应用程序的安全性，才能使集群更加稳定安全。

最后，请记住：你须要万分当心你的 YAML 文件内容缩进，若是你的 YAML 文件很是多，眼睛看花了，但愿下面的神器能够助你一臂之力：