Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Esta é uma documentação não divulgada para Admission Controller 1.34-dev.

Arquitetura do SUSE Security Admission Controller

SUSE Security Admission Controller é um mecanismo de políticas do Kubernetes. Ele utiliza políticas escritas em uma linguagem de programação de sua escolha. Essa linguagem deve gerar um binário WebAssembly para SUSE Security Admission Controller usar.

O que é uma política?

Uma política é um Open Container Initiative (OCI) artefato. Ela contém um módulo WebAssembly, o código da política e os metadados necessários para o PolicyServer realizar validações e mutações de solicitações de admissão.

Assim como Kubernetes, SUSE Security Admission Controller utiliza os termos 'PolicyServer' ao discutir o SUSE Security Admission Controller servidor de políticas e policy-server ao discutir Pod ou implantação de um SUSE Security Admission Controller PolicyServer.

Princípios de design

Fazendo uso de recursos essenciais do Kubernetes

A equipe projetou SUSE Security Admission Controller para usar recursos essenciais do Kubernetes, sem reinventar a roda. O projeto utiliza uma combinação de:

  • Controladores do Kubernetes

  • Definições de Recursos Personalizados (CRDs)

  • Webhooks (Validação e Mutação)

  • o sistema de notificação de eventos do Control Plane

Faz uso eficaz da arquitetura do Kubernetes

SUSE Security Admission Controller opera de forma integrada dentro do ecossistema Kubernetes. No seu núcleo, o controlador SUSE Security Admission Controller é um controlador do Kubernetes, monitorando SUSE Security Admission Controller as Definições de Recursos Personalizados (CRDs) e configurando recursos do Kubernetes para executá-los. Essa integração garante que SUSE Security Admission Controller utilize os mecanismos incorporados do Kubernetes, como controladores e CRDs, para observar, gerenciar e aplicar políticas de segurança de forma eficiente.

Definição de política extensível

SUSE Security Admission Controller emprega CRDs para definir e gerenciar SUSE Security Admission Controller recursos, que especificam as regras para validações de solicitações de admissão. Esse design permite que os usuários ampliem as capacidades do Kubernetes com controles de admissão personalizados, garantindo que a aplicação de políticas de segurança e conformidade seja consistente em todo o cluster.

Controle de admissão direto

Quando configurado pelo controlador SUSE Security Admission Controller, o Serviço policy-server recebe solicitações de admissão diretamente do plano de controle do Kubernetes, utilizando ValidationWebhooks e MutatingWebhooks. Essa interação direta simplifica o processo de controle de admissão, reduzindo a latência e aumentando a eficiência na aplicação de políticas.

WebAssembly oferece um ambiente de execução isolado, garantindo que as políticas sejam executadas em isolamento, assim melhorando a segurança e a estabilidade do mecanismo de aplicação de políticas. Esse isolamento impede que as políticas interfiram umas com as outras ou com o sistema host, mitigando o risco de execução de código malicioso. WebAssembly é portátil e eficiente, permitindo que as políticas sejam executadas em diferentes ambientes sem modificação. Essa compatibilidade entre plataformas garante que as políticas SUSE Security Admission Controller sejam versáteis, permitindo que você as distribua e execute em diversos clusters Kubernetes.

Artefatos de política baseados em OCI

As políticas em SUSE Security Admission Controller são artefatos OCI (Open Container Initiative). Essa padronização facilita a distribuição e versionamento das políticas. As políticas contêm tanto os módulos WebAssembly para a lógica de aplicação quanto os metadados necessários para a operação do PolicyServer. O uso de artefatos OCI promove a interoperabilidade e a facilidade de gerenciamento dentro dos ecossistemas de nuvem.

Aplicação granular de políticas

SUSE Security Admission Controller associa políticas com seu próprio webhook de 'validação' ou 'mutação', permitindo uma aplicação granular dos controles de admissão. Essa flexibilidade permite que os administradores adaptem a aplicação das políticas de acordo com necessidades específicas, aprimorando a segurança e a conformidade do cluster Kubernetes.

A SUSE Security Admission Controller pilha

SUSE Security Admission Controller consiste nos seguintes componentes:

  • SUSE Security Admission Controller Recursos Customizados são Recursos Customizados do Kubernetes que simplificam o processo de gerenciamento de políticas.

    SUSE Security Admission Controller se integra ao Kubernetes usando Controle de Admissão Dinâmico. Em particular, SUSE Security Admission Controller opera como um Webhook de Admissão do Kubernetes. O policy-server é o endpoint do Webhook chamado pelo servidor da API do Kubernetes para validar solicitações.

  • O SUSE Security Admission Controller controlador é um controlador do Kubernetes que reconcilia os Recursos Customizados de SUSE Security Admission Controller. Esse controlador cria partes da pilha SUSE Security Admission Controller. Ele também traduz a configuração de SUSE Security Admission Controller em diretrizes do Kubernetes.

    O kubewarden-controller registra os objetos necessários MutatingWebhookConfiguration ou ValidatingWebhookConfiguration com o servidor da API do Kubernetes.

  • SUSE Security Admission Controller políticas são módulos WebAssembly que contêm a lógica de validação ou mutação. Os módulos WebAssembly têm documentação detalhada nas seções escrevendo políticas.

  • O Servidor de Políticas recebe solicitações de validação. Ele valida as solicitações executando SUSE Security Admission Controller as políticas.

  • O scanner de auditoria inspeciona os recursos já no cluster. Ele identifica aqueles que violam SUSE Security Admission Controller as políticas.

    Scanner de auditoria verifica constantemente os recursos declarados no cluster, sinalizando aqueles que não aderem mais às SUSE Security Admission Controller políticas implantadas.

    %%{ init: { "flowchart": { "htmlLabels": false, } } }%% graph LR accTitle: Admission Controller architecture accDescr: A diagram showing the architecture of Admission Controller components. subgraph " " direction LR subgraph " " direction LR k8s(("Kubernetes")) registry[("OCI registry")] end subgraph kw["`**Admission Controller**`"] controller("`**Controller**`") subgraph policy-server["`**policy-server**`"] direction LR kw-policy-1{{"Policy 1"}} kw-policy-2{{"Policy 2"}} kw-policy-3{{"Policy 3"}} end webhooks(["ValidationWebhooks and\nMutatingWebhooks"]) audit-scanner["KW audit scanner"] end end policy-server -->|"downloads\npolicies from"| registry controller -->|"watches for\nevents"| k8s controller -->|"creates"| webhooks controller -->|"creates\npolicy-server\ninstances"| policy-server k8s -. "sends admission\nrequests using" .-> webhooks webhooks -. "sent admission\nrequests from K8s" .-> policy-server audit-scanner -->|"sends audit\nadmission requests"| policy-server
    Figure 1. Arquitetura

A jornada de uma SUSE Security Admission Controller política

PolicyServer Padrão

Em um novo cluster, os componentes SUSE Security Admission Controller definidos são:

  • Definições de Recursos Personalizados (CRD)

  • A kubewarden-controller Implantação

  • Um Recurso Personalizado PolicyServer chamado default.

Quando o kubewarden-controller percebe o recurso PolicyServer padrão, ele\ncria uma implantação policy-server do componente PolicyServer.

SUSE Security Admission Controller funciona como um Webhook de Admissão do Kubernetes. O Kubernetes especifica\nutilizando protocolo TLS (TLS) para proteger todos os pontos finais do Webhook. O kubewarden-controller\nconfigura essa comunicação segura por:

  1. Gerando uma Autoridade Certificadora autoassinada

  2. Use esta CA para gerar uma chave de certificado TLS para o Serviço policy-server.

Esses objetos são todos armazenados como Secret recursos no Kubernetes.

Finalmente, kubewarden-controller cria a Implantação policy-server e um\nServiço ClusterIP do Kubernetes para expô-lo dentro da rede do cluster.

Definindo a primeira política

Uma política deve definir em qual policy-server deve ser executada. Ela vincula a uma\ninstância policy-server. Você pode ter políticas diferentes com o mesmo módulo Wasm\ne configurações rodando em muitos PolicyServers. No entanto, você não pode ter uma\ndefinição de política única que rode em muitos PolicyServers.

O kubewarden-controller percebe o novo recurso ClusterAdmissionPolicy e assim encontra o policy-server vinculado e o reconcilia.

Reconciliação de um policy-server

Ao criar, modificar ou excluir um ClusterAdmissionPolicy ou AdmissionPolicy, um loop de reconciliação é ativado em kubewarden-controller, para o policy-server que possui a política. Esse loop de reconciliação cria um ConfigMap com todas as políticas vinculadas ao policy-server. Então, o rollout de implantação do policy-server começa. Isso resulta no início da nova instância policy-server com a configuração atualizada.

No momento da inicialização, o policy-server lê sua configuração do ConfigMap e baixa todas as SUSE Security Admission Controller políticas especificadas. Você pode baixar SUSE Security Admission Controller políticas de servidores HTTP remotos e registros de contêiner.

Você usa parâmetros de configuração de políticas para ajustar o comportamento das políticas. Após a inicialização e o download da política, o policy-server verifica se as configurações de política fornecidas pelo usuário são válidas.

O policy-server valida as configurações de política invocando a função validate_setting exposta por cada política. Há mais documentação na seção referência de especificação da documentação.

Se alguma política receber parâmetros de configuração errados, da especificação de política do usuário, então qualquer solicitação de admissão avaliada por essa política retorna um erro.

Quando o SUSE Security Admission Controller tiver configurado todas as políticas, o policy-server gera um pool de threads de trabalho para avaliar as solicitações recebidas usando as políticas SUSE Security Admission Controller especificadas pelo usuário.

Finalmente, o policy-server inicia um servidor HTTPS, ouvindo solicitações de validação recebidas. O SUSE Security Admission Controller usa a chave TLS e o certificado criados pelo controlador SUSE Security Admission Controller para proteger o servidor web.

O servidor web expõe cada política por um caminho dedicado seguindo a convenção de nomenclatura: /validate/<policy ID>.

Tornando o Kubernetes ciente da política

Todas as instâncias policy-server têm um Readiness Probe, que kubewarden-controller usa para verificar quando o policy-server implantação está pronto para avaliar um AdmissionReview.

Uma vez que SUSE Security Admission Controller marca a implantação policy-server como 'únicamente acessível' ou Ready, o kubewarden-controller torna o servidor da API do Kubernetes ciente da nova política. Isso é feito criando um objeto MutatingWebhookConfiguration ou um objeto ValidatingWebhookConfiguration. Neste contexto, 'únicamente acessível' significa que todas as instâncias do PolicyServer no cluster têm a configuração de política mais recente instalada. A distinção é um ponto sutil, mas é necessária devido à forma como a implementação dos PolicyServers funciona. É possível ter a mesma política em diferentes PolicyServers com configurações diferentes.

Cada política tem um MutatingWebhookConfiguration ou ValidatingWebhookConfiguration dedicado apontando para o endpoint do Webhook servido por policy-server. O endpoint é acessível na URL /validate/<policy ID>.

Política em ação

Agora que toda a infraestrutura necessária está completa, o Kubernetes começa a enviar solicitações de Revisão de Admissão para os endpoints policy-server corretos.

Um policy-server recebe o objeto de Solicitação de Admissão e, com base no endpoint que recebeu a solicitação, utiliza a política correta para avaliá-la.

SUSE Security Admission Controller avalia cada política dentro de sua própria sandbox dedicada de WebAssembly. A comunicação entre uma instância de policy-server (o "host") e a política de WebAssembly (o "convidado") utiliza o protocolo de comunicação waPC. A descrição do protocolo faz parte da documentação de escrevendo políticas. As políticas também podem usar as interfaces fornecidas pelo Interface do Sistema Web Assembly (WASI).

Como SUSE Security Admission Controller lida com muitos PolicyServers e políticas

Um cluster pode ter muitos PolicyServers e SUSE Security Admission Controller políticas definidas. Existem benefícios em ter muitos PolicyServers:

  • Você pode isolar namespaces ou locatários barulhentos, ou aqueles que geram muitas avaliações de políticas, do restante do cluster para não afetar adversamente outras operações do cluster.

  • Você pode executar políticas críticas em um pool dedicado de PolicyServers, tornando sua infraestrutura mais resiliente.

Um recurso PolicyServer define cada policy-server e um recurso ClusterAdmissionPolicy ou AdmissionPolicy define cada política.

Um ClusterAdmissionPolicy e um AdmissionPolicy se vinculam a um policy-server. Qualquer ClusterAdmissionPolicy que não especificar um policy-server se vincula ao PolicyServer padrão. Se um ClusterAdmissionPolicy referenciar um policy-server que não existe, seu estado é unschedulable.

Cada policy-server define muitos pontos de validação, um para cada política definida em seu arquivo de configuração. Você pode carregar a mesma política várias vezes, com diferentes parâmetros de configuração.

Os recursos ValidatingWebhookConfiguration e MutatingWebhookConfiguration tornam o servidor da API do Kubernetes ciente dessas políticas. Então, kubewarden-controller mantém o servidor da API e os recursos de configuração em sincronização.

O servidor da API do Kubernetes encaminha as solicitações de admissão recebidas para o ponto de validação correto exposto por policy-server.