Kubernetes，并且明确部署的安全需求。此处我们强调的最佳实践指的是容器的生命周期管理：构建，打包和运行，并且特指Kubernetes的部署。我们在我们自己的SaaS部署（http://t.cn/RIcMXd7）中采用了这些最佳实践，它是运行在谷歌云平台上的Kubernetes。
以下就是我们关于部署一个安全的Kubernetes应用的建议。
确保镜像没有漏洞
用有漏洞的镜像来跑容器会使你的环境面临更容易被攻破的风险。确保你的所有软件都没有已知漏洞，就能减少很多攻击。
-
进行持续的安全漏洞扫描——容器可能包含那些过期的携带已知漏洞的包。漏洞扫描不能只是个一次性过程，因为新的漏洞每天都在发布。一个持续评估镜像安全性的过程，对确保一个必要的安全态势是至关重要的。
-
定期对环境进行安全更新——一旦运行中的容器发现了漏洞，你必须更新源镜像并重新部署容器。尽量避免直接更新运行中的容器（如使用 apt-update），因为这会破坏镜像和容器的关系。使用 Kubernetes 的 rolling update 特性来升级容器是相当简单的，它允许逐步更新运行中的应用，通过更新镜像到最新版本。
确保环境中只使用授权的镜像
如果不能确保只允许附带组织策略的镜像运行，那么该组织将冒着运行有漏洞甚至是恶意容器的风险。从未知源下载并运行镜像是危险的。这相当于在生产环境服务器上运行未知供应商提供的软件。千万不要这么做。
使用私有仓库来存储你的认证过的镜像，并确保只上传认证过的镜像到这些私有仓库。单单这条就已经缩小范围了，它从成千上万的公开可用的镜像中减少到只剩一部分潜在的镜像可以进入到你的流水线。构建一条 CI 流水线来集成安全评估（比如漏洞扫描），使它成为构建过程的一部分。
CI 流水线必须确保只有评审过的代码（允许上生产环境）才能用来构建镜像。一旦镜像构建好，它必须扫描安全漏洞，并且只有当没发现问题时，这个镜像才能被上传到私有仓库，从该仓库中部署到生产环境就完成了。安全评估中的失败应该在流水线中创建一个失败，从而阻止差的安全质量的镜像上传到镜像仓库。
Kubernetes 的镜像认证插件正在完工中（期望在 Kubernetes 1.4 中完工），它将允许阻止未认证的镜像打包。详情请看这个 pull request（https://github.com/kubernetes/kubernetes/pull/27129）。
限制对 Kubernetes 节点的直接访问
你应该限制对Kubernetes 节点的 SSH 访问，减少主机资源未认证就被访问的风险。相应的，你应该要求用户使用 kubectl exex 命令来访问，它将提供对容器环境的直接访问，而不涉及对主机的访问。
你可以使用 Kubernetes 的授权插件来进一步控制用户的资源访问权限。它允许对特定的命名空间，容器和操作定义细粒度访问的控制规则。
资源之间创建管理边界
限制用户权限的范围可以减少误操作或者恶意操作的影响。Kubernetes 的命令空间允许你将已创建的资源划分成逻辑命名组。一个命名空间内创建的资源可以和其它命名空间隔离开。默认情况下，用户在Kubernetes集群中创建的每个资源都在default命名空间下。你可以创建额外的命名空间并将资源和用户挂到该空间下。你可以通过Kubernetes的授权插件（Authorization plugins）创建策略，隔离不同用户对空间下的资源的访问权限。
例如，以下策略允许“alice”读取命名空间“fronto”下的 pods。
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "alice",
"namespace": "fronto",
"resource": "pods",
"readonly": true
}
}
定义资源配额
运行资源不受限的容器会使你的系统面临DoS或者“吵闹的邻居（noisy neighbor）”的风险。为了阻止或者最小化这些风险，你应该定义资源配额。默认情况下，Kubernetes集群中创建的所有资源都不限制CPU和内存。你可以创建资源配额策略并关联到命名空间下，以限制pod对CPU和内存的消耗。
以下是命名空间下资源配额定义的例子，它限制了该命令空间下，pod数量为4，总的CPU使用为1到2个，总的内存为1到2G。
compute-resources.yaml:
apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: pods: "4" requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi
将资源配额关联到命名空间方法如下：
kubectl create -f ./compute-resources.yaml --namespace=myspace
实现网络分割
不同的应用都运行在同一个Kubernetes集群中，会面临一个缺乏抵抗力的应用攻击它的邻居应用的风险。网络分割对确保容器只能和那些它们允许访问的容器交流来说就很重要。
Kubernetes部署中的其中一个挑战就是在pod，服务和容器间创建网络分割。说它是挑战，是因为容器网络标识（IPs）的“动态”本质，以及另一个事实，即容器可以在同一节点和不同节点间通信。
谷歌云平台的用户受益于平台的自动防火墙规则，可以阻止跨集群的通信。使用网络防火墙或者SDN方案，我们也可以在本地部署一个相似的实现。Kubernetes的网络SIG正在该领域做相关工作，它能明显改善pod和pod间通信的策略。一个新的网络策略API应该满足用户的需求，在pod间创建防火墙规则，以限制容器间的网络访问。
以下是个网络策略的例子，它控制”backend”pod的网络，只允许“frontend”pod 的网络访问。
POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys
{
"kind": "NetworkPolicy",
"metadata": {
"name": "pol1"
},
"spec": {
"allowIncoming": {
"from": [{
"pods": { "segment": "frontend" }
}],
"toPorts": [{
"port": 80,
"protocol": "TCP"
}]
},
"podSelector": {
"segment": "backend"
}
}
}
更多网络策略请参考这里（http://blog.kubernetes.io/2016/04/Kubernetes-Network-Policy-APIs.html）。
给pod和容器使用安全上下文
在设计容器和pod的时候，请确保为你的pod，容器和volumes配置了安全的上下文。一个安全的上下文是部署yaml中定义的一个属性。它控制了将赋给pod/容器/volume的安全参数。某些重要参数如下：
Security Context Setting Description SecurityContext->runAsNonRoot Indicates that containers should run as non-root user SecurityContext->Capabilities Controls the Linux capabilities assigned to the container. SecurityContext->readOnlyRootFilesystem Controls whether a container will be able to write into the root filesystem. PodSecurityContext->runAsNonRoot Prevents running a container with ‘root’ user as part of the pod
以下是一个带安全上下文参数的pod定义例子：
apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: # specification of the pod’s containers # ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true
请参考这里（http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_podsecuritycontext）。
当你要用提升的权限（–privileged）来运行容器的时候，你应该考虑使用“DenyEscalatingExec”接入控制。这个控制拒绝 exec 和 attach 命令发到 pod ，那些pod用提升权限在运行，允许主机访问。这些pod包括以特权运行的，对主机IPC命名空间有访问权限的，以及对主机PID命名空间有访问权限的。关于接入控制的更多细节请参考Kubernetes文档（http://kubernetes.io/docs/admin/admission-controllers/）。
每个地方都记录日志
Kubernetes提供基于集群的日志，允许记录容器活动到一个中央日志仓库。当一个集群创建的时候，每个容器的标准输出和标准错误输出都可以通过一个运行在每个节点上的Fluentd代理获取到，这些输出被输入到谷歌Stackdriver日志系统或者Elasticsearch，并通过Kibana来查看。
总结
Kubernetes应用了许多选项来创建安全的部署。不存在一刀切的解决方案，适用于任何地方。因此对这些选项要有一定的熟悉度，以及理解它们如何增强你的应用的安全性。
我们建议使用本文强调的那些最佳实践，使用Kubernetes的灵活配置能力将安全过程并入到持续集成流水线中，使得整个过程能自动化得无缝接入。
原文链接：Kubernetes部署的最佳安全实践，转载请注明来源！