本篇内容主要讲解“部署一个安全的kubernetes应用建议有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“部署一个安全的kubernetes应用建议有哪些”吧!
kubernetes提供了许多能有效提升你的应用安全性的规则。配置这些规则需要你精通kubernetes，并且明确部署的安全需求。此处我们强调的最佳实践指的是容器的生命周期管理：构建，打包和运行，并且特指kubernetes的部署。
用有漏洞的镜像来跑容器会使你的环境面临更容易被攻破的风险。确保你的所有软件都没有已知漏洞，就能减少很多攻击。
进行持续的安全漏洞扫描——容器可能包含那些过期的携带已知漏洞的包。漏洞扫描不能只是个一次性过程，因为新的漏洞每天都在发布。一个持续评估镜像安全性的过程，对确保一个必要的安全态势是至关重要的。
定期对环境进行安全更新——一旦运行中的容器发现了漏洞，你必须更新源镜像并重新部署容器。尽量避免直接更新运行中的容器（如使用 apt-update），因为这会破坏镜像和容器的关系。使用 kubernetes 的 rolling update 特性来升级容器是相当简单的，它允许逐步更新运行中的应用，通过更新镜像到最新版本。
如果不能确保只允许附带组织策略的镜像运行，那么该组织将冒着运行有漏洞甚至是恶意容器的风险。从未知源下载并运行镜像是危险的。这相当于在生产环境服务器上运行未知供应商提供的软件。千万不要这么做。
使用私有仓库来存储你的认证过的镜像，并确保只上传认证过的镜像到这些私有仓库。单单这条就已经缩小范围了，它从成千上万的公开可用的镜像中减少到只剩一部分潜在的镜像可以进入到你的流水线。构建一条 CI 流水线来集成安全评估（比如漏洞扫描），使它成为构建过程的一部分。
CI 流水线必须确保只有评审过的代码（允许上生产环境）才能用来构建镜像。一旦镜像构建好，它必须扫描安全漏洞，并且只有当没发现问题时，这个镜像才能被上传到私有仓库，从该仓库中部署到生产环境就完成了。安全评估中的失败应该在流水线中创建一个失败，从而阻止差的安全质量的镜像上传到镜像仓库。
Kubernetes 的镜像认证插件正在完工中（期望在 Kubernetes 1.4 中完工），它将允许阻止未认证的镜像打包。
你应该限制对 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" } } }在设计容器和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
当你要用提升的权限（--privileged）来运行容器的时候，你应该考虑使用“DenyEscalatingExec”接入控制。这个控制拒绝 exec 和 attach 命令发到 pod ，那些pod用提升权限在运行，允许主机访问。这些pod包括以特权运行的，对主机IPC命名空间有访问权限的，以及对主机PID命名空间有访问权限的。
kubernetes提供基于集群的日志，允许记录容器活动到一个中央日志仓库。当一个集群创建的时候，每个容器的标准输出和标准错误输出都可以通过一个运行在每个节点上的Fluentd代理获取到，这些输出被输入到谷歌Stackdriver日志系统或者Elasticsearch，并通过Kibana来查看。
到此，相信大家对“部署一个安全的kubernetes应用建议有哪些”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
