Visão geral
Workloads conteinerizados em ambientes compartilhados enfrentam ameaças que o isolamento tradicional de containers não mitiga, como administradores mal-intencionados, kernels comprometidos e ataques no nível de firmware.
O projeto CNCF Confidential Containers (CoCo) encapsula pods do Kubernetes em VMs confidenciais baseadas em hardware. Ele criptografa a memória de runtime para torná-la inacessível ao host e fornece atestação remota para verificar a integridade do ambiente antes da injeção de secrets.
Este tópico orienta você na implantação do CoCo em uma instância bare metal ecs.ebmg8i.48xlarge com Intel TDX para criar um runtime confiável e isolado para workloads conteinerizados.
Arquitetura
Cada pod do Kubernetes executa dentro de uma VM confidencial TDX que protege os dados em tempo de execução. Todo o processamento ocorre dentro desse limite seguro.
Objetivos
Implantar um cluster CoCo de nó único (versão v0.17.0).
Configurar um cluster Kubernetes de nó único (v1.32.0) usando Kubeadm.
Procedimento
Etapa 1: Criar uma instância bare metal TDX
Crie uma instância bare metal do Alibaba Cloud de 8ª geração com suporte a Intel TDX.
Acesse a página de compra de instâncias.
Selecione um método de faturamento, região e zona de disponibilidade. A imagem da comunidade necessária está disponível apenas em zonas específicas. Para este exemplo, selecione Beijing Zone I.
Na seção Instance, clique em Elastic Bare Metal Server e selecione o tipo de instância
ecs.ebmg8i.48xlarge.-
Na seção Image, selecione Community Image e pesquise pelo ID da imagem
m-2ze2ucup4c5bvgx751lx. Marque a caixa de seleção Confidential VM para ativar o TDX.ImportanteEsta é uma imagem personalizada baseada em Ubuntu com drivers TDX pré-instalados. O usuário SSH padrão é
ubuntu, nãoroot. Configure as definições de rede, armazenamento, largura de banda, grupo de segurança e gerenciamento. Consulte Configuration Item Descriptions.
Revise a configuração geral no lado direito da página. Defina opções como a duração da assinatura e verifique se todas as configurações atendem aos seus requisitos.
-
Clique em Confirm Order para criar a instância.
A criação da instância leva de 3 a 5 minutos. Acesse a página Instances no console para verificar o status. A instância estará pronta quando seu status mudar para Running.
Etapa 2: Preparar o nó do Kubernetes
Conecte-se à instância e instale o software necessário para configurá-la como um cluster Kubernetes de nó único.
-
Instalar o containerd
# Update the package sources and install dependencies. sudo apt-get update sudo apt-get install -y ca-certificates curl # Add Docker's official GPG key. sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc # Add Docker's APT repository. echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # Install containerd. sudo apt-get update sudo apt-get install -y containerd.io -
Configurar o containerd Gere o arquivo de configuração padrão e modifique parâmetros essenciais para compatibilidade com o Kubernetes.
# Generate the default configuration file. sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml # Replace the Kubernetes image registry with an Alibaba Cloud mirror to accelerate image pulls. sudo sed -i -E 's#registry.k8s.io#registry.aliyuncs.com/google_containers#g' /etc/containerd/config.toml # Change the cgroup driver to systemd to meet Kubernetes requirements. sudo sed -i 's#SystemdCgroup = false#SystemdCgroup = true#g' /etc/containerd/config.toml # Restart the containerd service to apply the changes. sudo systemctl restart containerd -
Configurar parâmetros do kernel Desative a partição swap e carregue os módulos do kernel necessários para rede e runtime do Kubernetes.
# Temporarily disable swap. sudo swapoff -a # Permanently disable swap by commenting out the swap entry in the fstab file. sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab # Load the overlay and br_netfilter kernel modules. sudo modprobe overlay sudo modprobe br_netfilter # Configure the modules to load automatically at boot. sudo tee /etc/modules-load.d/k8s.conf <<EOF overlay br_netfilter EOF # Configure kernel parameters to allow IP forwarding and bridged traffic processing. sudo tee /etc/sysctl.d/kubernetes.conf <<EOT net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 EOT # Apply all sysctl configurations. sudo sysctl --system
Etapa 3: Instalar um cluster Kubernetes de nó único
Use o kubeadm para configurar um cluster Kubernetes de nó único.
-
Instalar componentes do Kubernetes Instale o
kubeadm,kubeletekubectl.# Add the GPG key for the Kubernetes APT repository. curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg # Add the Kubernetes APT repository. echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list # Install the Kubernetes tools. sudo apt-get update sudo apt-get install -y kubectl kubeadm kubelet sudo apt-mark hold kubelet kubeadm kubectl -
Inicializar o plano de controle Use
kubeadm initpara inicializar o plano de controle.# Get the IP address of the primary network interface to use as the API server's advertise address. # Note: This command assumes the primary interface is eth0. If your environment is different, replace it with the correct IP address. NODE_IP=$(ip -o -4 addr show dev eth0 | awk '{split($4,a,"/");print a[1]}') # Initialize the cluster. sudo kubeadm init --pod-network-cidr=10.10.0.0/16 \ --apiserver-advertise-address ${NODE_IP} \ --kubernetes-version v1.32.0 \ --image-repository registry.aliyuncs.com/google_containersApós a inicialização, siga as instruções de saída para configurar as credenciais de acesso do
kubectl.mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config -
Instalar um plugin de rede Implante o plugin CNI Flannel para comunicação entre pods.
# Install the Flannel network plugin. export KUBECONFIG=/etc/kubernetes/admin.conf FLANNEL_VERSION=v0.27.4 wget https://github.com/flannel-io/flannel/releases/download/${FLANNEL_VERSION}/kube-flannel.yml # Modify the Flannel manifest to set the correct pod network CIDR and use a regional image mirror. sed -i -E 's#([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]+#10.10.0.0/16#g' kube-flannel.yml sed -i -E 's#ghcr.io/flannel-io#confidential-ai-registry.cn-shanghai.cr.aliyuncs.com/product#g' kube-flannel.yml # Deploy Flannel. kubectl apply -f kube-flannel.yml -
Remover o taint do plano de controle Permita workloads neste cluster de nó único removendo o taint
NoScheduledo nó do plano de controle.NODE_NAME=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') kubectl taint nodes $NODE_NAME node-role.kubernetes.io/control-plane-
Etapa 4: Implantar componentes do CoCo
Escolha o método Helm chart ou Operator para implantar o CoCo.
Helm chart
Implante o CoCo com um Helm chart.
-
Instalar o Helm
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh -
Configurar o Helm chart do CoCo Clone o repositório de charts do CoCo e crie um arquivo
values.yamlpersonalizado para ativar os runtimes TDX.# Clone the charts repository and check out the specified version. git clone https://github.com/confidential-containers/charts.git cd charts git reset --hard v0.17.0 # Create a TDX-specific configuration file. cat << EOF > values-tdx.yaml architecture: x86_64 # Point the CoCo image registry to a regional mirror address. kata-as-coco-runtime: image: reference: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-kata-deploy imagePullPolicy: Always k8sDistribution: k8s debug: false # Snapshotter configuration snapshotter: setup: ["nydus"] # Enable the TDX-related shims. shims: qemu-tdx: enabled: true supportedArches: - amd64 containerd: snapshotter: nydus forceGuestPull: false crio: guestPull: true agent: httpsProxy: "" noProxy: "" qemu-coco-dev: enabled: true supportedArches: - amd64 allowedHypervisorAnnotations: [] containerd: snapshotter: nydus forceGuestPull: false crio: guestPull: true agent: httpsProxy: "" noProxy: "" # Explicitly disable other unnecessary TEE shims. qemu-snp: enabled: false qemu-se: enabled: false # Enable RuntimeClass creation. runtimeClasses: enabled: true createDefault: false defaultName: "kata" # Default shim per architecture defaultShim: amd64: qemu-tdx EOF -
Implantar o CoCo Instale o CoCo com o Helm usando sua configuração personalizada.
helm install coco oci://ghcr.io/confidential-containers/charts/confidential-containers \ -f values-tdx.yaml \ --namespace coco-system \ --create-namespace \ --version 0.17.0 -
Criar a RuntimeClass O Helm chart não cria uma RuntimeClass padrão. Crie manualmente os objetos
RuntimeClassnecessários para seus pods.cat <<EOF | kubectl apply -f - apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: kata-qemu-tdx handler: kata-qemu-tdx --- apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: kata-qemu-coco-dev handler: kata-qemu-coco-dev EOF
Operator
mkdir -p kustomize && cd kustomize
mkdir release && mkdir -p ccruntime/default
cat <<EOF > release/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- "github.com/confidential-containers/operator/config/release?ref=v0.17.0"
images:
- name: quay.io/confidential-containers/operator
newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-operator
EOF
cat <<EOF > ccruntime/default/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- "github.com/confidential-containers/operator/config/samples/ccruntime/default?ref=v0.17.0"
images:
- name: quay.io/confidential-containers/reqs-payload
newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-reqs-payload
- name: quay.io/kata-containers/kata-deploy-ci
newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-kata-deploy-ci
- name: quay.io/kata-containers/kata-deploy
newName: registry-cn-hangzhou.ack.aliyuncs.com/dev/coco-kata-deploy
EOF
# Allow the current node to act as a worker.
for NODE_NAME in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
kubectl label node $NODE_NAME node.kubernetes.io/worker=
done
kubectl apply -k release
kubectl apply -k ccruntime/default
Etapa 5: Implantar e verificar um pod de exemplo
Execute um pod de exemplo e verifique se ele roda em uma VM confidencial TDX.
-
Rotular o nó Aplique um rótulo no nó worker para indicar suporte ao runtime Kata.
NODE_NAME=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') kubectl label node $NODE_NAME katacontainers.io/kata-runtime=true -
Implantar um pod de exemplo Crie um pod que utilize o runtime TDX por meio de
runtimeClassNameem suaspec.cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: coco-demo-pod spec: runtimeClassName: kata-qemu-tdx containers: - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/alinux3:latest name: hello-alinux command: - "sleep" - "infinity" EOF -
Verificar a implantação Confirme se o pod está em execução com a classe de runtime correta.
# Wait for the pod status to become Running. kubectl get pod coco-demo-pod # Describe the pod and confirm that the "Runtime Class" field is "kata-qemu-tdx". kubectl describe pod coco-demo-pod | grep "Runtime Class" -
Verificar a ativação do TDX Verifique os logs do kernel na instância bare metal para confirmar a inicialização do TDX.
# Run this command on the node. dmesg | grep -i tdxUma saída contendo
TDX module initializedou mensagens semelhantes confirma que o ambiente TDX está ativo e que o runtime Kata o utiliza para VMs confidenciais.
Custos e riscos
Detalhamento de custos: O principal custo provém da instância bare metal
ecs.ebmg8i.48xlarge. Suas altas especificações adequam-se a workloads de produção com requisitos rigorosos de segurança e desempenho, mas aumentam os custos de avaliação e teste.-
Limitações e riscos:
Dependência de hardware e região: Esta solução exige um tipo específico de instância bare metal e zonas de disponibilidade compatíveis.
Ponto único de falha: Este tutorial utiliza um cluster de nó único, que não possui alta disponibilidade. Implantações em produção requerem um cluster multi-nó com arquitetura de alta disponibilidade.
Compatibilidade de versões: As versões do CoCo, Kubernetes e componentes relacionados são fortemente acopladas. Atualizações exigem testes cuidadosos de compatibilidade.