Kubernetes的五种安全实践

这种情况很糟糕。你可以随时通过加密secrets来缓解它。如果可能的话，你也应该把这个secret与镜像或pod分开。一种方法是将进程拆分为单独的容器。例如，可以将应用程序分为前端容器和后端容器。后端具有私钥secret并响应来自前端的签名请求。

除非您既是安全管理员又是Kubernetes管理员，否则必须使用第三方秘密工具来保护您的secret。其中包括AWS Secrets Manager，Google Cloud Platform KMS和用于公共云的Azure Key Vault。而且，程序如Hashicorp Vault, CyberArk/Conjur, Confidant和Aqua Security Kubernetes Security for the Enterprise。

5.保持网络安全

从上面可以看出，允许访问etcd非常危险。正如Kubernetes安全企业ControlPlane的联合创始人Andrew Martin 在Kubernetes自己的博客中写道：“ 对API服务器的etcd的写访问权限等同于在整个集群上获得root权限，甚至可以很容易的使用读访问权限公平地提升特权。”

因此，Martin建议：“ etcd应该配置有peer和客户端TLS证书，并部署在专用节点上。为避免私钥被从工作节点窃取和使用，集群也可以通过防火墙连接到API服务器。

不仅etcd需要网络保护。由于Kubernetes完全由API驱动，因此默认情况下，所有内部集群通信均使用TLS加密。

但是，这还不够。默认情况下，Kubernetes Pod接受来自任何来源的流量。在此重复一遍：“任何来源。” Pod已开放用于网络连接，这并不安全。由您决定网络策略，该策略可以安全地定义Pod如何在群集内以及与外部资源进行通信。

您可以通过添加支持网络策略控制器的网络插件来实现。如果没有这样的控制器，您设置的任何网络策略都不会生效。不幸的是，Kubernetes默认没有官方默认甚至首选的网络策略控制器。相反，您必须使用第三方插件，如Calico，Cilium，Kube-router，Romana或Weave Net。不管怎样，我最喜欢的是Calico。

我建议您从**“默认拒绝所有**”网络策略开始。这样，仅允许您随后明确允许的与其他网络策略规则的连接。由于网络策略是在namespace中设置的，因此您需要为每个namespace设置网络策略。

设置完成后，您可以开始允许适当的网络访问规则。更多可以参考 【Kubernetes Network Policy Recipes】(https://github.com/ahmetb/kubernetes-network-policy-recipes)。

确保Kubernetes的安全是一项重要工作。

正如我在一开始所说的那样，保护Kubernetes确实不是一件容易的事。到现在为止，我相信您现在是非常同意我这一说法。

Kubernetes从一开始就被设计为易于部署。不幸的是，这也意味着它在设计上是不安全的。这意味着要增加安全性完全取决于您。幸运的是，增加安全性，则使你的Kubernetes集群更具有生产价值。

本文只谈到了Kubernetes安全需要解决的最重要的问题。当然还有很多其他的问题。但是，我真的希望我给了你足够的思路让你明白这工作有多重要。而且，您必须现在就开始保护Kubernetes集群，否则黑客会毫不犹豫地提醒您，您已经将公司的重要系统暴露在危险之中。

译者：祝祥

原文：https://www.idginsiderpro.com/article/3571466/the-five-best-kubernetes-security-practices.html

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!