Capítulo 4. Configuración, Secretos y RBAC

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

La naturaleza componible de los contenedores nos permite, como operadores, introducir datos de configuración en un contenedor en tiempo de ejecución. Esto nos permite desacoplar la función de una aplicación del entorno en el que se ejecuta. Mediante las convenciones permitidas en el tiempo de ejecución del contenedor para pasar variables de entorno o montar volúmenes externos en un contenedor en tiempo de ejecución, puedes cambiar efectivamente la configuración de la aplicación en el momento de su instanciación. Como desarrollador, es importante tener en cuenta la naturaleza dinámica de este comportamiento y permitir el uso de variables de entorno o la lectura de datos de configuración desde una ruta específica disponible para el usuario en tiempo de ejecución de la aplicación.

Al trasladar datos sensibles, como secretos, a un objeto API nativo de Kubernetes, es importante comprender cómo Kubernetes asegura el acceso a la API. El método de seguridad más utilizado en Kubernetes es el Control de Acceso Basado en Roles (RBAC, por sus siglas en inglés) para implementar una estructura de permisos de grano fino en torno a las acciones que pueden realizar determinados usuarios o grupos contra la API. Este capítulo cubre algunas de las buenas prácticas relativas al RBAC y también proporciona un pequeño manual.

Configuración mediante ConfigMaps y Secretos

Kubernetes permite proporcionar de forma nativa información de configuración a nuestras aplicaciones a través de ConfigMaps o recursos secretos. El principal diferenciador entre ambos es la forma en que un pod almacena la información de recepción y cómo se almacenan los datos en el almacén de datos etcd.

ConfigMaps

En es muy habitual que las aplicaciones consuman información de configuración a través de algún tipo de mecanismo, como argumentos de la línea de comandos, variables de entorno o archivos disponibles en el sistema. Los contenedores permiten al desarrollador desvincular esta información de configuración de la aplicación, lo que permite una verdadera portabilidad de la aplicación. La API ConfigMap permite inyectar la información de configuración suministrada. Los ConfigMaps son muy adaptables a los requisitos de la aplicación y pueden proporcionar pares clave/valor o datos masivos complejos como JSON, XML o datos de configuración propietarios.

Los ConfigMaps no sólo proporcionan información de configuración para los pods, sino que también pueden proporcionar información para ser consumida por servicios del sistema más complejos, como controladores, CRDs, operadores, etc. Como se ha dicho antes, la API ConfigMap está pensada más para datos de cadenas que no son realmente datos sensibles. Si tu aplicación requiere datos más sensibles, la API Secretos es más apropiada.

Para que tu aplicación utilice los datos de ConfigMap, se pueden inyectar como un volumen montado en el pod o como variables de entorno.

Secretos

Muchos de los atributos y razones por los que querrías utilizar un ConfigMap se aplican a los secretos. Las principales diferencias radican en la naturaleza fundamental de un secreto. Los datos secretos deben almacenarse y manejarse de forma que puedan ocultarse fácilmente y, posiblemente, cifrarse en reposo si el entorno está configurado como tal. Los datos secretos se representan como información codificada en base64, y es fundamental entender que esto no está encriptado. En cuanto se inyecta el secreto en el pod, el propio pod puede ver los datos secretos en texto plano.

Los datos secretos están pensados para ser pequeñas cantidades de datos, limitados por defecto en Kubernetes a 1 MB de tamaño para los datos codificados en base64, así que asegúrate de que los datos reales son de aproximadamente 750 KB debido a la sobrecarga de la codificación. Hay tres tipos de secretos en Kubernetes:

generic

Este suele ser sólo pares clave/valor normales que se crean a partir de un archivo, un directorio o de literales de cadena utilizando el parámetro --from-literal=, como se indica a continuación:

kubectl create secret generic mysecret --from-literal=key1=$3cr3t1
    --from-literal=key2=@3cr3t2
docker-registry

Este es utilizado por el kubelet cuando se pasa en una plantilla pod si existe un imagePullsecret para proporcionar las credenciales necesarias para autenticarse en un registro Docker privado:

kubectl create secret docker-registry registryKey --docker-server
    myreg.azurecr.io --docker-username myreg --docker-password
    $up3r$3cr3tP@ssw0rd --docker-email ignore@dummy.com
tls

Este crea un secreto de Seguridad de la Capa de Transporte (TLS) a partir de un par de claves pública/privada válido. Siempre que el cert esté en un formato PEM válido, el par de claves se codificará como secreto y se podrá pasar al pod para que lo utilice en sus necesidades SSL/TLS:

kubectl create secret tls www-tls --key=./path_to_key/wwwtls.key
    --cert=./path_to_crt/wwwtls.crt

Los secretos también se montan en tmpfs sólo en los nodos que tienen un pod que requiere el secreto y se borran cuando el pod que necesita el secreto desaparece. Así se evita que queden secretos en el disco del nodo. Aunque esto pueda parecer seguro, es importante saber que, por defecto, los secretos se almacenan en el almacén de datos etcd de Kubernetes en texto plano, y es importante que los administradores del sistema o el proveedor de servicios en la nube se esfuercen por garantizar la seguridad del entorno etcd, incluyendo mTLS entre los nodos etcd y habilitando el cifrado en reposo para los datos etcd. Las versiones más recientes de Kubernetes utilizan etcd3 y tienen la capacidad de habilitar el cifrado nativo de etcd; sin embargo, se trata de un proceso manual que debe configurarse en la configuración del servidor API especificando un proveedor y los medios de claves adecuados para cifrar correctamente los datos secretos que se guardan en etcd. A partir de Kubernetes v1.10 (ha pasado a beta en v1.12), disponemos del proveedor KMS, que promete proporcionar un proceso de claves más seguro mediante el uso de sistemas KMS de terceros para mantener las claves adecuadas.

Buenas prácticas comunes paralas API ConfigMapy Secrets

La mayoría de los problemas que surgen al utilizar un ConfigMap o secreto son suposiciones incorrectas sobre cómo se gestionan los cambios cuando se actualizan los datos que contiene el objeto. Si comprendes las reglas del juego y añades algunos trucos para facilitar el cumplimiento de esas reglas, podrás alejarte de los problemas:

  • Para soportar los cambios dinámicos de en tu aplicación sin tener que volver a desplegar nuevas versiones de los pods, monta tus ConfigMaps/Secrets como un volumen y configura tu aplicación con un vigilante de archivos para que detecte los datos de archivo modificados y se reconfigure a sí misma según sea necesario. El código siguiente muestra una Implementación que monta un ConfigMap y un archivo Secreto como un volumen:

apiVersion: v1
kind: ConfigMap
metadata:
    name: nginx-http-config
    namespace: myapp-prod
data:
  config: |
    http {
      server {
        location / {
        root /data/html;
        }

        location /images/ {
          root /data;
        }
      }
    }
apiVersion: v1
kind: Secret
metadata:
  name: myapp-api-key
type: Opaque
data:
  myapikey: YWRtd5thSaW4=
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mywebapp
  namespace: myapp-prod
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 8080
    volumeMounts:
    - mountPath: /etc/nginx
      name: nginx-config
    - mountPath: /usr/var/nginx/html/keys
      name: api-key
  volumes:
    - name: nginx-config
      configMap:
        name: nginx-http-config
        items:
        - key: config
          path: nginx.conf
    - name: api-key
      secret:
        name: myapp-api-key
        secretname: myapikey
Nota

Hay que tener en cuenta un par de cosas al utilizar volumeMounts. En primer lugar, en cuanto se cree el ConfigMap/Secret, añádelo como volumen en la especificación de tu pod. A continuación, monta ese volumen en el sistema de archivos del contenedor. Cada nombre de propiedad del ConfigMap/Secret se convertirá en un nuevo archivo en el directorio montado, y el contenido de cada archivo será el valor especificado en el ConfigMap/Secret. En segundo lugar, evita montar ConfigMaps/Secrets utilizando la propiedad volumeMounts.subPath. Esto evitará que los datos se actualicen dinámicamente en el volumen si actualizas un ConfigMap/Secret con nuevos datos.

  • Los ConfigMaps/Secrets deben existir en el espacio de nombres de los pods que los consumirán antes de que se despliegue el pod. La bandera opcional puede utilizarse para evitar que los pods no se inicien si el ConfigMap/Secret no está presente.

  • Utiliza un controlador de admisión para garantizar datos de configuración específicos o para impedir implementaciones que no tengan establecidos determinados valores de configuración. Un ejemplo sería si requieres que todas las cargas de trabajo Java de producción tengan determinadas propiedades JVM establecidas en entornos de producción.

  • Si utilizas Helm para liberar aplicaciones en tu entorno, puedes utilizar un gancho de ciclo de vida para asegurarte de que la plantilla ConfigMap/Secret se despliega antes de que se aplique la Implementación.

  • Algunas aplicaciones requieren que su configuración se aplique como un único archivo, como un archivo JSON o YAML. ConfigMap/Secret permite un bloque entero de datos sin procesar utilizando el símbolo |, como se demuestra aquí:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-file
data:
  config: |
    {
      "iotDevice": {
        "name": "remoteValve",
        "username": "CC:22:3D:E3:CE:30",
        "port": 51826,
        "pin": "031-45-154"
      }
    }
  • Si la aplicación utiliza variables de entorno del sistema para determinar su configuración, puedes utilizar la inyección de datos del ConfigMap para crear un mapeo de variables de entorno en el pod. Hay dos formas principales de hacerlo: montando cada par clave/valor del ConfigMap como una serie de variables de entorno en el pod utilizando envFrom y utilizando despuésconfigMapRef o secretRef, o asignando claves individuales con sus respectivos valores utilizando configMapKeyRef o secretKeyRef.

  • Si utilizas el método configMapKeyRef o secretKeyRef, ten en cuenta que si la clave real no existe, esto impedirá que se inicie el pod.

  • Si estás cargando todos los pares clave/valor del ConfigMap/Secret en el pod utilizando envFrom, se omitirán todas las claves que se consideren valores de entorno no válidos; no obstante, el pod podrá arrancar. El evento para el pod tendrá un evento con la razón InvalidVariableNamesy el mensaje apropiado sobre qué clave se ha omitido. El código siguiente es un ejemplo de Implementación con una referencia ConfigMap y Secret como variable de entorno:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-config
data:
  mysqldb: myappdb1
  user: mysqluser1
apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
type: Opaque
data:
  rootpassword: YWRtJasdhaW4=
  userpassword: MWYyZDigKJGUyfgKJBmU2N2Rm
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-db-deploy
spec:
  selector:
    matchLabels:
      app: myapp-db
  template:
    metadata:
      labels:
        app: myapp-db
    spec:
      containers:
      - name: myapp-db-instance
        image: mysql
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 3306
        env:
          - name: MYSQL_ROOT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-secret
                key: rootpassword
          - name: MYSQL_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-secret
                key: userpassword
          - name: MYSQL_USER
            valueFrom:
              configMapKeyRef:
                name: mysql-config
                key: user
          - name: MYSQL_DB
            valueFrom:
              configMapKeyRef:
                name: mysql-config
                key: mysqldb
  • Si es necesario pasar argumentos de línea de comandos a tus contenedores, los datos de las variables de entorno pueden obtenerse utilizando la sintaxis de interpolación $(ENV_KEY):

[...]
spec:
  containers:
  - name: load-gen
    image: busybox
    command: ["/bin/sh"]
args: ["-c", "while true; do curl $(WEB_UI_URL); sleep 10;done"]
    ports:
    - containerPort: 8080
    env:
    - name: WEB_UI_URL
      valueFrom:
        configMapKeyRef:
          name: load-gen-config
          key: url
  • Al consumir datos ConfigMap/Secret como variables de entorno, es muy importante comprender que las actualizaciones de los datos en el ConfigMap/Secret no se actualizarán en el pod y requerirán un reinicio del pod. Esto puede hacerse borrando los pods y dejando que el controlador ReplicaSet cree un nuevo pod, o activando una actualización de la Implementación, que seguirá la estrategia adecuada de actualización de la aplicación, tal como se declara en la especificación de la Implementación.

  • Es más fácil asumir que todos los cambios en un ConfigMap/Secret requieren una actualización de toda la Implementación; esto garantiza que, aunque estés utilizando variables de entorno o volúmenes, el código tomará los nuevos datos de configuración. Para que esto sea más fácil, puedes utilizar una canalización CI/CD para actualizar la propiedad name del ConfigMap/Secret y actualizar también la referencia en la Implementación, lo que desencadenará una actualización de la Implementación mediante las estrategias normales de actualización de Kubernetes. Exploraremos esto en el siguiente código de ejemplo. Si utilizas Helm para liberar el código de tu aplicación en Kubernetes, puedes aprovechar una anotación en la plantilla de Implementación para comprobar la suma de comprobación sha256 del ConfigMap/Secret. Esto hace que Helm actualice la Implementación utilizando el comando helm upgrade cuando los datos de un ConfigMap/Secret cambien :

apiVersion: apps/v1
kind: Deployment
[...]
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml")
            . | sha256sum }}
[...]

Buenas prácticas específicas de los secretos

Debido a la naturaleza de datos sensibles de la API de Secretos, naturalmente hay buenas prácticas más específicas, que giran principalmente en torno a la seguridad de los propios datos:

  • Si tu carga de trabajo no necesita acceder directamente a la API de Kubernetes, es una buena práctica bloquear el automontaje de la Credencial API para la Cuenta de Servicio (Predeterminada o creada por el operador). Esto reducirá las llamadas al servidor de la API, ya que se utiliza un reloj para actualizar los datos de la credencial de la API cuando ésta caduca. En clusters muy grandes o con muchos pods, esto reducirá las llamadas al Plano de Control, reduciendo así una posible causa de degradación del rendimiento. Esto puede definirse en el ServiceAccount o en el propio Pod Spec:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app1-svcacct
automountServiceAccountToken: false
[...]
apiVersion: v1
kind: Pod
metadata:
  name: app1-pod
spec:
  serviceAccountName: app1-svcacct
  automountServiceAccountToken: false
[...]
  • La especificación original de la API de Secretos esbozaba una arquitectura conectable para permitir que el almacenamiento real del secreto fuera configurable en función de los requisitos. Soluciones como HashiCorp Vault, Aqua Security, Twistlock, AWS Secrets Manager, Google Cloud KMS o Azure Key Vault permiten el uso de sistemas de almacenamiento externos para los datos secretos utilizando un nivel de cifrado y auditabilidad superior al que ofrece Kubernetes de forma nativa. El proyecto de la Fundación LinuxExternalSecrets Operator proporciona una forma nativa de ofrecer esta funcionalidad.

  • Asigna un imagePullSecrets a un serviceaccount que el pod utilizará para montar automáticamente el secreto sin tener que declararlo en elpod.spec. Puedes parchear la cuenta de servicio predeterminada para el espacio de nombres de tu aplicación y añadirle directamente el imagePullSecrets. Esto lo añadirá automáticamente a todos los pods del espacio de nombres:

Create the docker-registry secret first
kubectl create secret docker-registry registryKey --docker-server
myreg.azurecr.io --docker-username myreg --docker-password $up3r$3cr3tP@ssw0rd
--docker-email ignore@dummy.com

patch the default serviceaccount for the namespace you wish to configure
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name":
"registryKey"}]}'
  • Utiliza las funciones de CI/CD para obtener secretos de una cámara acorazada segura o de un almacén cifrado con un Módulo de Seguridad de Hardware (HSM) durante el proceso de publicación. Esto permite la separación de funciones. Los equipos de gestión de la seguridad pueden crear y cifrar los secretos, y los desarrolladores sólo tienen que hacer referencia a los nombres del secreto esperado. Este es también el proceso DevOps preferido para garantizar un proceso de entrega de aplicaciones más dinámico.

RBAC

Cuando se trabaja en entornos grandes y distribuidos, es muy habitual que se necesite algún tipo de mecanismo de seguridad para impedir el acceso no autorizado a sistemas críticos. Existen numerosas estrategias sobre cómo limitar el acceso a los recursos de los sistemas informáticos, pero la mayoría pasan todas por las mismas fases. Utilizar una analogía de una experiencia común, como volar a un país extranjero, puede ayudar a explicar los procesos que ocurren en sistemas como Kubernetes. Podemos utilizar la experiencia común del viajero con un pasaporte, un visado de viaje y los guardias de aduanas o fronteras para mostrar el proceso:

Pasaporte (autentificación del sujeto)

Normalmente necesitas tener un pasaporte emitido por alguna agencia gubernamental que ofrezca algún tipo de verificación sobre quién eres. Esto equivaldría a una cuenta de usuario en Kubernetes. Kubernetes depende de una autoridad externa para autenticar a los usuarios; sin embargo, las cuentas de servicio son un tipo de cuenta gestionada directamente por Kubernetes.

Visado o póliza de viaje (autorización)

Los países tendrán acuerdos formales para aceptar a viajeros con pasaportes de otros países mediante acuerdos formales a corto plazo, como los visados. Los visados también describirán lo que el visitante puede hacer y durante cuánto tiempo puede permanecer en el país visitante, dependiendo del tipo específico de visado. Esto sería equivalente a la autorización en Kubernetes. Kubernetes tiene diferentes métodos de autorización, pero RBAC es el más utilizado. Esto permite un acceso muy granular a diferentes capacidades de la API.

Patrulla de fronteras o aduanas (control de admisión)

Al entrar en un país extranjero, suele haber un organismo de autoridad que comprobará los documentos necesarios, incluidos el pasaporte y el visado, y, en muchos casos, inspeccionará lo que se introduce en el país para asegurarse de que cumple las leyes de ese país. En Kubernetes esto equivale a los controladores de admisión. Los controladores de admisión pueden permitir, denegar o modificar las peticiones a la API basándose en reglas y políticas definidas. Kubernetes tiene muchos controladores de admisión integrados, como los controladoresPodSecurity, ResourceQuota y ServiceAccount. Kubernetes también permite controladores dinámicos mediante el uso de controladores de admisión validadores o mutantes .

Esta sección se centra en la menos comprendida y la más evitada de estas tres áreas: RBAC. Antes de esbozar algunas de las buenas prácticas, debemos presentar una introducción al RBAC de Kubernetes.

Manual RBAC

El proceso RBAC en Kubernetes tiene tres componentes principales que hay que definir: el sujeto, la regla y la vinculación del rol.

Temas

El primer componente de es el sujeto, el elemento cuyo acceso se comprueba realmente. El sujeto suele ser un usuario, una cuenta de servicio o un grupo. Como ya se ha dicho, tanto los usuarios como los grupos son gestionados fuera de Kubernetes por el módulo de autorización utilizado. Podemos clasificarlos en autenticación básica, certificados de cliente x.509 o tokens de portador. Las implementaciones más comunes utilizan certificados de cliente x.509 o algún tipo de token portador utilizando algo como un sistema OpenID Connect como Azure Active Directory (Azure AD), Salesforce o Google.

Nota

Las cuentas de servicio en Kubernetes se diferencian de las cuentas de usuario en que están vinculadas a un espacio de nombres y se almacenan internamente en Kubernetes; están pensadas para representar procesos, no personas, y son gestionadas por controladores nativos de Kubernetes.

Reglas

En pocas palabras, es la lista real de acciones que se pueden realizar en un objeto (recurso) concreto o en un grupo de objetos de la API. Los verbos se alinean con las típicas operaciones de tipo crear, leer, actualizar y eliminar (CRUD), pero con algunas capacidades añadidas en Kubernetes, como watch, list yexec. Los objetos se alinean con los distintos componentes de la API y se agrupan en categorías. Los objetos pod, por ejemplo, forman parte de la API central y pueden referenciarse con apiGroup: "", mientras que las implementaciones están bajo el grupo de la API de aplicaciones. Éste es el verdadero poder del proceso RBAC y probablemente lo que intimida y confunde a la gente a la hora de crear controles RBAC adecuados.

Funciones

Los roles permiten a definir el alcance de las reglas definidas. Kubernetes tiene dos tipos de roles, role y clusterRole, con la diferencia de querole es específico de un espacio de nombres , y clusterRole es un rol que abarca todo el clúster y todos los espacios de nombres. Un ejemplo de definición de rol con ámbito de espacio de nombres sería el siguiente:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-viewer
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBindings

El enlace RoleBinding permite asignar un tema, como un usuario o un grupo, a un rol específico. Los enlaces también tienen dos modos: roleBinding, que es específico de un espacio de nombres, y clusterRoleBinding, que es para todo el clúster. Aquí tienes un ejemplo de RoleBinding con ámbito de espacio de nombres :

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: noc-helpdesk-view
  namespace: default
subjects:
- kind: User
  name: helpdeskuser@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-viewer # this must match the name of the Role or ClusterRole
                   # to bind to
  apiGroup: rbac.authorization.k8s.io

Buenas prácticas de RBAC

RBAC es un componente crítico para ejecutar un entorno Kubernetes seguro, fiable y estable. Los conceptos subyacentes a RBAC pueden ser complejos; sin embargo, la adhesión a algunas buenas prácticas puede aliviar algunos de los principales escollos:

  • Las aplicaciones desarrolladas para ejecutarse en Kubernetes rara vez necesitan un rol RBAC y un RoleBinding asociados. Sólo si el código de la aplicación interactúa directamente con la API de Kubernetes, la aplicación requiereuna configuración RBAC.

  • Si la aplicación necesita acceder directamente a la API de Kubernetes para, quizás, cambiar la configuración en función de los endpoints que se añadan a un servicio, o si necesita listar todos los pods de un espacio de nombres específico, la mejor práctica es crear una nueva cuenta de servicio que se especifique en la especificación del pod. A continuación, crea un rol que tenga la menor cantidad de privilegios necesarios para cumplir su objetivo.

  • Utiliza un servicio OpenID Connect que permita la gestión de identidades y, si es necesario, la autenticación de dos factores. Esto permitirá un mayor nivel de autenticación de identidad. Asigna grupos de usuarios a roles que tengan la menor cantidad de privilegios necesarios para realizar el trabajo.

  • Junto con la práctica mencionada, debes utilizar sistemas de acceso Justo a Tiempo (JIT) para permitir que los ingenieros de fiabilidad del sitio (SRE), los operadores y quienes puedan necesitar tener privilegios elevados durante un breve periodo de tiempo realicen una tarea muy específica. Alternativamente, estos usuarios deben tener identidades diferentes que sean auditadas más intensamente para el inicio de sesión, y esas cuentas deben tener privilegios más elevados asignados por la cuenta de usuario o grupo vinculado a un rol.

  • Deben utilizarse cuentas de servicio específicas para las herramientas de CI/CD que se desplieguen en tus clústeres de Kubernetes. Esto garantiza la auditabilidad dentro del clúster y la comprensión de quién podría haber desplegado o eliminado cualquier objeto en un clúster.

  • Si sigues utilizando Helm v2 para desplegar aplicaciones, la cuenta de servicio por defecto es Tiller, desplegado en kube-system. Es mejor desplegar Tiller en cada espacio de nombres con una cuenta de servicio específica para Tiller que tenga alcance para ese espacio de nombres. En la herramienta CI/CD que llama al comando de instalación/actualización de Helm, como paso previo, inicializa el cliente Helm con la cuenta de servicio y el espacio de nombres específico para la Implementación. El nombre de la cuenta de servicio puede ser el mismo para cada espacio de nombres, pero el espacio de nombres debe ser específico. Se aconseja pasar a Helm v3 porque uno de sus principios básicos es que ya no se necesita Tiller para funcionar en un clúster. La nueva arquitectura está completamente basada en el cliente y utiliza el acceso RBAC del usuario que llama a los comandos de Helm. Esto está en consonancia con el enfoque preferido de herramientas basadas en el cliente para la API de Kubernetes.

  • Limita cualquier aplicación que requiera watch y list en la API de Secretos. Esto básicamente permite a la aplicación o a la persona que desplegó el pod ver los secretos de ese espacio de nombres. Si una aplicación necesita acceder a la API de Secretos para secretos específicos, limita el uso de get en cualquier secreto específico que la aplicación necesite leer fuera de los que tiene asignados directamente .

Resumen

Los principios para desarrollar aplicaciones para la entrega nativa en la nube es un tema para otro día, pero está universalmente aceptado que la separación estricta de la configuración del código es un principio clave para el éxito. Con objetos nativos para datos no sensibles, la API ConfigMap, y para datos sensibles, la API Secretos, Kubernetes puede ahora gestionar este proceso con un enfoque declarativo. A medida que se representan y almacenan cada vez más datos críticos de forma nativa en la API de Kubernetes, es fundamental asegurar el acceso a esas API mediante procesos de seguridad adecuados, como RBAC y sistemas de autenticación integrados.

Como verás a lo largo del resto de este libro, estos principios impregnan todos los aspectos de la correcta implementación de servicios en una plataforma Kubernetes para construir un sistema estable, fiable, seguro y robusto.

Get Las mejores prácticas de Kubernetes, 2ª edición now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.