¿Qué son los contenedores confidenciales?

Un contenedor confidencial proporciona un entorno de ejecución seguro para cargas de trabajo sensibles, pero permite seguir trabajando con los flujos de trabajo existentes.

La implementación de IBM Cloud de contenedores confidenciales aprovecha los pods de pares para ampliar la funcionalidad de los pods de Red Hat OpenShift en una VSI independiente del nodo trabajador. Esta extensión crea un entorno de ejecución de confianza más allá de los tradicionales Kubernetes y OpenShift.

Más información:

• Repase las razones por las que podría utilizar contenedores confidenciales.
• Visite Preguntas más frecuentes para consultar los contenedores confidenciales.

Requisitos previos

• Al crear o elegir el clúster Red Hat OpenShift on IBM Cloud que se va a utilizar, el clúster debe cumplir los siguientes requisitos:

  • El clúster debe estar en una región que admita instancias de servidor virtual TDX(VSI).
  • El clúster debe tener una interfaz pública o puede conectarse a su entorno a través de una VPN.
  • Para permitir que el clúster se comunique con cualquier VSI creado con contenedores confidenciales, debe crearse un grupo de seguridad denominado kube-CLUSTER_ID para el clúster.

• Si es necesario, active OperatorHub. A veces OperatorHub se desactiva en un clúster por razones de seguridad.

Paso 1: Instalación del operador

Instale el operador OpenShift Sandboxed Containers para gestionar el ciclo de vida de los contenedores confidenciales en los clústeres.

1. Abra el panel de control del clúster.

2. Haga clic en OpenShift consola web > Operadores > OperatorHub.

3. Busque OpenShift sandboxed containers Operator y haga clic en la ficha.

4. Haga clic en Instalar para obtener la versión estable y compatible del operador de contenedores aislados OpenShift, versión 1.10.3. Consulte en Red Hat 's Operator Update Information Checker las versiones compatibles de OpenShift.

5. En la ventana Instalar operador, puede mantener las selecciones predeterminadas y hacer clic en Instalar.

6. Espere hasta que finalice la instalación. Haga clic en el enlace View installed Operators in Namespace openshift-sandboxed-containers-operator y espere a que el estado sea Succeeded. Mientras espera, puede completar el siguiente paso para configurar la CLI.

Paso 2: Configuración de la CLI

Antes de empezar, puede completar estos pasos para configurar la CLI o puede utilizar el shell IBM Cloud para ejecutar comandos.

1. Instale el sitio IBM Cloud línea de comando.

2. Instale las herramientas ks y oc CLI.

3. Inicie sesión en la CLI de IBM Cloud.

   ibmcloud login --apikey API_KEY -g RESOURCE_GROUP
   

4. Enumere los clústeres de la cuenta y copie el ID del clúster que desea utilizar para el siguiente paso.

   ibmcloud ks cluster ls
   

5. Ejecute el mandato config.

   ibmcloud ks cluster config --cluster CLUSTER_ID --admin --endpoint link
   

   En su directorio personal, se crea una carpeta .kube y se almacena información para comunicarse con ese clúster.

6. Confirme que los comandos oc se ejecutan correctamente visualizando los detalles de los nodos trabajadores del clúster.

   oc get nodes
   

7. Establezca el proyecto de espacio de nombres para que no tenga que incluir el espacio de nombres en comandos posteriores.

   oc project openshift-sandboxed-containers-operator
   

8. Opcional: Explorar el espacio de nombres.

   oc get all
   

   Por ejemplo, en la lista de pods, el gestor controlador que se llama pod/controller-manager-<id> gestiona los microservicios dentro del operador.

9. Instale la herramienta CLI is.

Paso 3: Importación de la imagen peer pod

El operador de OpenShift Sandboxed Containers lanza un sistema operativo especial dentro del pod par que debe ser importado a su cuenta de IBM Cloud. Este sistema operativo es necesario para desplegar una carga de trabajo en un contenedor confidencial.

La imagen peer pod contiene un sistema operativo completo Red Hat Enterprise Linux (RHEL) 9.6 con el software necesario para instanciar un contenedor en una máquina virtual confidencial (CVM).

Todas las configuraciones y paquetes instalados en el sistema operativo conservan los valores predeterminados de Red Hat. Sin embargo, los VSI ( IBM Cloud ) requieren cloud init para funcionar. En los scripts, se impide que cloud init se desinstale cuando termina de construir el podvm, lo que constituye una diferencia clave con respecto a su imagen de origen.

Antes de empezar:

Validar la compatibilidad de versiones. La imagen es compatible con las siguientes versiones.

• OpenShift Sandboxed Containers Versión para operadores 1.10.3
• OpenShift versiones 4.19, 4.18, 4.17, y 4.16 clusters

Para importar la imagen del pod par:

1. Ejecute el image-create comando.

   # Note IMAGE_NAME is a placeholder variable. Image names do not support capitalization.
   ibmcloud is image-create "IMAGE_NAME" --file cos://us-south/podvm-image/rhel9-podvm-latest.qcow2  --os-name red-9-amd64
   

2. Abre las imágenes informáticas.

3. Haga clic en el icono Crear +, elija una región con VSI compatibles con TDX y complete los campos obligatorios.

   a. Para Fuente de imagen, seleccione Cloud Object Storage.

   b. Seleccione la pestaña Localizar por archivo de imagen URL y en Imagen URL, introduzca cos://us-south/podvm-image/rhel9-podvm-latest.qcow2.

   c. Para el Sistema operativo, seleccione Red Hat Enterprise Linux > red-9-amd64.

   d. Opcional: Para crear otro contenedor confidencial desde la API con los mismos detalles más adelante, haga clic en el botón Obtener ejemplo de llamada a la API y copie el comando Curl.

   e. Haz clic en Crear imagen personalizada.

4. Cuando la imagen se añada a la lista Imágenes, haga clic en el nombre de la imagen y seleccione la pestaña IDs. A continuación, anote el ID de la imagen para utilizarlo más adelante.

5. Espera a que el estado de la imagen sea Disponible.

   ibmcloud is image IMAGE_NAME
   

6. Repita estos pasos cuando disponga de una nueva versión de la imagen.

Paso 4: Crear una clave API o un perfil de confianza

Los contenedores confidenciales requieren una credencial para instanciar el pod par a través de kata-remote cuando se lanza una carga de trabajo segura. Esta credencial debe ser una clave API válida o un perfil de confianza con permisos para crear una VSI en su cuenta.

Si está probando contenedores confidenciales, puede utilizar una clave API. Si utiliza Secrets Manager, debe configurar un perfil de confianza.

• Clave API desde la interfaz de usuario

  1. En el panel IBM Cloud, haga clic en Gestionar > Acceso (IAM) > Claves API.

  2. Pulse Crear.

  3. Guarde esta clave de forma segura, ya que no podrá recuperarla posteriormente desde esta página.

• Clave API desde la CLI.

  Ejecuta el siguiente comando y guarda el resultado.

  ibmcloud iam api-key-create KEY_NAME
  

• Perfil de confianza

  1. Abra el panel de perfiles de confianza.

  2. Cree un perfil de confianza y concédale los permisos necesarios para crear servidores virtuales desde OpenShift.

     a. Cree un perfil de confianza.

     ibmcloud iam trusted-profile-create <NAME> [--description <DESCRIPTION>]
     

     b. Permitir que los recursos de openshift-sandboxed-containers-operator utilicen el perfil de confianza.

     ibmcloud iam trusted-profile-rule-create PROFILE_NAME_OR_ID --name RULE_NAME --type Profile-CR --conditions claim:namespace,operator:EQUALS,value:openshift-sandboxed-containers-operator --cr-type ROKS_SA
     

     c. Permitir el acceso a los servicios de infraestructura de la VPC (is).

     Para permitir el acceso a todos los recursos de la cuenta:

     ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile>  --roles Editor,Writer --service-name is
     

     Para permitir el acceso a un grupo de recursos específico:

     ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile> --roles Viewer [--resource-group-id <resource group>]
     

Paso 5: Crear una clave SSH (Opcional)

En clusters de prueba, puede ser útil tener una clave SSH lista para solucionar problemas de por qué algo no se inicia y para ver los registros. En los clusters de producción, es posible que no desee habilitar la funcionalidad SSH.

1. Haga clic en Infraestructura > Ordenadores > Claves SSH.

2. Cree una clave SSH y anote el ID de la clave SSH.

Paso 6: Configuración de contenedores confidenciales

Una vez instalado el Operador, cree ConfigMaps para permitir que Kata gestione cargas de trabajo en la cuenta IBM Cloud.

1. Crea un directorio para guardar los archivos.

   mkdir <directory-name>
   

2. Cambia al directorio.

   cd <directory-name>
   

3. Copie las siguientes variables de entorno para la clave API, el ID del perfil de confianza, el nombre del clúster, el ID de la imagen PodVM, el ID de la clave SSH y el ID de la VPC (opcional).

   Opcional: Puede almacenarlos en un script de Shell en el nuevo directorio para establecerlos de nuevo más tarde. Ejemplo:<directory-name>/env-vars.sh

   a. Recopila los valores de las siguientes variables y actualiza los valores en el script.

   • En CLUSTER_NAME, abra los detalles del clúster en la lista de clústeres y copie el nombre.
   • Opcional: Para VPC_ID, en la sección Detalles del clúster de la misma página, puede hacer clic en el nombre de la VPC para abrir los detalles de la VPC y copiar el campo ID de VPC.
   • Para PODVM_IMAGE_ID, utilice el ID de imagen que guardó para la imagen del pod par.
   • Si utiliza una clave API, puede eliminar la línea IBMCLOUD_TRUSTED_PROFILE_ID.
   • Si utiliza un perfil de confianza, puede eliminar la línea IBMCLOUD_API_KEY.
   • Si no ha configurado una clave SSH, puede eliminar la línea SSH_KEY_ID.

   export IBMCLOUD_API_KEY=<your API key>
   export IBMCLOUD_TRUSTED_PROFILE_ID="<your Trusted Profile ID>"
   export CLUSTER_NAME=<cluster-name-region-flavor>
   export PODVM_IMAGE_ID=<PodVM image ID provided by IBM or a custom-built image>
   export SSH_KEY_ID=<SSH key ID to be used by the peer pod VSI>
   export VPC_ID=<Optional: the VPC that your Openshift cluster is in>
   

   b. Si almacenó las variables en un script de Shell, ejecútelo. Ejemplo:

   sh env-vars.sh
   

4. Ejecute el comando para crear la página feature-gates.yaml ConfigMap.

   cat > feature-gates.yaml <<EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: osc-feature-gates
     namespace: openshift-sandboxed-containers-operator
   data:
     deploymentMode: "DaemonSetFallback" # or DaemonSet to force it
     confidential: "true"
     layeredImageDeployment: "false"
   EOF
   

5. Aplique el ConfigMap.

   oc apply -f feature-gates.yaml
   

6. Ejecute el comando para crear la página peer-pods-secret.yaml. Elimine las variables de entorno opcionales de la sección stringData que no necesite.

   cat > peer-pods-secret.yaml <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: peer-pods-secret
     namespace: openshift-sandboxed-containers-operator
   type: Opaque
   stringData:
     # either IBMCLOUD_API_KEY or IBMCLOUD_IAM_PROFILE_ID must be set
     # if you specify both the IBMCLOUD_API_KEY will be used
     # IBMCLOUD_IAM_ENDPOINT is optional
     IBMCLOUD_API_KEY: "$IBMCLOUD_API_KEY"
     IBMCLOUD_IAM_ENDPOINT: "https://iam.cloud.ibm.com/identity/token"
     IBMCLOUD_IAM_PROFILE_ID: "$IBMCLOUD_TRUSTED_PROFILE_ID"
   EOF
   

7. Aplica el secreto al clúster.

   oc apply -f peer-pods-secret.yaml
   

8. Ejecute el comando para crear la página peer-pods-cm.yaml ConfigMap. Elimine las variables de entorno opcionales de la sección data que no haya establecido.

   cat > peer-pods-cm.yaml <<EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: peer-pods-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     CLOUD_PROVIDER: "ibmcloud"
     IBMCLOUD_PODVM_IMAGE_ID: "$PODVM_IMAGE_ID"
     IBMCLOUD_PODVM_INSTANCE_PROFILE_LIST: "bx3dc-2x10"
     IBMCLOUD_PODVM_INSTANCE_PROFILE_NAME: "bx3dc-2x10"
     IBMCLOUD_RESOURCE_GROUP_ID: "$(ibmcloud is vpc "$VPC_ID" -json | jq -r .resource_group.id)"
     IBMCLOUD_SSH_KEY_ID: "$SSH_KEY_ID"
     IBMCLOUD_VPC_ID: "$VPC_ID"
     IBMCLOUD_VPC_SG_ID: "$(ibmcloud ks security-group ls --cluster $CLUSTER_NAME -json | jq -r '.[] | select(.type == "cluster") | .id')"
     CLOUD_CONFIG_VERIFY: "false"
     CRI_RUNTIME_ENDPOINT: "/run/cri-runtime/containerd.sock"
     ENABLE_CLOUD_PROVIDER_EXTERNAL_PLUGIN: "false"
     VXLAN_PORT: ""
     TUNNEL_TYPE: ""
     INITDATA: ""
     PEERPODS_LIMIT_PER_NODE: "10"
   EOF
   

   El ajuste PEERPODS_LIMIT_PER_NODE controla el número máximo de VSI de pods de pares que se pueden programar por nodo trabajador. El valor predeterminado es 10. Puede aumentar este valor en función de la capacidad de su nodo trabajador, pero tenga en cuenta que también está restringido por los límites de pods de Kubernetes (110 pods por nodo para un trabajador de 16x64 ) y los recursos de CPU disponibles en el nodo trabajador. Cada pod peer consume aproximadamente 250m CPU y 120Mi memoria en el nodo trabajador para la construcción del pod Kubernetes, aunque la carga de trabajo real se ejecute en una VSI independiente. Para obtener más información, consulte Preguntas más frecuentes.

9. Aplique el ConfigMap.

   oc apply -f peer-pods-cm.yaml
   

10. Ejecute el comando para crear la página kata-runtime-settings.yaml KataConfig.

    cat > kata-runtime-settings.yaml <<EOF
    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: kata-runtime-settings
      namespace: openshift-sandboxed-containers-operator
    spec:
      enablePeerPods: true
      logLevel: info
     #checkNodeEligibility: true
     #kataConfigPoolSelector:
     #  matchLabels:
     #    <label_key>: '<label_value>'
    EOF
    

11. Aplique el KataConfig.

    oc apply -f kata-runtime-settings.yaml
    

12. A medida que se instala Kata y se inician los conjuntos de demonios, puede supervisar el progreso.

    • Puede mirar en el OperatorHub openshift-sandboxed-containers-operator proyecto para ver que KataConfig está en curso.
    • Puede ejecutar el siguiente comando para ver cómo se actualizan las etiquetas con el estado actual de la instalación.

        oc get nodes --output yaml|egrep "kata-ds-rpm-install|ibm-cloud.kubernetes.io/worker-id"
        ```
        Posibles estados:
    
        - `waiting_to_install`: La instalación de Kata está en cola en el nodo.
        - `installing`: La instalación de Kata está en curso.
        - `installed`: Kata se ha instalado correctamente en el nodo.
        - `waiting_for_reboot`: El nodo debe reiniciarse para completar la instalación o desinstalación.
        - `waiting_to_uninstall`: La desinstalación de Kata está en cola en el nodo.
        - `uninstalling`: La desinstalación de Kata está en curso.
        - `uninstalled`: Kata se desinstala correctamente del nodo.
    
    

13. Cuando las etiquetas estén actualizadas y en el estado waiting_for_reboot, reinicie cada nodo trabajador de uno en uno.

Cuando ejecute oc get nodes y cada nodo trabajador se encuentre en el estado installed, la instalación habrá finalizado.

Paso 7: Configurar una autoridad de confianza

La certificación es una parte fundamental de los contenedores confidenciales. Debe validar la seguridad del código de la cadena de suministro, que el código que se ejecuta en el contenedor no haya sido modificado. Puede aprovechar un chip Intel TDX y el protocolo key-broker-service. La imagen de podvm ya contiene el código del controlador TDX y kbs_client. No obstante, debes configurar los INITDATA con los datos del administrador.

1. Seleccione un administrador. Hay muchas opciones para depositar fideicomisos en contenedores confidenciales.

   • Para fines de desarrollo, podría lanzar un VM para un administrador en él.

   • Para un servicio de nivel de producción, puede utilizar Intel Trust Authority.

2. Si ha seleccionado VM para un administrador con fines de desarrollo, complete estos pasos de configuración.

   a. Introduzca la dirección IP del administrador en el siguiente script y ejecútelo para establecer la variable INITDATA.

   export KBS_SERVICE_ENDPOINT="https://REPLACE_WITH_TRUSTEE_IP:8080"
   export INITDATA=$(cat <<EOF | gzip | base64 -w0
   algorithm = "sha256"
   version = "0.1.0"
   [data]
   "aa.toml" = '''
   [token_configs]
   [token_configs.coco_as]
   url = "$KBS_SERVICE_ENDPOINT"
   [token_configs.kbs]
   url = "$KBS_SERVICE_ENDPOINT"
   '''
   "cdh.toml"  = '''
   socket = 'unix:///run/confidential-containers/cdh.sock'
   credentials = []
   [kbc]
   name = "cc_kbc"
   url = "$KBS_SERVICE_ENDPOINT"
   '''
   EOF
   )
   

   b. Compruebe la variable de entorno $INITDATA.

   echo $INITDATA
   

   c. Añade el valor de la variable a peer-pods-cm.yaml ConfigMap en el espacio de nombres openshift-sandboxed-containers-operator.

   d. Reinicie el conjunto de demonios osc-caa-ds en el espacio de nombres openshift-sandboxed-containers-operator. Este daemonset de Cloud API Adapter se utiliza para comunicarse con IBM Cloud.

   oc rollout restart daemonset.apps/osc-caa-ds
   

   e. Ejecuta el siguiente comando para ver los pods. Para cada pod osc-caa-ds-<id>, mire la Edad de cada pod para verificar que el pod se reinició.

   oc get pods
   

   Si un pod no se ha reiniciado, elimínelo para volver a crearlo.

   oc delete pod/osc-caa-ds-<id>
   

   Vuelve a ver las cápsulas.

   oc get pods
   

   f. Repita estos pasos para cada entrada de carga de trabajo de INITDATA.

   g. El valor INITDATA se puede aplicar a un contenedor individual como una anotación y el contenedor que se inicia está configurado para utilizar el administrador. Esta anotación puede ser útil a la hora de probar nuevos administradores o de asegurarse de que los cambios en INITDATA no rompen ningún contenedor confidencial.

   Ejemplo de anotación:

   apiVersion: v1
   kind: Pod
     metadata:
       name: mypod
       annotations:
         io.katacontainers.config.runtime.cc_init_data: $INITDATA
   spec:
     runtimeClassName: kata-remote
   

Paso 8: Ejecutar una carga de trabajo de contenedor confidencial

Una vez actualizadas todas las etiquetas a installed, despliegue una carga de trabajo utilizando el nombre de clase en tiempo de ejecución kata-remote en un archivo pod.yaml. Puede utilizar el ejemplo Hola Mundo como carga de trabajo de prueba en un contenedor confidencial.

1. Cree un archivo pod.yaml.

   oc apply -f - <<EOF
   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       app: helloworld
       version: v1
     name: helloworld
   spec:
     containers:
     - name: helloworld
       image: docker.io/istio/examples-helloworld-v1:1.0
       ports:
       - containerPort: 5000
     runtimeClassName: kata-remote
   EOF
   

2. Supervise el despliegue en la lista Virtual Servers. Cuando se crea la VSI, muestra el estado En ejecución. Si el VSI parece estar atascado en el estado de inicio, compruebe si hay problemas en los registros.

   a. Obtenga los nombres de pod.

   oc get pods
   

   b. Obtenga los registros de uno de los pods Cloud API Adapter y busque errores.

   oc logs osc-caa-ds-<id>
   

3. Comprueba el pod ejecutando el siguiente comando.

   oc describe pod/helloworld
   

4. Para comprobar la atestación, ejecute el siguiente comando en el contenedor.

   oc exec -it helloworld -- bash
   

   A continuación, ejecute el siguiente comando curl para obtener información del administrador.

   curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1
   

   Cuando haya terminado, puede salir del contenedor.

   exit
   

5. Si hay problemas, revise los registros en el espacio de nombres openshift-sandboxed-containers-operator.

   • Registros de pods gestionados por el controlador:

       oc logs pod/controller-manager-<UNIQUE_ID>
       ```
   - Registros del pod del Adaptador de la API de la Nube:
   
   ```sh {: pre}
       oc logs pod/osc-caa-ds-<UNIQUE_ID>
       ```
   - Registros de aplicaciones: Depende de la ubicación especificada.
   
   

Su configuración de contenedores confidenciales ya está completa ¿Sigue necesitando ayuda? Echa un vistazo a la resolución de problemas.

Eliminación de cargas de trabajo y herramientas

Completar estos pasos en el orden incorrecto podría dejar atrás recursos que se le facturan, como un VSI.