dew-provider

Presentación

El complemento de dew-provider se utiliza para interconectar con Data Encryption Workshop (DEW), que le permite montar secretos almacenados fuera de un clúster (es decir, DEW para almacenar información confidencial) en los pods. De esta manera, la información sensible puede desacoplarse del entorno de agrupamiento, evitando la fuga de información causada por la configuración de codificación dura del programa o de texto plano.

Notas y restricciones

• DEW incluye Key Management Service (KMS), Cloud Secret Management Service (CSMS) y Key Pair Service (KPS). Actualmente, el complemento de dew-provider solo puede interconectarse con CSMS.
• El complemento de dew-provider solo se puede instalar en clústeres v1.19 o posterior.
• El complemento de dew-provider se puede instalar en clústeres de CCE y en clústeres de CCE Turbo.
• Se puede crear un máximo de 500 objetos de SecretProviderClass.
• Cuando se desinstala el complemento, los recursos de CRD relacionados se eliminan en consecuencia. Incluso si se reinstala el complemento, el objeto de SecretProviderClass original no está disponible. Si desea utilizar los recursos originales de SecretProviderClass después de desinstalar y reinstalar el complemento, debe crearlos manualmente de nuevo.

Cómo funciona el complemento

Principios básicos

El complemento de dew-provider consiste en secrets-store-csi-driver y dew-provider, que se despliegan como DaemonSets.

• El componente secrets-store-csi-driver es responsable de mantener dos CRD: SecretProviderClass (SPC) y SecretProviderClassPodStatus (spcPodStatus). SPC se utiliza para describir el secreto en el que los usuarios están interesados (como la versión secreta y el nombre). Es creado por los usuarios y será referenciado en los pods. spcPodStatus se utiliza para rastrear las relaciones de unión entre los pods y secretos. Es creado automáticamente por csi-driver y no requiere operación manual. Un pod corresponde a un spcPodStatus. Después de iniciar un pod, se genera un spcPodStatus para el pod. Cuando finaliza el ciclo de vida del pod, el spcPodStatus se elimina en consecuencia.
• El componente de dew-provider obtiene los secretos especificados de CSMS y los monta en los pods.

Funciones

• Montaje básico: Después de instalar el complemento de dew-provider, puede crear un objeto de SecretProviderClass y declarar y hacer referencia al volumen en un pod. Cuando se inicia el pod, el secreto declarado en el objeto SecretProviderClass se monta en el pod.
• Rotación programada: Después de que un pod se ejecute correctamente, si se actualiza el secreto declarado en el objeto SPC y almacenado en CSMS, los últimos valores secretos se pueden actualizar en el pod con la rotación programada. Cuando se utiliza esta capacidad, debe establecer la versión secreta en latest.
• Conocimiento en tiempo real de los cambios de SPC: Después de que un pod se ejecute correctamente, si un usuario modifica el secreto declarado en el objeto de SPC (por ejemplo, se agrega un secreto o se cambia el número de versión), el complemento puede detectar el cambio en tiempo real y actualizar el secreto al pod.

Instalación del complemento

1. Inicie sesión en la consola de CCE y acceda a la consola del clúster. Elija Add-ons en el panel de navegación, localice dew-provider a la derecha y haga clic en Install.
2. En la página Install Add-on, seleccione el clúster donde se va a instalar el complemento y configure los parámetros en el área Parameters como se indica en la siguiente tabla.

   Parámetro	Descripción
   rotation_poll_interval	Intervalo de rotación, en unidad de m (en lugar de min). El intervalo de rotación indica el intervalo para enviar una solicitud al CSMS y obtener el último secreto. El intervalo adecuado es [1m, 1440m]. El valor predeterminado es 2m.

3. Haga clic en Install.

   Después de instalar el complemento, seleccione el clúster y haga clic en Add-ons en el panel de navegación. En la página mostrada, vea el complemento en el área Add-ons Installed.

Uso de complementos

1. Crear un ServiceAccount.
   1. Cree un objeto de ServiceAccount, que declara los nombres secretos que pueden ser utilizados por los servicios. Si un usuario hace referencia a un secreto que no se declara aquí, el montaje fallará. Como resultado, el pod no puede funcionar.

      Cree el archivo serviceaccount.yaml basado en la siguiente plantilla y declare los nombres secretos que pueden usar los servicios en el campo cce.io/dew-resource. Aquí, se declaran secret_1 y secret_2 indicando que se permite al servicio hacer referencia a dos secretos. En operaciones posteriores, si el usuario hace referencia a secret_3 en el servicio, la verificación falla. Como resultado, el secreto no se puede montar y el pod no puede funcionar.

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: nginx-spc-sa
        annotations:
          cce.io/dew-resource: "[\"secret_1\",\"secret_2\"]"  #secrets that allow pod to use

      Asegúrese de que los secretos declarados aquí existen en CSCM, como se muestra en la siguiente figura. De lo contrario, incluso si la verificación tiene éxito, se produce un error cuando el secreto correspondiente se obtiene de CSCM. Como resultado, la cápsula no puede funcionar correctamente.

      

   2. Ejecute el siguiente comando para crear el ServiceAccount:

      kubectl apply -f serviceaccount.yaml

   3. Compruebe si el objeto ServiceAccount se ha creado correctamente.

      $ kubectl get sa
      NAME       SECRETS   AGE
      default         1         18d   # This is the default ServiceAccount object of the system.
      nginx-spc-sa    1         19s   # This is the newly created ServiceAccount object.

      Se ha creado un objeto de ServiceAccount denominado nginx-spc-sa. Se hará referencia a este objeto en los pods.

2. Crear un SecretProviderClass.
   1. El objeto de SecretProviderClass se utiliza para describir la información secreta (como la versión y el nombre) que interesan a los usuarios. Es creado por los usuarios y será referenciado en los pods.

      Cree el archivo secretproviderclass.yaml utilizando la plantilla a continuación. Preste atención al campo objects de parameters que es un array utilizado para declarar el secreto a montar.

      apiVersion: secrets-store.csi.x-k8s.io/v1
      kind: SecretProviderClass
      metadata:
        name: spc-test
      spec:
        provider: cce     # The value is fixed at cce.
        parameters:
          objects: |
                - objectName: "secret_1"
                  objectVersion: "v1"
                  objectType: "csms"

      Parámetro	Tipo	Obligatorio	Descripción
      objectName	String	Sí	Nombre de la credencial. Si se definen varios objectNames en el mismo SecretProviderClass, los objectNames deben ser únicos. De lo contrario, el montaje falla.
      objectAlias	String	No	Nombre de archivo del secreto escrito en el contenedor. Si no se especifica este parámetro, el nombre de archivo del secreto escrito en el contenedor es el valor de objectName de forma predeterminada. Si se especifica este parámetro, el valor debe ser diferente de objectName y de los valores objectAlias y objectName de otros secretos. De lo contrario, el montaje falla.
      objectType	String	Sí	Tipo secreto. Actualmente, solo se admite csms. Otros valores no son válidos.
      objectVersion	String	Sí	Versión secreta. Especifique una versión, por ejemplo, v1. Utilice la última versión (última). Cuando objectVersion se establece en latest, si se actualiza el secreto correspondiente en CSCM, se actualizará en el pod después de un cierto intervalo (rotation_poll_interval).

   2. Ejecute el siguiente comando para crear un objeto de SecretProviderClass:

      kubectl apply -f secretproviderclass.yaml

   3. Compruebe si se ha creado el objeto de SecretProviderClass.

      $ kubectl get spc
      NAME   AGE
      spc-test   20h

      Se crea un objeto SecretProviderClass denominado spc-test. Este objeto será referenciado en pods posteriormente.

3. Crear un pod.

   A continuación se describe cómo crear una aplicación de Nginx.

   1. Defina una carga de trabajo, haga referencia al objeto de ServiceAccount creado en serviceAccountName y haga referencia al objeto de SPC creado en secretProviderClass, especifique la ruta de montaje del contenedor en mountPath. (No especifique directorios especiales como / y /var/run.Otherwise, the container may fail to be started.)

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: nginx-spc
        labels:
          app: nginx
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: nginx
        template:
          metadata:
            labels:
              app: nginx
          spec:
            serviceAccountName: nginx-spc-sa   # Reference the created ServiceAccount.
            volumes:
              - name: secrets-store-inline
                csi:
                  driver: secrets-store.csi.k8s.io
                  readOnly: true
                  volumeAttributes:
                    secretProviderClass: "spc-test"  # Reference the created SPC.
            containers:
              - name: nginx-spc
                image: nginx:alpine
                imagePullPolicy: IfNotPresent
                volumeMounts:
                  - name: secrets-store-inline
                    mountPath: "/mnt/secrets-store"  # Define the mount path of secrets in the container.
                    readOnly: true
            imagePullSecrets:
              - name: default-secret

   2. Ejecute kubectl apply -f despliegue.yaml para crear un pod.
   3. Compruebe si se ha creado el pod.

      $ kubectl get pod
      NAME                     READY   STATUS   RESTARTS   AGE
      nginx-spc-67c9d5b594-642np     1/1     Running    0            20s

   4. Acceda al contenedor y compruebe si el secreto especificado está escrito correctamente. Por ejemplo:

      $ kubectl exec -ti nginx-spc-67c9d5b594-642np -- /bin/bash
      root@nginx-spc-67c9d5b594-642np:/#  
      root@nginx-spc-67c9d5b594-642np:/# cd /mnt/secrets-store/
      root@nginx-spc-67c9d5b594-642np:/mnt/secrets-store# 
      root@nginx-spc-67c9d5b594-642np:/mnt/secrets-store# ls
      secret_1

      El resultado del comando muestra que secret_1 declarado en el objeto de SPC se ha escrito en el pod.

      Además, puede obtener spcPodStatus para comprobar la relación de enlace entre pods y secretos. Por ejemplo:

      $ kubectl get spcps
      NAME                                                                    AGE
      nginx-spc-67c9d5b594-642np-default-spc-test   103s
      $ kubectl get spcps nginx-spc-67c9d5b594-642np-default-spc-test -o yaml
      ......
      status:
      mounted: true
      objects:    # Mounted secret
      - id: secret_1
      version: v1
      podName: nginx-spc-67c9d5b594-642np   # Pod that references the SPC object
      secretProviderClassName: spc-test               # SPC object
      targetPath: /mnt/paas/kubernetes/kubelet/pods/6dd29596-5b78-44fb-9d4c-a5027c420617/volumes/kubernetes.io~csi/secrets-store-inline/mount

Rotación programada

Como se describió antes, puede usar este complemento para completar los secretos de montaje, es decir, puede escribir los secretos almacenados en CSMS en un pod.

Para cambiar la versión secreta declarada en el objeto SPC a latest, ejecute el siguiente comando:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: spc-test
spec:
  provider: cce
  parameters:
    objects: |
          - objectName: "secret_1"
            objectVersion: "latest"  # change "v1"to "latest"
            objectType: "csms"

Después de actualizar el objeto de SPC, el complemento envía periódicamente una solicitud al CSMS para obtener el valor de secret_1 de la última versión y actualiza el valor al pod que hace referencia al objeto SPC. El intervalo para que el complemento envíe solicitudes periódicamente se especifica mediante rotation_poll_interval establecido en Instalación del complemento.

Detección en tiempo real de cambios de SPC

Los cambios de SPC ya se detectan en tiempo real en Uso de complementos y Rotación programada. Para una demostración, agregue el secreto secret_2 al objeto SPC de la siguiente manera:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: spc-test
spec:
  provider: cce
  parameters:
    objects: |
          - objectName: "secret_1"
            objectVersion: "latest"
            objectType: "csms"
          - objectName: "secret_2"
            objectVersion: "v1"
            objectType: "csms"

Una vez actualizado el objeto de SPC, el nuevo secret_2 se monta rápidamente en el pod que hace referencia al objeto de SPC.

Consulta de logs de componentes

Ver el pod donde se ejecuta el complemento.

$ kubectl get pod -n kube-system
NAME                          READY   STATUS      RESTARTS   AGE
csi-secrets-store-76tj2       3/3     Running     0           11h
dew-provider-hm5fq            1/1     Running     0           11h

Vea los logs de pod del componente de dew-provider.

$ kubectl logs dew-provider-hm5fq -n kube-system
...Log information omitted...
...

Vea los logs de pod del componente csi-secrets-store. Como el pod del componente csi-secrets-store contiene varios contenedores, debe ejecutar el comando -c para especificar un contenedor al ver los logs de pod. El contenedor de secrets-store es el principal contenedor de servicios del complemento y contiene la mayoría de los logs.

$ kubectl logs csi-secrets-store-76tj2 -c secrets-store -n kube-system
...Log information omitted...
...

Historial de cambios