То, что защищает Secret, - это тот факт, что он является отдельным типом ресурса в kubernetes и, следовательно, может подвергаться политике RBAC, отличной от ConfigMap.
Если вы в настоящее время можете читать Secret s в своем кластере, это потому, что у вашего ClusterRoleBinding (или RoleBinding) есть правило, которое специально предоставляет доступ к этим ресурсам. Это может быть связано с тем, что вы обращаетесь к кластеру через его «неаутентифицированный» порт с одного из главных узлов, или из-за [Cluster] RoleBinding, связывающего ваши Subject с cluster-admin, что, вероятно, довольно часто встречается в Привет-мир ситуации, но я бы предположил, что менее распространены в настройках производственного кластера.
Это педантичный ответ, однако, на самом деле охранять секреты, содержащиеся в Secret, сложнее, учитывая, что они обычно подвергаются Pod с помощью инъекции среды или монтирования тома. Это означает, что любой, кто имеет exec доступ к Pod, может очень легко отфильтровать секретные значения, поэтому, если секреты очень важны и должны храниться даже в команде, вам необходимо отозвать exec доступ к ваши Pod с тоже. Срединной точкой может быть предоставление команде доступа к Secret с их Namespace, но запрещение этого с другими Namespace с. Это безопасность, так что перестановкам и особым случаям почти нет конца.