Como fazer auditoria usando restrições

Os objetos de restrição do controlador de políticas permitem que você aplique políticas aos clusters do Kubernetes. Para ajudar a testar suas políticas, adicione uma ação de aplicação às suas restrições. Nesse caso, é possível visualizar as violações em objetos e registros de restrição.

Esta página é destinada a administradores e operadores de TI que querem garantir que todos os recursos executados na plataforma de nuvem atendam a requisitos de conformidade organizacional, fornecendo e mantendo automação para auditar ou aplicar, e que gerenciam o ciclo de vida da infraestrutura de tecnologia subjacente. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Tipos de ações de aplicação

Há três ações de cumprimento: deny, dryrun e warn.

deny é a ação de aplicação padrão. Ela é ativada automaticamente, mesmo que você não adicione uma ação de aplicação à sua restrição. Use deny para evitar que uma determinada operação de cluster ocorra quando houver uma violação.

dryrun permite monitorar violações das regras sem bloquear ativamente as transações. Use-o para testar se as restrições estão funcionando conforme o esperado, antes de ativar a aplicação ativa usando a ação deny. O teste de restrições dessa maneira pode impedir interrupções causadas por uma restrição configurada incorretamente.

warn é semelhante a dryrun, mas também fornece uma mensagem imediata sobre as violações que ocorrem no momento da admissão.

Ao testar novas restrições ou realizar ações de migração, como o upgrade de plataformas, é recomendado alterar as aplicações de política de deny para warn ou dryrun, a fim de testar se as políticas funcionam conforme o esperado.

Como adicionar ações de aplicação

É possível adicionar enforcementAction: deny ou enforcementAction: dryrun a uma restrição.

A restrição de exemplo a seguir, denominada audit.yaml, adiciona a ação dryrun.

#audit.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: user-must-be-3333
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    runAsUser:
      rule: MustRunAs
      ranges:
        - min: 3333
          max: 3333

Crie a restrição. Por exemplo, aplique-a usando kubectl apply -f:

kubectl apply -f audit.yaml

Como visualizar resultados de auditoria

As violações auditadas são anexadas aos objetos de restrição e também são gravadas nos registros. Violações que o controlador de admissão rejeita não aparecem nos registros.

Como ver os resultados da auditoria em objetos de restrição

Para ver violações de uma determinada restrição, execute o seguinte comando e visualize os campos spec.status.

kubectl get constraint-kind constraint-name -o yaml

Exemplo

Para ver o resultado da restrição de audit.yaml, execute o seguinte comando:

kubectl get K8sPSPAllowedUsers user-must-be-3333 -o yaml

O resultado que você vê é semelhante a este:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  creationTimestamp: "2020-05-22T01:34:22Z"
  generation: 1
  name: user-must-be-3333
  resourceVersion: "13351707"
  selfLink: /apis/constraints.gatekeeper.sh/v1beta1/k8spspallowedusers/user-must-be-3333
  uid: 5d0b39a8-9bcc-11ea-bb38-42010a80000c
spec:
  enforcementAction: dryrun
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Pod
  parameters:
    runAsUser:
      ranges:
      - max: 3333
        min: 3333
      rule: MustRunAs
 status:
  auditTimestamp: "2020-05-22T01:39:05Z"
  byPod:
  - enforced: true
    id: gatekeeper-controller-manager-6b665d4c4d-lwnz5
    observedGeneration: 1
 totalViolations: 5
  violations:
  - enforcementAction: dryrun
    kind: Pod
    message: Container git-sync is attempting to run as disallowed user 65533
    name: git-importer-86564db8cb-5r4gs
    namespace: config-management-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container manager is attempting to run as disallowed user 1000
    name: gatekeeper-controller-manager-6b665d4c4d-lwnz5
    namespace: gatekeeper-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container kube-proxy is attempting to run without a required securityContext/runAsUser
    name: kube-proxy-gke-fishy131-default-pool-7369b17c-cckf
    namespace: kube-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container kube-proxy is attempting to run without a required securityContext/runAsUser
    name: kube-proxy-gke-fishy131-default-pool-7369b17c-jnhb
    namespace: kube-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container kube-proxy is attempting to run without a required securityContext/runAsUser
    name: kube-proxy-gke-fishy131-default-pool-7369b17c-xrd8
    namespace: kube-system

Como ver os resultados da auditoria nos registros

Use a Análise de registros para recuperar, visualizar e analisar dados de registros do Policy Controller.

Para ver todos os registros do controlador de política, execute o seguinte comando:

kubectl logs -n gatekeeper-system -l gatekeeper.sh/system=yes

Os resultados da auditoria têm "process":"audit" nas linhas do registro. Assim, é possível colocar o resultado em outro comando e filtrar por essas linhas. Por exemplo, é possível usar jq, que analisa arquivos JSON e permite definir um filtro para um tipo de registro específico.

Exemplo de resultado da auditoria do registro:

{
"level":"info",
"ts":1590111401.9769812,
"logger":"controller",
"msg":"Container kube-proxy is attempting to run without a required securityContext/runAsUser",
"process":"audit",
"audit_id":"2020-05-22T01:36:24Z",
"event_type":"violation_audited",
"constraint_kind":"K8sPSPAllowedUsers",
"constraint_name":"user-must-be-3333",
"constraint_namespace":"",
"constraint_action":"dryrun",
"resource_kind":"Pod",
"resource_namespace":"kube-system",
"resource_name":"kube-proxy-gke-fishy131-default-pool-7369b17c-xrd8"
}

A seguir