使用基于角色的访问掌握

从Kubernetes1.8开始，您可以使用RBAC来控制用户可以做什么。这一点很重要，因为试图将运行在数十个实例和集群上的用户混为一谈来提供服务是非常恐怖的。使用RBAC，零信任安全方法，用户和组件(如应用程序和节点)只需要获得完成任务所需的权限。

RBAC在应用程序编程接口(API)级别上工作。这样，即使不使用授权者本身，RBAC规则也会锁定用户。RBAC还阻止用户通过编辑角色或角色绑定为自己提供更多特权。

默认情况下，它也会阻止外来者。RBAC策略向控制平面组件、节点和控制器授予作用域权限。但是，这一点很重要，它不向kube-system namespace之外的服务帐户授予任何权限。

为了便于管理Kubernetes，RBAC提供了预定义的角色。这样，开发人员、操作员和集群管理员只需获得他们所需的权限，而不需要任何用不到的权限。

在这个系统中，cluster admin角色相当于Unix和Linux的超级用户。群集管理员可以创建、编辑或删除任何群集资源。不用说，必须小心保护群集管理员角色的访问权限。

Kubernetes Secrets对象包含敏感元素，例如密码，OAuth令牌或ssh密钥。简而言之，它们是Kubernetes集群的钥匙。您必须保护好他们。

Kubernetes会自动创建用于访问API的机密，并修改您的Pod以使用它们。但是，您的secrets(例如Pod访问数据库所需的用户名和密码)则在您的控制和保护之下。

很简单吧?不幸的是，Kubernetes的secrets带有许多内置的安全漏洞。官方所列出的漏洞简直令人恐惧。

• 在API服务器，secret数据被存储在ETCD，Kubernetes默认使用分布式key-value存储。默认情况下，etcd数据不加密，因此您的secrets也不加密。因此，您必须启用静态加密并限制对admin用户的etcd访问。
• 许多用户将其机密信息保存在JSON或YAML文件中。在这里，机密数据被编码(未加密)为base64。这意味着如果您共享配置文件或将其提交到代码仓库中，其他人则可以读取您的所有secrets。
• 一旦应用程序使用了secret，就将不允许该应用程序对其进行记录或将其传输给不受信任的一方。
• 一个可以创建使用secret的Pod的用户也可以看到这个secret的值。即使API服务器策略不允许该用户读取它，用户也可以运行一个Pod，这会暴露secret。
• 当前，在任何节点上具有root权限的任何人都可以通过模拟kubelet来从API服务器读取任何secret。这实际上是一个特性。其思想是，通过只与需要它们的节点共享secret，可以将根攻击对单个节点造成的损害限制在一个节点上。

这种情况很糟糕。你可以随时通过加密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。

（编辑：泉州站长网）

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