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.

Início rápido

A pilha SUSE Security Admission Controller é composta por:

  • Um ou mais recursos ClusterAdmissionPolicy: isso define políticas para clusters Kubernetes.

  • Um ou mais recursos PolicyServer: representando uma implantação de um Admission Controller PolicyServer. O Admission Controller PolicyServer carrega e avalia as políticas do seu administrador.

  • Um ou mais recursos AdmissionPolicy: políticas para um namespace definido.

  • Uma implantação de um kubewarden-controller: este controlador monitora os recursos ClusterAdmissionPolicy e interage com os componentes Admission Controller PolicyServer.

Admission Controller descreve suas Definições de Recursos Personalizados (CRDs) do Kubernetes aqui.

Admission Controller Os CRDs mencionados neste tutorial e no restante da documentação têm nomes curtos, que são mais fáceis de usar. Estes são os nomes curtos para os CRDs:

Resource shortName

AdmissionPolicies

ap

ClusterAdmissionPolicies

cap

AdmissionPolicyGroups

apg

ClusterAdmissionPolicyGroups

capg

PolicyServers

ps

Instalação

Autenticação

Você pode recuperar políticas Admission Controller do registro de contêiner do GitHub em https://ghcr.io.. Você precisa de autenticação para usar o repositório com o CLI Admission Controller, usando um token de acesso pessoal do GitHub (PAT). A documentação deles orienta você a criar um se você ainda não o fez. Então você autentica com um comando como:

echo $PAT | docker login ghcr.io --username <my-gh-username> --password-stdin

Implante a pilha Admission Controller usando os gráficos helm da seguinte forma:

helm repo add kubewarden https://charts.kubewarden.io
helm repo update kubewarden

Instale os seguintes gráficos Helm no namespace kubewarden em seu cluster Kubernetes:

  • kubewarden-crds, que registra as definições de recursos personalizados ClusterAdmissionPolicy, AdmissionPolicy e PolicyServer. Além disso, as definições de recursos personalizados {report} usadas pelo scanner de auditoria.

  • kubewarden-controller, que instala o controlador Admission Controller e o scanner de auditoria.

    Se você precisar desativar o componente do scanner de auditoria, consulte a página de documentação da instalação do scanner de auditoria.

  • kubewarden-defaults, que cria um recurso PolicyServer chamado default. Ele também pode instalar um conjunto de políticas recomendadas para proteger seu cluster, aplicando boas práticas bem conhecidas.

helm install --wait -n kubewarden --create-namespace kubewarden-crds kubewarden/kubewarden-crds
helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller
helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

Como v0.4.0, um recurso PolicyServer chamado default não é criado usando o gráfico kubewarden-controller. Agora, um gráfico Helm chamado kubewarden-defaults instala o servidor de políticas padrão.

Isso significa que, se não estiver usando a versão mais recente do kubewarden-controller ao fazer upgrade ou excluir, seu servidor de políticas padrão não será atualizado ou excluído. Portanto, você pode encontrar problemas se tentar instalar o kubewarden-defaults com informações conflitantes, por exemplo, o mesmo nome de servidor de políticas. Para instalar futuras atualizações do gráfico Helm kubewarden-defaults, remova o recurso PolicyServer existente criado pelo kubewarden-controller antes de instalar o novo gráfico. Agora você pode fazer upgrade do seu servidor de políticas usando upgrades do Helm sem conflitos de recursos. Quando você remove o PolicyServer, você remove todas as políticas vinculadas a ele também.

Os valores de configuração padrão são suficientes para a maioria das implantações. A documentação descreve todas as opções.

Componentes principais

Admission Controller possui três componentes principais com os quais você interage:

PolicyServer

O kubewarden-controller gerencia um Admission Controller PolicyServer. Você pode implantar múltiplos PolicyServers no mesmo cluster Kubernetes.

Um PolicyServer valida as requisições recebidas executando políticas Admission Controller contra elas.

Esta é a configuração padrão do PolicyServer:

apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
  name: reserved-instance-for-tenant-a
spec:
  image: ghcr.io/kubewarden/policy-server:v1.3.0
  replicas: 2
  serviceAccountName: ~
  env:
    - name: KUBEWARDEN_LOG_LEVEL
      value: debug

Verifique a última versão PolicyServer lançada e altere a tag para corresponder.

Visão geral dos atributos do recurso PolicyServer:

Obrigatória Marcador Descrição

Y (S)

image

O nome da imagem do contêiner

Y (S)

replicas

O número de instâncias desejadas

N

serviceAccountName

O nome do ServiceAccount a ser usado para a implantação PolicyServer. Se não houver valor fornecido, o padrão ServiceAccount do namespace de instalação, de kubewarden-controller, será utilizado.

N

env

A lista de variáveis de ambiente

N

annotations

A lista de anotações

Alterar qualquer um desses atributos causa uma implantação do PolicyServer com a nova configuração.

ClusterAdmissionPolicy

O recurso ClusterAdmissionPolicy é o kernel da pilha Admission Controller. Ele define como as políticas avaliam as requisições.

Impor políticas é a operação mais comum que um administrador Kubernetes realiza. Você pode declarar quantas políticas quiser, cada uma direciona um ou mais recursos do Kubernetes (ou seja, pods, Custom Resource e outros). Você também especifica o tipo de operações aplicadas aos recursos direcionados. As operações disponíveis são CREATE, UPDATE, DELETE e CONNECT.

Configuração padrão de ClusterAdmissionPolicy:

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities
spec:
  policyServer: reserved-instance-for-tenant-a
  module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.9
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  mutating: true
  settings:
    allowed_capabilities:
      - CHOWN
    required_drop_capabilities:
      - NET_ADMIN

Visão geral dos atributos do recurso ClusterAdmissionPolicy:

Obrigatória Marcador Descrição

N

policy-server

Identifica um objeto PolicyServer existente. Apenas esta instância de PolicyServer serve a política. O servidor de políticas chamado default serve um ClusterAdmissionPolicy sem um PolicyServer explícito.

Y (S)

module

A localização da política de Admission Controller. Os seguintes esquemas são permitidos:

N

- registry: Download da política de um registro de contêiner compatível com artefatos OCI. Exemplo: registry://<OCI registry/policy URL>

N

- http, https: Download da política de um servidor HTTP(s) regular. Exemplo: https://<website/policy URL>

N

- file: Carregue a política de um arquivo no sistema de arquivos do computador. Exemplo: file:///<policy WASM binary full path>

Y (S)

resources

Os recursos do Kubernetes avaliados pela política

Y (S)

operations

Quais operações para os tipos dados anteriormente devem ser encaminhadas para esta política de admissão pelo servidor da API para avaliação.

Y (S)

mutating

Defina este valor booleano true para políticas que podem mutar solicitações recebidas

N

settings

Um objeto de formato livre que contém os valores de configuração da política

N

failurePolicy

A ação a ser tomada se a solicitação avaliada por uma política resultar em um erro. As seguintes opções são permitidas:

N

- Ignore: ignorar um erro ao chamar o webhook e a solicitação da API continua.

N

- Fail: um erro ao chamar o webhook faz com que a admissão falhe e a solicitação da API seja rejeitada.

O controlador registra o webhook de recursos ClusterAdmissionPolicy * scope. Isso significa que os webhooks registrados encaminham todas as solicitações que correspondem ao resources e operations fornecidos, seja de recursos com namespace ou em todo o cluster.

AdmissionPolicy

AdmissionPolicy é um recurso de namespace. A política processa apenas as solicitações que estão direcionadas ao namespace com o AdmissionPolicy definido. Além disso, não há diferenças funcionais entre os recursos AdmissionPolicy e ClusterAdmissionPolicy.

AdmissionPolicy requer Kubernetes 1.21.0 ou superior. Isso ocorre porque Admission Controller usa o rótulo kubernetes.io/metadata.name, introduzido no Kubernetes 1.21.0.

A documentação completa desses Recursos Personalizados está aqui ou em docs.crds.dev.

Exemplo: Imponha sua primeira política

Usaremos a política pod-privileged. Queremos impedir a criação de contêineres privilegiados dentro do nosso cluster Kubernetes, impondo esta política.

Vamos definir um ClusterAdmissionPolicy para fazer isso:

kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: privileged-pods
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.2.2
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: false
EOF

Isso produz a seguinte saída:

clusteradmissionpolicy.policies.kubewarden.io/privileged-pods created

Após instanciar um ClusterAdmissionPolicy, o status se torna pending, e força um rollout do PolicyServer direcionado. No exemplo, é o PolicyServer chamado default. Você pode monitorar o rollout executando o seguinte comando:

kubectl get clusteradmissionpolicy.policies.kubewarden.io/privileged-pods

Você deve ver a seguinte saída:

NAME              POLICY SERVER   MUTATING   STATUS
privileged-pods   default         false      pending

Uma vez que a nova política esteja pronta, o kubewarden-controller registra um objeto ValidatingWebhookConfiguration para atendê-la.

O status ClusterAdmissionPolicy se torna active uma vez que a implantação é concluída para cada instância PolicyServer. Mostre ValidatingWebhookConfigurations com o seguinte comando:

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l kubewarden

Você deve ver a seguinte saída:

NAME                          WEBHOOKS   AGE
clusterwide-privileged-pods   1          9s

Uma vez que o ClusterAdmissionPolicy esteja ativo e o ValidatingWebhookConfiguration registre, você pode testar a política.

Primeiro, você pode criar um Pod com um Container não em modo privileged:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: unprivileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
EOF

Isso produz a seguinte saída:

pod/unprivileged-pod created

O Pod foi criado com sucesso.

Agora, você pode criar um Pod com pelo menos uma flag de Container privileged:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      securityContext:
          privileged: true
EOF

A política nega a criação do Pod e você deve ver a seguinte mensagem:

Error from server: error when creating "STDIN": admission webhook "clusterwide-privileged-pods.kubewarden.admission" denied the request: Privileged container is not allowed

Ambos os exemplos não definiram um namespace, o que significa que o namespace default foi o alvo. No entanto, como você pode ver no segundo exemplo, a política ainda é aplicada. Como mencionado anteriormente, isso se deve ao escopo ser global do cluster e não direcionar um namespace específico.

Desinstalar

Você pode remover os recursos criados desinstalando os charts do helm da seguinte forma:

helm uninstall --namespace kubewarden kubewarden-defaults
helm uninstall --namespace kubewarden kubewarden-controller
helm uninstall --namespace kubewarden kubewarden-crds

Após a remoção dos charts do helm, remova o namespace do Kubernetes usado para implantar a pilha Admission Controller:

kubectl delete namespace kubewarden

Admission Controller contém um hook de pré-exclusão do helm que remove todos os PolicyServer`s e `kubewarden-controller`s. Então o `kubewarden-controller exclui todos os recursos, por isso é importante que o kubewarden-controller esteja em execução quando o helm uninstall for executado.

Admission Controller exclui ValidatingWebhookConfigurations e MutatingWebhookConfigurations. Verifique isso com:

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"

Se esses recursos não forem removidos automaticamente, remova-os manualmente usando o seguinte comando:

kubectl delete -l "kubewarden" validatingwebhookconfigurations.admissionregistration.k8s.io
kubectl delete -l "kubewarden" mutatingwebhookconfigurations.admissionregistration.k8s.io

Concluindo

ClusterAdmissionPolicy é o recurso kernel que um operador de cluster deve gerenciar. O módulo kubewarden-controller cuida automaticamente da configuração para o restante dos recursos necessários para executar as políticas.

Próximos passos

Agora, você está pronto para implantar Admission Controller! Dê uma olhada nas políticas em artifacthub.io, em GitHub, ou reutilize políticas Rego existentes, conforme mostrado nos capítulos seguintes.

Lista completa de políticas disponíveis no ArtifactHub