O que são contêineres confidenciais?

Um contêiner confidencial fornece um ambiente de tempo de execução seguro para cargas de trabalho confidenciais, mas permite que você continue a trabalhar com os fluxos de trabalho existentes.

A implementação IBM Cloud de contêineres confidenciais aproveita os pods de pares para estender a funcionalidade dos pods Red Hat OpenShift em um VSI separado do nó de trabalho. Essa extensão cria um ambiente de execução confiável além dos tradicionais Kubernetes e OpenShift.

Saiba mais:

• Analise os motivos pelos quais você pode usar contêineres confidenciais.
• Consulte o site Perguntas frequentes para ver se há contêineres confidenciais.

Pré-requisitos

• Quando você cria ou escolhe o cluster Red Hat OpenShift on IBM Cloud a ser usado, o cluster deve atender aos seguintes requisitos:

  • O cluster deve estar em uma região que ofereça suporte a VSIs(Virtual Server Instances)TDX.
  • O cluster deve ter uma interface pública ou você pode se conectar ao seu ambiente por meio de uma VPN.
  • Para permitir que o cluster se comunique com qualquer VSI criado com contêineres confidenciais, é necessário criar um grupo de segurança com o nome especificado. kube-CLUSTER_ID para o cluster.

• Se necessário, habilite OperatorHub. Às vezes, o OperatorHub é desativado em um cluster por motivos de segurança.

Etapa 1: Instalação do operador

Instale o OpenShift Sandboxed Containers Operator para gerenciar o ciclo de vida de contêineres confidenciais em clusters.

1. Abra o painel de controle do cluster.

2. Clique em OpenShift console da Web > Operators > OperatorHub.

3. Procure por OpenShift sandboxed containers Operator e clique no bloco.

4. Clique em Instalar para obter a versão estável e com suporte do OpenShift Sandboxed Containers Operator, versão 1.10.3. Consulte o Verificador de informações de atualização do operador do site Red Hat para obter as versões compatíveis do site OpenShift.

5. Na janela Instalar operador, você pode manter as seleções padrão e clicar em Instalar.

6. Espere que a instalação seja concluída. Clique no link View installed Operators in Namespace openshift-sandboxed-containers-operator e aguarde até que o status seja Succeeded. Enquanto espera, você pode concluir a próxima etapa para configurar a CLI.

Etapa 2: Configuração da CLI

Antes de começar, você pode concluir estas etapas para configurar a CLI ou pode usar o shell IBM Cloud para executar comandos.

1. Instale a linha de comando IBM Cloud.

2. Instale as ferramentas ks e oc CLI.

3. Efetue login na CLI do IBM Cloud.

   ibmcloud login --apikey API_KEY -g RESOURCE_GROUP
   

4. Liste os clusters na conta e copie o ID do cluster que você deseja usar na próxima etapa.

   ibmcloud ks cluster ls
   

5. Execute o comando config .

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

   Em seu diretório pessoal, é criada uma pasta .kube e as informações são armazenadas para a comunicação com esse cluster.

6. Confirme se os comandos do oc foram executados corretamente, visualizando os detalhes dos nós de trabalho no cluster.

   oc get nodes
   

7. Defina o namespace project para que você não precise incluir o namespace em comandos posteriores.

   oc project openshift-sandboxed-containers-operator
   

8. Opcional: Explore o namespace.

   oc get all
   

   Por exemplo, na lista de pods, o gerenciador de controlador chamado pod/controller-manager-<id> gerencia os microsserviços dentro do operador.

9. Instale a ferramenta is CLI.

Etapa 3: Importar a imagem do pod de pares

O OpenShift Sandboxed Containers Operator inicia um sistema operacional especial dentro do pod de pares que deve ser importado para a sua conta IBM Cloud. Esse sistema operacional é necessário para implementar uma carga de trabalho em um contêiner confidencial.

A imagem do pod de pares contém um sistema operacional completo Red Hat Enterprise Linux (RHEL) 9.6 com o software necessário para instanciar um contêiner em uma Máquina Virtual Confidencial (CVM).

Todas as configurações e pacotes instalados no sistema operacional permanecem com os valores padrão Red Hat. No entanto, os VSIs ( IBM Cloud ) exigem cloud init que o funcione. Nos scripts, o cloud init é impedido de ser desinstalado quando termina de criar o podvm, o que é uma diferença importante em relação à sua imagem de origem.

Antes de Iniciar:

Validar a compatibilidade da versão. A imagem é compatível com as seguintes versões.

• OpenShift Contêineres em sandbox Versão do operador 1.10.3
• OpenShift versões 4.19, 4.18, 4.17, e 4.16 clusters

Para importar a imagem do pod de pares:

1. Execute o 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. Abra as imagens computacionais.

3. Clique no ícone Criar +, escolha uma região com VSIs compatíveis com TDX e preencha os campos obrigatórios.

   a. Para Fonte de imagem, selecione Cloud Object Storage.

   b. Selecione a guia Localizar por URL do arquivo de imagem e, no URL da imagem, insira cos://us-south/podvm-image/rhel9-podvm-latest.qcow2.

   c. Para o sistema operacional, selecione Red Hat Enterprise Linux > red-9-amd64.

   d. Opcional: Para criar outro contêiner confidencial a partir da API com os mesmos detalhes posteriormente, clique no botão Get sample API call (Obter chamada de API de amostra ) e copie o comando Curl.

   e. Clique em “Criar imagem personalizada ”.

4. Quando a imagem for adicionada à lista Imagens, clique no nome da imagem e selecione a guia IDs. Em seguida, anote o ID da imagem para usar posteriormente.

5. Aguarde até que o status da imagem passe a ser “Disponível ”.

   ibmcloud is image IMAGE_NAME
   

6. Repita essas etapas quando uma nova versão da imagem estiver disponível.

Etapa 4: Criação de uma chave de API ou perfil confiável

Os contêineres confidenciais exigem uma credencial para instanciar o pod par por meio do site kata-remote quando uma carga de trabalho segura é iniciada. Essa credencial deve ser uma chave de API válida ou um perfil confiável com permissões para criar um VSI em sua conta.

Se estiver testando contêineres confidenciais, poderá usar uma chave de API. Se estiver usando o site Secrets Manager, você deverá configurar um perfil confiável.

• Chave API da interface do usuário

  1. No painel IBM Cloud, clique em Gerenciar > Acesso (IAM) > Chaves de API.

  2. Clique em Criar.

  3. Salve essa chave de forma segura, pois ela não poderá ser recuperada dessa página posteriormente.

• Chave API da CLI.

  Execute o comando a seguir e salve o resultado.

  ibmcloud iam api-key-create KEY_NAME
  

• Perfil confiável

  1. Abra o painel de perfis confiáveis.

  2. Crie um perfil confiável e conceda a esse perfil as permissões necessárias para criar servidores virtuais a partir de OpenShift.

     a. Crie um perfil confiável.

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

     b. Permitir que os recursos em openshift-sandboxed-containers-operator usem o perfil confiável.

     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 acesso aos serviços de infraestrutura da VPC (is).

     Para permitir o acesso a todos os recursos da conta:

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

     Para permitir o acesso a um 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>]
     

Etapa 5: criação de uma chave SSH (opcional)

Em clusters de teste, pode ser útil ter uma chave SSH pronta para solucionar problemas de não inicialização e para visualizar os registros. Em clusters de produção, talvez você não queira ativar a funcionalidade SSH.

1. Clique em Infraestrutura > Computação > Chaves SSH.

2. Crie uma chave SSH e anote o ID da chave SSH.

Etapa 6: Configuração de contêineres confidenciais

Depois que o Operator for instalado, crie o site ConfigMaps para permitir que o Kata manipule cargas de trabalho na conta IBM Cloud.

1. Crie uma pasta para armazenar os arquivos.

   mkdir <directory-name>
   

2. Mudar para o diretório.

   cd <directory-name>
   

3. Copie as seguintes variáveis de ambiente para a chave de API, ID do perfil confiável, nome do cluster, ID da imagem PodVM, ID da chave SSH e ID da VPC (opcional).

   Opcional: você pode armazená-los em um script do Shell no novo diretório para defini-los novamente mais tarde. Exemplo:<directory-name>/env-vars.sh

   a. Reúna os valores das seguintes variáveis e atualize os valores no script.

   • Para o site CLUSTER_NAME, abra os detalhes do cluster na lista de clusters e copie o nome.
   • Opcional: Para o site VPC_ID, na seção Detalhes do cluster da mesma página, você pode clicar no nome do vpc para abrir os detalhes do VPC e copiar o campo ID do VPC.
   • Para PODVM_IMAGE_ID, use a ID da imagem que você salvou para a imagem do pod de pares.
   • Se estiver usando uma chave de API, você pode remover a linha IBMCLOUD_TRUSTED_PROFILE_ID.
   • Se estiver usando um perfil confiável, você pode remover a linha IBMCLOUD_API_KEY.
   • Se você não definiu uma chave SSH, poderá remover a linha 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. Se você armazenou as variáveis em um script do Shell, execute-o. Exemplo:

   sh env-vars.sh
   

4. Execute o comando para criar o site 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 o ConfigMap.

   oc apply -f feature-gates.yaml
   

6. Execute o comando para criar o site peer-pods-secret.yaml. Remova quaisquer variáveis de ambiente opcionais da seção stringData que sejam necessárias.

   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. Aplique o segredo ao cluster.

   oc apply -f peer-pods-secret.yaml
   

8. Execute o comando para criar o site peer-pods-cm.yaml ConfigMap. Remova quaisquer variáveis de ambiente opcionais da seção data que não tenham sido definidas.

   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
   

   A configuração PEERPODS_LIMIT_PER_NODE controla o número máximo de VSIs de pods de pares que podem ser agendados por nó de trabalho. O valor padrão é 10. É possível aumentar esse valor com base na capacidade do nó de trabalho, mas observe que você também está restrito pelos limites do pod Kubernetes (110 pods por nó para um trabalhador 16x64 ) e pelos recursos de CPU disponíveis no nó de trabalho. Cada pod de pares consome aproximadamente 250m CPU e 120Mi memória no nó de trabalho para a construção do pod Kubernetes, embora a carga de trabalho real seja executada em um VSI separado. Para obter mais informações, consulte as Perguntas mais frequentes.

9. Aplique o ConfigMap.

   oc apply -f peer-pods-cm.yaml
   

10. Execute o comando para criar o site 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 o KataConfig.

    oc apply -f kata-runtime-settings.yaml
    

12. À medida que o Kata é instalado e os conjuntos de daemons são iniciados, você pode monitorar o progresso.

    • Você pode dar uma olhada no projeto OperatorHub openshift-sandboxed-containers-operator para ver que o KataConfig está em andamento.
    • Você pode executar o seguinte comando para ver os rótulos serem atualizados com o estado atual da instalação.

        oc get nodes --output yaml|egrep "kata-ds-rpm-install|ibm-cloud.kubernetes.io/worker-id"
        ```
        Possíveis estados:
    
        - `waiting_to_install`: A instalação do Kata está em fila de espera no nó.
        - `installing`: A instalação do Kata está em andamento.
        - `installed`: O Kata foi instalado com êxito no nó.
        - `waiting_for_reboot`: O nó deve ser reinicializado para concluir a instalação ou desinstalação.
        - `waiting_to_uninstall`: A desinstalação do Kata está na fila do nó.
        - `uninstalling`: A desinstalação do Kata está em andamento.
        - `uninstalled`: O Kata foi desinstalado com sucesso do nó.
    
    

13. Quando os rótulos estiverem atualizados e no estado waiting_for_reboot, reinicie cada nó de trabalho, um de cada vez.

Quando você executar oc get nodes e cada nó de trabalho estiver no estado installed, a instalação estará concluída.

Etapa 7: Configuração de uma autoridade de confiança

O atestado é uma parte essencial dos contêineres confidenciais. Você deve validar a segurança do código da cadeia de suprimentos, para que o código em execução no contêiner não seja modificado. Você pode aproveitar um chip Intel TDX e o protocolo key-broker-service. A imagem do site podvm já contém o código do driver TDX em funcionamento e um kbs_client. No entanto, você deve configurar o INITDATA com os detalhes do trustee.

1. Selecione um administrador. Há muitas opções para o fiduciário em contêineres confidenciais.

   • Para fins de desenvolvimento, você pode lançar um VM para um administrador nele.

   • Para um serviço de nível de produção, você pode usar a Intel Trust Authority.

2. Se você selecionou o site VM para um trustee para fins de desenvolvimento, conclua estas etapas de configuração.

   a. Insira o endereço IP do administrador no script a seguir e execute-o para definir a variável 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. Verifique a variável de ambiente $INITDATA .

   echo $INITDATA
   

   c. Adicione o valor da variável a peer-pods-cm.yaml ConfigMap no espaço de nomes openshift-sandboxed-containers-operator.

   d. Reinicie o daemonset osc-caa-ds no namespace openshift-sandboxed-containers-operator. Esse conjunto de daemons do Cloud API Adapter é usado para se comunicar com IBM Cloud.

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

   e. Execute o comando a seguir para visualizar os pods. Para cada pod osc-caa-ds-<id>, examine a Idade de cada pod para verificar se o pod foi reiniciado.

   oc get pods
   

   Se um pod não for reiniciado, exclua o pod para recriá-lo.

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

   Visualize os pods novamente.

   oc get pods
   

   f. Repita essas etapas para cada entrada de carga de trabalho de INITDATA.

   g. O valor INITDATA pode ser aplicado a um contêiner individual como uma anotação, e o contêiner que é iniciado é configurado para usar o trustee. Essa anotação pode ser útil ao testar novos fiduciários ou ao garantir que as alterações em INITDATA não danifiquem nenhum contêiner confidencial.

   Exemplo de anotação:

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

Etapa 8: executar uma carga de trabalho de contêiner confidencial

Depois que todos os rótulos forem atualizados para installed, implante uma carga de trabalho usando o nome da classe de tempo de execução kata-remote em um arquivo pod.yaml. Você pode usar o exemplo Hello World como uma carga de trabalho de teste em um contêiner confidencial.

1. Crie um arquivo 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. Monitore a implementação na lista Virtual Servers. Quando o VSI é criado, ele exibe o estado Em execução. Se o VSI parecer estar preso no estado Iniciando, verifique se há problemas nos registros.

   a. Obtenha os nomes de pod.

   oc get pods
   

   b. Obtenha os registros de um dos pods do Cloud API Adapter e procure por erros.

   oc logs osc-caa-ds-<id>
   

3. Verifique o pod executando o comando a seguir.

   oc describe pod/helloworld
   

4. Para verificar o atestado, execute o contêiner com o seguinte comando.

   oc exec -it helloworld -- bash
   

   Em seguida, execute o seguinte comando curl para obter informações do administrador.

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

   Quando terminar, você poderá sair do contêiner.

   exit
   

5. Se houver problemas, examine os registros no namespace openshift-sandboxed-containers-operator.

   • Registros de pods gerenciados pelo controlador:

       oc logs pod/controller-manager-<UNIQUE_ID>
       ```
   - Registros de pods do adaptador de API da nuvem:
   
   ```sh {: pre}
       oc logs pod/osc-caa-ds-<UNIQUE_ID>
       ```
   - Registros de aplicativos: Depende do local especificado.
   
   

A configuração dos contêineres confidenciais está concluída! Ainda precisa de ajuda? Confira a solução de problemas.

Remoção de cargas de trabalho e ferramentas

A conclusão dessas etapas na ordem errada pode deixar para trás recursos pelos quais você será cobrado, como um VSI.