Системный журнал#

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

В DropApp Plus системным журналом является Kubelet Logs. Kubelet Logs или журналы kubelet можно просмотреть, чтобы убедиться в работоспособности узлов кластера DropApp Plus.

Настройка системного журнала#

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

Следующие значения уровней ведения журнала записываются в файл syslog.h, и им предшествуют их числовые эквиваленты:

• 0= emerg: система непригодна для использования;

• 1= alert: меры должны быть приняты немедленно;

• 2= crit: критические условия;

• 3= err: условия ошибки;

• 4= warn: условия предупреждения;

• 5= notice: нормальное, но значимое состояние;

• 6= info: информационный;

• 7= debug: сообщения уровня отладки;

Два следующих значения не являются частью syslog.h, но широко используются:

• 8= trace: сообщения уровня трассировки, которые более подробны, чем debug сообщения;

• 9= unknown: когда система журналирования получает значение, которое она не распознает.

Существует возможность настроить политику записей системного журнала, которая будет использоваться при регистрации запросов.

Настроить политику записей системного журнала может только пользователь с ролью cluster-admin.

1. Отредактируйте APIServer с помощью команды:

   oc edit apiserver cluster
   

2. Измените поле spec.audit.profile:

   apiVersion: config.openshift.io/v1
   kind: APIServer
   metadata:
   ...
   spec:
       audit:
       profile: WriteRequestBodies
   

3. Сохраните файл, подтвердив внесение изменений.

4. Подождите, пока pod API-сервера Kubernetes обновятся. Это может занять несколько минут.

5. Просмотрите состояние NodeInstallerProgressing для API-сервера Kubernetes, чтобы убедиться, что на всех pod внесены последние изменения.

   oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
   

   Вывод команды AllNodesAtLatestRevision свидетельствует об успешном обновлении:

   AllNodesAtLatestRevision
   3 nodes are at revision 12
   

   Если в выводе команды отображается одно из следующих сообщений, необходимо подождать несколько минут и повторить попытку:

   • 3 nodes are at revision 11; 0 nodes have achieved new revision 12;

   • 2 nodes are at revision 11; 1 nodes are at revision 12.

Доступ к системному журналу#

Администратор кластера может развернуть ведение журнала DropApp Plus для агрегирования всех журналов из кластера, таких как: журналы аудита системы узлов, журналы контейнера приложений и журналы инфраструктуры. Logging объединяет журналы со всего кластера и сохраняет их в хранилище журналов по умолчанию.

Logging объединяет следующие типы журналов:

• application — журналы контейнера, генерируемые пользовательскими приложениями, работающими в кластере, за исключением приложений-контейнеров инфраструктуры;

• infrastructure — журналы, генерируемые компонентами инфраструктуры, работающими в кластере и на узлах. Компоненты инфраструктуры — это pod, которые запускаются в проектах openshift, kube или default.

• audit — журналы, созданные Auditd - системой аудита узлов, которые хранятся в файле /var/log/audit/audit.log, а также журналы аудита с API-серверов Kubernetes и DropApp Plus.

Основными компонентами Logging являются:

• сбор — это компонент, который собирает логи из кластера, форматирует их и пересылает в хранилище логов. По умолчанию реализуется с помощью Fluentd. Не входит в состав поставки DropApp Plus и не является обязательным инструментом;

• хранилище журналов — это компонент, где хранятся журналы. По умолчанию реализуется с помощью Elasticsearch. Не входит в состав поставки DropApp Plus и не является обязательным инструментом. Хранилище журналов по умолчанию оптимизировано для краткосрочного хранения;

• визуализация — это компонент пользовательского интерфейса, который можно использовать для просмотра журналов, графиков, диаграмм и т.д. По умолчанию реализуется с помощью Kibana. Не входит в состав поставки DropApp Plus и не является обязательным инструментом.

Поля записи системного журнала#

Следующие поля могут присутствовать в записях журнала, экспортируемых Logging:

• message;

• structured;

• @timestamp;

• hostname;

• ipaddr4;

• ipaddr6;

• level;

• pid;

• service;

• tags;

• file;

• offset;

• kubernetes:

  • kubernetes.pod_name;

  • kubernetes.pod_id;

  • kubernetes.namespace_name;

  • kubernetes.namespace_id;

  • kubernetes.host;

  • kubernetes.container_name;

  • kubernetes.annotations;

  • kubernetes.labels;

  • kubernetes.event;

  • kubernetes.event.verb;

  • kubernetes.event.metadata;

  • kubernetes.event.involvedObject;

  • kubernetes.event.reason;

  • kubernetes.event.source_component;

• OpenShift;

• openshift.labels.

Записи системного журнала форматируются как объекты JSON.

Для поиска по этим полям в Elasticsearch и Kibana используйте полное имя поля, разделенное точками. Например, с URL-адресом Elasticsearch /_search для поиска имени pod используйте /_search/q=kubernetes.pod_name:name-of-my-pod.

Поля верхнего уровня могут присутствовать в каждой записи.

Исходный текст записи журнала имеет кодировку UTF-8.

Используйте аудит, чтобы взаимодействовать с журналами аудита DropApp Plus. Каждый запрос может быть записан с соответствующим этапом:

• RequestReceived - этап для событий, генерируемых, как только обработчик аудита получает запрос, и до того, как он будет делегирован вниз по цепочке обработчиков.

• ResponseStarted - этап после отправки заголовков ответа, но до отправки тела ответа. Этот этап генерируется только для длительных запросов (например, watch).

• ResponseComplete - этап, когда ответ завершен, и байты отправляться не будут.

• Panic - события, генерируемые при возникновении kernel panic.

Основные события#

Примеры основных событий системного журнала: