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.

Proteção dos Admission Controller webhooks

A pilha SUSE Security Admission Controller utiliza webhooks para impor políticas em um cluster Kubernetes. Cada instância PolicyServer expõe um webhook que o servidor de API do Kubernetes chama para validar e modificar recursos. Além disso, o kubewarden-controller expõe webhooks para validar e modificar os recursos personalizados fornecidos pelo projeto Admission Controller.

Para diminuir sua superfície de ataque, você deve limitar o acesso a esses webhooks apenas aos chamadores válidos que eles têm:

o servidor de API do Kubernetes
o componente scanner de auditoria.

Você pode fazer isso usando políticas de rede e autenticação de forma independente ou juntas, para proteger os webhooks contra ataques.

Bloquear tráfego externo usando políticas de rede

Os webhooks devem aceitar apenas solicitações do servidor de API do Kubernetes e do componente scanner de auditoria. Por padrão, no entanto, os webhooks podem aceitar tráfego de qualquer origem. Se você estiver usando uma Interface de Rede de Contêiner (CNI) que suporte Políticas de Rede, pode criar uma política que bloqueie tráfego que não se origina do servidor de API.

O recurso NetworkPolicy incorporado no Kubernetes não pode bloquear ou admitir tráfego dos hosts do cluster. Além disso, o processo kube-apiserver está sempre em execução na rede do host. Portanto, você deve usar os recursos avançados de política de rede da CNI em uso. Exemplos para Calico e Cilium seguem. Consulte a documentação do seu CNI para mais detalhes.

Calico

Use o recurso NetworkPolicy no grupo de API crd.projectcalico.org/v1 para definir uma política de rede como a seguinte:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-k8s-and-audit-scanner
  namespace: kubewarden
spec:
  selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        nets:
        - 192.168.42.0/24
      destination:
        selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'
    - action: Allow
      protocol: TCP
      source:
        namespaceSelector: 'kubernetes.io/metadata.name == "kubewarden"'
      destination:
        selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'

Esta política de rede usa seletores de rótulos introduzidos na versão Admission Controller 1.23.0. Se você estiver usando uma versão mais antiga, atualize os rótulos na política para corresponder à sua implantação.

Mais especificamente, escreva os

selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'

seletores como:

selector: 'app.kubernetes.io/name == "kubewarden-controller" || has(kubewarden/policy-server)'

Cilium

Use o recurso CiliumNetworkPolicy no grupo de API cilium.io/v2 para definir uma política de rede como a seguinte:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-k8s-and-audit-scanner
  namespace: kubewarden
spec:
  endpointSelector:
    matchExpressions:
      - key: app.kubernetes.io/component
        operator: In
        values:
          - policy-server
          - controller
  ingress:
    - fromEntities:
      - host
      - remote-node
    - fromEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kubewarden

Mais especificamente, escreva a

matchExpressions:
  - key: app.kubernetes.io/component
    operator: In
    values:
      - policy-server
      - controller

expressão como:

endpointSelector:
matchExpressions:
  - key: app.kubernetes.io/name
    operator: In
    values:
      - kubewarden-controller
  - key: kubewarden/policy-server
    operator: Exists

Exija que o servidor de API do Kubernetes se autentique no webhook

Consulte como configurar mTLS no webhook para um guia passo a passo sobre como configurar o servidor de API do Kubernetes do K3s para se autenticar no webhook.

Os webhooks expostos pela pilha Admission Controller devem aceitar apenas solicitações do servidor de API do Kubernetes ou do componente de scanner de auditoria. Por padrão, esses webhooks não exigem que os clientes se autentiquem neles. Eles aceitam qualquer solicitação.

Você pode configurar os webhooks para exigir credenciais, de modo que apenas o servidor de API e os processos do scanner de auditoria possam acessá-los. Consulte documentação do Kubernetes para mais informações.

Configure o servidor de API para apresentar um certificado de cliente ao webhook, apontando para um arquivo AdmissionConfiguration para configurar os plug-ins ValidatingAdmissionWebhook e MutatingAdmissionWebhook:

Crie um arquivo chamado admission.yaml com o seguinte conteúdo:
```
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
 configuration:
   apiVersion: apiserver.config.k8s.io/v1
   kind: WebhookAdmissionConfiguration
   kubeConfigFile: "/etc/k8s/admission/kubeconfig"
- name: MutatingAdmissionWebhook
 configuration:
   apiVersion: apiserver.config.k8s.io/v1
   kind: WebhookAdmissionConfiguration
   kubeConfigFile: "/etc/k8s/admission/kubeconfig"
```
Este é o mesmo arquivo de configuração usado para configurar outros plug-ins, como PodSecurity. Se sua distribuição ou configuração usar plug-ins de admissão adicionais, você também deve configurá-los.
Crie o arquivo kubeconfig ao qual os plug-ins de admissão se referem. Admission Controller suporta apenas autenticação de certificado de cliente, então gere um par de chaves TLS e configure o kubeconfig para usar ou client-certificate e client-key ou client-certificate-data e client-key-data.

Por exemplo:
```
apiVersion: v1
kind: Config
users:
- name: '*.kubewarden.svc'
  user:
    client-certificate: /path/to/client/cert
    client-key: /path/to/client/key
```
Inicie o binário kube-apiserver com a flag --admission-control-config-file apontando para o seu arquivo AdmissionConfiguration. A maneira de fazer isso varia conforme a distribuição, e não é suportada universalmente, como em provedores de Kubernetes hospedados. Consulte a documentação para a sua distribuição do Kubernetes.
Torne o certificado da CA raiz que emitiu o certificado de cliente do servidor API disponível para a pilha Admission Controller.

Coloque seu conteúdo em um ConfigMap no namespace kubewarden usando uma chave chamada client-ca.crt.

Assumindo que a CA raiz está disponível em /etc/k8s/admission/certs/rootCA.crt, crie o ConfigMap com o seguinte comando:
```
kubectl create configmap -n kubewarden api-server-mtls \
   --from-file=client-ca.crt=/etc/k8s/admission/certs/rootCA.crt
```
Por fim, ao instalar o gráfico Helm kubewarden-controller, certifique-se de habilitar os seguintes valores:
- Defina mTLS.enable como true.
- Defina mTLS.configMapName como o nome do ConfigMap que foi criado anteriormente.
  
  O nome do ConfigMap é api-server-mtls, então o comando Helm para instalar o kubewarden-controller é:
  helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller \ --set mTLS.enable=true \ --set mTLS.configMapName=api-server-mtls
  O controlador Admission Controller cria um certificado de cliente para uso pelo componente do scanner de auditoria. O certificado é automaticamente rotacionado pelo controlador quando necessário.