Dela documentación de Kubernetes Secrets :

Riesgos

• En el servidor API, los datos secretos se almacenan en etcd ( por defecto, los datos de etcd no están encriptados ); por lo tanto:
  1. Los administradores deben habilitar el cifrado en reposo para los datos del clúster (requiere v1.13 o posterior).
  2. Los administradores deben limitar el acceso a etcd a los usuarios administradores.
  3. Es posible que los administradores deseen borrar/triturar los discos usados por etcd cuando ya no estén en uso.
  4. Si ejecuta etcd en un clúster, los administradores deben asegurarse de usar SSL/TLS para la comunicación entre pares de etcd.
• Si configura el secreto a través de un archivo de manifiesto (JSON o YAML) que tiene los datos secretos codificados como base64, compartir este archivo o registrarlo en un repositorio de origen significa que el secreto está comprometido. La codificación Base64 no es un método de cifrado y se considera igual que el texto sin formato.
• Las aplicaciones aún necesitan proteger el valor del secreto después de leerlo del volumen, como no registrarlo accidentalmente o transmitirlo a una parte que no sea de confianza.
• Un usuario que puede crear un Pod que usa un secreto también puede ver el valor de ese secreto. Incluso si la política del servidor API no permite que ese usuario lea el secreto, el usuario podría ejecutar un pod que exponga el secreto.
• Actualmente, cualquier persona con permiso de raíz en cualquier nodo puede leer cualquier secreto del servidor de la API haciéndose pasar por el kubelet. Es una característica planificada para enviar secretos solo a los nodos que realmente los requieren, para restringir el impacto de un exploit raíz en un solo nodo.

Consulte también la excelente publicación ¿Puede Kubernetes guardar un secreto? Todo depende de la herramienta que estés usando , especialmente la parte " ¿Qué tiene de malo Kubernetes Plain Secrets? ".

Espero haber respondido a su pregunta, pero en general @Harsh Manvar tiene razón: primero debe tener acceso a ese secreto.

Debe limitar el acceso mediante políticas de autorización como RBAC.

Deberá crear un Role/ClusterRole con los permisos apropiados y luego vincularlo (mediante RoleBinding/ClusterRoleBinding ) a un usuario y/o una cuenta de servicio (se puede usar en la definición de pod entonces), según su caso de uso.

Puede consultar la documentación aquí para crear Role & ClusterRole y los documentos aquí para RoleBinding y ClusterRoleBinding.