Аудит K8S - как получить все варианты политики? - PullRequest
0 голосов
/ 07 января 2020

Я хотел бы определить политику для журнала аудита, которая будет включать информацию только о создании модуля. Я хотел бы убедиться, что все журналы аудита не появятся. Как я могу найти все варианты, которые может иметь политика? Я хотел бы иметь только

- level: RequestResponse
    resources:
    - group: ""
      # Resource "pods" doesn't match requests to any subresource of pods,
      # which is consistent with the RBAC policy.
      resources: ["pods"]

Я использовал официальный сайт k8s и использую их пример , я изменил все на "None", кроме правила "Pods", и все же я получил много других журналов, не связанных с модулями.

Моя политика:

omitStages:
  - "RequestReceived"
rules:
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]

  - level: None
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # core API group
      resources: ["endpoints", "services"]

  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # Wildcard matching.
    - "/version"

  # Log the request body of configmap changes in kube-system.
  - level: None
    resources:
    - group: "" # core API group
      resources: ["configmaps"]

  - level: None
    resources:
    - group: "" # core API group
      resources: ["secrets", "configmaps"]

  - level: None
    resources:
    - group: "" # core API group
    - group: "extensions" # Version of group should NOT be included.


  - level: None
    # Long-running requests like watches that fall under this rule will not
    # generate an audit event in RequestReceived.
    omitStages:
      - "RequestReceived"```

1 Ответ

0 голосов
/ 13 января 2020

Простое изменение примера конфигурации .yaml не решит вашу проблему. Необходимо точно понимать, как работает файл политики аудита.

Когда событие обрабатывается, оно сравнивается с правилами политики аудита по порядку, и первое соответствующее правило устанавливает уровень аудита события.

Вот пример правила, которое вы хотите настроить в вашем случае использования. Если событие соответствует правилу, сервер API Kubernetes создает запись журнала на уровне RequestResponse.

- level: RequestResponse
  verbs: ["create"]
  resources:
    - group: "" # core
      resources: ["pods", "pods/status"]
  omitStages:
    - "RequestReceived"

Событие соответствует правилу, если выполняются все следующие условия:

  • Событие не соответствует ни одному предыдущему правилу в файле политики.
  • Вызов create.
  • Запрос к ресурсу pods или pods/status .
  • Событие не относится к этапу RequestReceived вызова.

Если вы по-прежнему регистрируете записи, которые вы хотели бы отфильтровать, добавьте правила level: None до Приведенный выше пример, поскольку файл политики аудита Kubernetes начинается с правил, которые указывают, что определенные события вообще не должны регистрироваться.

Пожалуйста, дайте мне знать, если это поможет.

РЕДАКТИРОВАТЬ:

как я могу убедиться, что я охватываю все варианты аудита K8S? Есть ли какое-либо «общее» правило, которое говорит «ничего не регистрировать», и перед этим правилом я добавлю только мои специфичные c журналы?

Это зависит от вашего кластера. Самый простой способ добиться этого:

  • установить правило, которое вы хотите регистрировать
  • проверить журналы, если они ловят то, что вы не хотите
  • добавьте level: None правило перед тем, которое вы создали, чтобы исключить ненужные события

относительно создания модуля, если я хочу быть подробнее c и получать журналы только из пространства имен "по умолчанию" и не формировать другие пространства имен

То же самое можно применить здесь. Просто добавьте правило level: None, которое исключает события из других пространств имен.

...