我对 Kubernetes 很陌生。
我的理解secret
是它通过base64
. 从我看到的资源来看,据称secret
可以保护敏感信息。我不明白这一点。
除了用 编码信息之外,我看不出和base64
之间有任何真正的区别。我们可以很容易地解码编码信息。这意味着根本没有保护...secret
configMap
base64
我的理解错了吗?
我对 Kubernetes 很陌生。
我的理解secret
是它通过base64
. 从我看到的资源来看,据称secret
可以保护敏感信息。我不明白这一点。
除了用 编码信息之外,我看不出和base64
之间有任何真正的区别。我们可以很容易地解码编码信息。这意味着根本没有保护...secret
configMap
base64
我的理解错了吗?
保护 aSecret
的事实是它是 kubernetes 中不同的资源类型,因此可以受制于与 a 不同的 RBAC 策略ConfigMap
。
如果您当前能够读取Secret
集群中的 s,那是因为您的ClusterRoleBinding
(or RoleBinding
) 具有专门授予对这些资源的访问权限的规则。这可能是由于您通过其中一个主节点的“未经身份验证”端口访问集群,或者由于 [ Cluster
]RoleBinding
将您附加Subject
到cluster-admin
,这在 hello-world 情况下可能很常见,但我猜在生产集群设置。
这是迂腐的答案,然而,真正保护 a 中包含的秘密Secret
更加棘手,因为它们通常Pod
通过环境注入或卷安装暴露给 s 。这意味着任何有权exec
访问s 的人都Pod
可以很容易地泄露秘密值,因此如果秘密非常重要,甚至必须对团队保密,那么您也需要撤销exec
对 s 的访问权Pod
。中间立场可能是允许团队访问Secret
他们自己的 s Namespace
,但禁止其他Namespace
s 访问。这是安全性,因此排列和特殊情况几乎没有尽头。