myconnector

package: myconnector

title: myconnector(1)

summary: remote desktop client.

text:
# myconnector(1)

## НАИМЕНОВАНИЕ
MyConnector - remote desktop client.

## СИНТАКСИС
myconnector [options]

## ОПИСАНИЕ
Программа-фронтэнд для удаленного администрирования компьютеров с различными операционными системами. Поддерживается большинство распространенных типов подключения (RDP, VNC, X2GO, Citrix, VMware, etc).

## ОПЦИИ
<без опций>

Запустить программу в режиме графического интерфейса.

-c CONNECTION, --connection CONNECTION

Подключиться к сохраненному подключению по его имени.

FILE, -f FILE, --file FILE

Подключиться с помощью файла подключения (.myc, .remmina, .rdp).

-l, --list

Вывести список сохраненных подключений.

-e, --edit

Редактировать конфигурационный файл.

--kiosk <option>

Управление режимом КИОСК (подробнее: '--kiosk help').

-u, --update

Обновление программы через Интернет.

-r, --remove

Удаление программы (установленной из исходников).

-v, --version

Вывести информацию о версии программы и завершить работу.

-d, --debug

Запуск программы в режиме отображения журналов работы в реальном времени.

-h, --help

Вывести краткую справку и завершить работу.

-q, --quit

Закрыть все существующие копии программы.

## ССЫЛКИ
https://myconnector.ru/

https://docs.myconnector.ru/

## АВТОР
Evgeniy Korneechev <ek@myconnector.ru>

branch: sisyphus


myconnector-kiosk

package: myconnector-kiosk

title: myconnector-kiosk(1)

summary: Mode KIOSK for 'MyConnector'

text:
# myconnector-kiosk(1)

## НАИМЕНОВАНИЕ
myconnector-kiosk - Mode KIOSK for 'MyConnector'

## ОПИСАНИЕ
Конфигурационный файл режима КИОСК программы MyConnector - /etc/myconnector/kiosk.conf

mode - один из следующих режимов работы:

"0" - КИОСК отключен

"1" - запуск программы MyConnector в режиме КИОСК

"2" - соединение с сохраненным подключением

"3" - ВЕБ-киоск

file - файл подключения для mode=2 url - URL для ВЕБ-киоска

user - имя пользователя для режима КИОСК

autologin - управление автовходом пользователя

True,Yes - включен

False,No - отключен

ctrl_disabled - отключение "Ctrl" в ВЕБ-киоске

True,Yes - отключен

False,No - включен

## СМ. ТАКЖЕ
myconnector(1)

## ССЫЛКИ
https://myconnector.ru

https://docs.myconnector.ru/ru/latest/kiosk.html

## АВТОР
Evgeniy Korneechev <ek@myconnector.ru>


openscada

package: openscada-core

title: openscada(1)

summary: Программа главного запуска OpenSCADA

text:
# openscada(1)

## НАЗВАНИЕ
openscada - Программа главного запуска OpenSCADA

## СИНТАКСИС
openscada [параметры]

## ОПИСАНИЕ
Система OpenSCADA это открытая реализация SCADA (Supervisory Control And Data Acquisition) и HMI (Human-Machine Interface) системы. Основными свойствами системы являются: открытость(GPL), многоплатформенность, модульность и масштабируемость.

Сердцем системы является модульное ядро. В зависимости от того какие модули подключены, система может выполнять как функции различных серверов, так и функции клиентов клиент-серверной архитектуры. Собственно, архитектура системы позволяет реализовывать распределённые клиент-серверные системы любой сложности и сочетания. Для достижения высокого быстродействия, за счёт сокращения времени коммуникаций, архитектура позволяет объединять функции распределённых систем в одной программе.

Программа openscada это главный пускатель, который позволяет Вам запустить OpenSCADA в конфигурации (типично в файле /etc/oscada.xml) полноценной SCADA или ПЛК и режима демона. Для гибкого контроля используйте ориентированную на проекты обёртку openscada_start.

Для доступа к типовой конфигурации используйте учётную запись "root" и пароль "openscada" или запись "user" и пароль "user".

## ПАРАМЕТРЫ

### Основные опции:
-h, --help

Информация по опциям системы OpenSCADA.

--config=файл

Конфигурационный файл станции.

--station=идентификатор

Идентификатор станции.

--statName=имя

Имя станции.

--demon, --daemon

Запуск в режиме демона.

--pidFile=файл

Файл для помещения ID процесса программы сюда.

--coreDumpAllow

Установить ограничения для разрешения генерации дампа памяти при крушении программы.

--modPath=путь

Путь к модулям (/var/os/modules/).

--messLev=уровень

Обрабатываемый уровень сообщений (0-7).

--log=направление

Направление сообщений в, по битовому полю:

0x1 - системный логер (syslogd);

0x2 - стандартный выход (stdout);

0x4 - стандартный выход ошибок (stderr);

0x8 - архив сообщений.

### Параметры модуля <Archive:FSArch>:
--noArchLimit

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

### Параметры модуля <UI:QTStarter>:
--sync

Переключение в синхронный режим X11 для отладки.

--widgetcount

Печать отладочных сообщений при выходе, о количеcтве виджетов оставшихся неудалёнными и максимальном их количестве.

--qws

Делает данное приложение сервером с Qt для встраиваемого Linux.

--style=имя

Установить GUI стиль в имя (windows, platinum, plastique, ...).

--stylesheet=путь

Установить таблицу стилей из файла по пути.

--session=имя

Восстановить из предыдущего сеанса с указанным именем.

--reverse

Установить направление размещения в Qt::RightToLeft.

--graphicssystem=имя

Установить механизм рендеринга для экранных виджетов и QPixmaps (raster, opengl).

--display=имя

Установить X экран в имя (типично в $DISPLAY).

--geometry=геометрия

Установить клиентскую геометрию первого отображаемого окна.

## ФАЙЛЫ
/etc/oscada.xml

Типичный конфигурационный файл OpenSCADA

/usr/share/openscada/

Глобальная директория файлов данных OpenSCADA

## СМОТРИТЕ ТАКЖЕ
openscada_start(1),

http://oscada.org

Главный сайт проекта OpenSCADA

http://wiki.oscada.org

WIKI-ресурс с источником всей документации Полная документация пользователя доступна через модуль графической конфигурации вроде QTCfg.

## АВТОРЫ

```
Роман Савоченко <roman@oscada.org>
```


title: openscada_start(1)

text:
# openscada_start(1)

## НАЗВАНИЕ
openscada_start - Ориентированный на проекты скрипт запуска OpenSCADA

## СИНТАКСИС
openscada_start [параметры]

## ОПИСАНИЕ
Система OpenSCADA это открытая реализация SCADA (Supervisory Control And Data Acquisition) и HMI (Human-Machine Interface) системы. Основными свойствами системы являются: открытость(GPL), многоплатформенность, модульность и масштабируемость.

Сердцем системы является модульное ядро. В зависимости от того какие модули подключены, система может выполнять как функции различных серверов, так и функции клиентов клиент-серверной архитектуры. Собственно, архитектура системы позволяет реализовывать распределённые клиент-серверные системы любой сложности и сочетания. Для достижения высокого быстродействия, за счёт сокращения времени коммуникаций, архитектура позволяет объединять функции распределённых систем в одной программе.

Скрипт openscada_start это ориентированная на проекты обёртка к главной пускающей программе openscada который позволяет создавать новые проекты и независимо их запускать. Также этот скрипт осуществляет слежение, обработку и генерацию отчётов про падения, при наличии gdb.

Проект OpenSCADA это директория с названием, соответствующим имени проекта, которую размещено в директории данных OpenSCADA /usr/share/openscada/, в случае пред-установленных проектов, и ~/.openscada/ для пользовательских проектов.

ИмяПроекта может быть передано в окружении "OSCADA_ProjName=ИмяПроекта" или через название символической ссылки "openscada_ИмяПроекта" на этот скрипт.

Вызов этого скрипта без указания ИмяПроекта создаст диалог для выбора создания нового проекта или исполнения пред-установленных и пользовательских проектов. Выполнение пред-установленного проекта из окружения пользователя приведёт к копированию конфигурационного файла /etc/oscada_ИмяПроекта.xml и каталога проекта в пользовательскую директорию ~/.openscada/, с целью предоставления пользователю доступа на модификацию этого проекта.

Для формирования диалогов выбора и имени нового проекта используются диалоговые программы, в приведенном приоритете проверки: dialog (в случае наличия активного терминала), kdialog, zenity та Xdialog.

Для доступа к новому проекту (типовая конфигурация) используется учётная запись "root" и пароль "openscada" или запись "user" и пароль "user".

Скрипт пропускает все параметры к openscada однако некоторые из них используются в формировании окружения проекта!

## ПАРАМЕТРЫ

### Основные опции:
-h, --help

Информация по опциям системы OpenSCADA.

--config=файл

Конфигурационный файл станции.

--station=идентификатор

Идентификатор станции.

--statName=имя

Имя станции.

--demon, --daemon

Запуск в режиме демона.

--pidFile=файл

Файл для помещения ID процесса программы сюда.

--coreDumpAllow

Установить ограничения для разрешения генерации дампа памяти при крушении программы.

--modPath=путь

Путь к модулям (/var/os/modules/).

--messLev=уровень

Обрабатываемый уровень сообщений (0-7).

--log=направление

Направление сообщений в, по битовому полю:

0x1 - системный логер (syslogd);

0x2 - стандартный выход (stdout);

0x4 - стандартный выход ошибок (stderr);

0x8 - архив сообщений.

### Параметры модуля <Archive:FSArch>:
--noArchLimit

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

### Параметры модуля <UI:QTStarter>:
--sync

Переключение в синхронный режим X11 для отладки.

--widgetcount

Печать отладочных сообщений при выходе, о количеcтве виджетов оставшихся неудалёнными и максимальном их количестве.

--qws

Делает данное приложение сервером с Qt для встраиваемого Linux.

--style=имя

Установить GUI стиль в имя (windows, platinum, plastique, ...).

--stylesheet=путь

Установить таблицу стилей из файла по пути.

--session=имя

Восстановить из предыдущего сеанса с указанным именем.

--reverse

Установить направление размещения в Qt::RightToLeft.

--graphicssystem=имя

Установить механизм рендеринга для экранных виджетов и QPixmaps (raster, opengl).

--display=имя

Установить X экран в имя (типично в $DISPLAY).

--geometry=геометрия

Установить клиентскую геометрию первого отображаемого окна.

## ОКРУЖЕНИЕ
OSCADA_ProjName

Устанавливать окружение OSCADA_ProjName в название проекта для запуска.

## ФАЙЛЫ
/etc/oscada.xml

Типичный конфигурационный файл OpenSCADA

/usr/share/openscada/

Глобальная директория файлов данных и пред-установленных проектов OpenSCADA

~/.openscada/

Директория пользовательских проектов OpenSCADA

/etc/oscada_ИмяПроекта.xml

Конфигурационный файл пред-установленного проекта ИмяПроекта

ИмяПроекта/oscada.xml

Конфигурационный файл проекта ИмяПроекта

ИмяПроекта/*.db

Локальные файлы БД SQLite проекта ИмяПроекта

ИмяПроекта/*.crash

Отчёты падений проекта ИмяПроекта

ИмяПроекта/icons/*

Специфические медиа файлы проекта ИмяПроекта

ИмяПроекта/docs/*

Специфические файлы документации проекта ИмяПроекта

## СМОТРИТЕ ТАКЖЕ
openscada(1), dialog(1), kdialog(1), zenity(1)

http://oscada.org

Главный сайт проекта OpenSCADA

http://wiki.oscada.org

WIKI-ресурс с источником всей документации Полная документация пользователя доступна через модуль графической конфигурации вроде QTCfg.

## АВТОРЫ

```
Роман Савоченко <roman@oscada.org>
```


outwiker

package: outwiker

title: outwiker(1)

text:
# outwiker(1)

## ИМЯ
OutWiker - бесплатная кроссплатформенная программа для хранения заметок в виде дерева.

## КОМАНДНАЯ СТРОКА
outwiker [-h] [-v] [-r] [--normal] [--debug] [ path ]

## ОПИСАНИЕ
OutWiker - это бесплатная кроссплатформенная программа для хранения заметок в виде дерева. Такие программы называют outliner'ами, персональными вики-системами или древовидными редакторами. Основное отличие OutWiker от других подобных программ заключается в том, что OutWiker хранит дерево заметок в виде обычных директорий на диске, а не в одном файле. Также к заметкам может быть прикреплено любое количество файлов.

OutWiker может содержать страницы разного типа, в данный момент поддерживаются четыре типа страниц: страница с поддержкой вики-нотации, обычный текст, HTML-страницы и страница поиска по дереву.

Страница программы в интернете находится по адресу: http://jenyay.net/Soft/Outwiker

## ПАРАМЕТРЫ
path

Путь до папки с деревом заметок (или до файла __page.opt). Если path не указан, программа ведет себя согласно настройкам и открывает пустое окно или последнее открытое дерево с заметками.

-h, --help

Показать справку по параметрам командной строки.

-v, --version

Показать версию outwiker.

-r, --readonly

Открыть дерево заметок в режиме "только для чтения".

--normal

Не минимизировать окно программы при запуске.

--debug

Запустить OutWiker в отлидочном режиме.

## АВТОР
Евгений Ильин (aka Jenyay). <jenyay.ilin@gmail.com>

## ЛИЦЕНЗИЯ
GNU GPL 3

## БЛАГОДАРНОСТИ
Программа использует бесплатные иконки, взятые с сайтов http://famfamfam.com , http://yusukekamiyamane.com и http://fatcow.com , за что спасибо авторам этих сайтов.

### Отдельные благодарности
Набродову Алексею ( http://averr.in/ ) за иконку для программы.

Горбунову Анатонию за новую иконку для программы.

Чешкову Илье ( http://ilyuxaif.livejournal.com ) за исправление английского перевода справки.

Юрию aka Cuprum ( http://cuprum.name/ ) за иконки браузеров и операционных систем для набора иконок, а также за стиль "dark".

linda_kaioh ( http://linda-kaioh.livejournal.com/ )за тестирование программы и за стиль "green".

Виталию Яковчуку, Дмитрию Васильченко и Вадиму Деркачу за украинскую локализацию программы.

Åke Engelbrektson за шведскую локализацию программы.

Matteo Migliaccio ( https://plus.google.com/+MatteoMigliaccio/posts ) за итальянскую локализацию программы.

Пользователю tehTen с Jabber'ом <1010@xmpp.ru> за стиль "greyness".

Пользователю Alex (профиль на форуме) за стиль "AVC".

Пользователю Gabrielle Ramires ( <gabrielleramires.iv@gmail.com> ) за стиль "Gabrielle".

Пользователю Unreal666 за обнаружение ошибок.


title: pdf2djvu(1)

summary: создаёт DjVu\-файлы из PDF\-файлов

text:
# pdf2djvu(1)

## НАЗВАНИЕ
pdf2djvu - создаёт DjVu-файлы из PDF-файлов

## СИНТАКСИС
pdf2djvu [{-o | --output} результирующий-djvu-файл] [параметр...] pdf-файл...

pdf2djvu {-i | --indirect} файл-индекса-djvu [параметр...] pdf-файл...

pdf2djvu {--version | --help | -h}

## ОПИСАНИЕ
Программа создаёт DjVu-файл из одного или нескольких Portable Document Format файлов.

## ПАРАМЕТРЫ
pdf2djvu допускает следующие параметры:

### Тип документа, имена файлов
-o, --output=результирующий-djvu-файл

Создать объединённый многостраничный документ. Записать файл в результирующий-djvu-файл вместо стандартного вывода.

-i, --indirect=файл-индекса-djvu

Создать раздельный многостраничный документ. Использовать файл-индекса-djvu как имя файла индекса; поместить файлы-компоненты в один и тот же каталог. Каталог должен существовать и иметь разрешение на запись.

--page-id-template=шаблон

Устанавливает схему именования идентификаторов страниц. Обратитесь за справкой к «ЯЗЫК ШАБЛОНОВ» секции описания языка шаблонов. Шаблон по умолчанию «p{page:04*}.djvu».

По причине портабельности идентификатор страницы:

•должен состоять только из строчных ASCII букв, цифр, _, +, - и точки,

•не может начинаться с +, - или точки,

•не может включать две последовательные точки,

•должен заканчиваться расширением .djvu или .djv.

--page-id-prefix=префикс

Эквивалентно «--page-id-template=префикс{page:04*}.djvu».

--page-title-template=шаблон

Устанавливает шаблон заголовков страниц. Обратитесь за справкой к секции описания языка шаблонов «ЯЗЫК ШАБЛОНОВ». Шаблон по умолчанию «{label}».

--no-page-titles

Не устанавливать заголовки страницы.

### Разрешение, размер страницы
-d, --dpi=разрешение

Устанавливает желаемое разрешение разрешение точек на дюйм. По умолчанию 300 dpi. Разрешённый диапазон: 72 ≤ разрешение ≤ 6000.

--media-box

Использовать MediaBox для определения размера страницы. По умолчанию используется CropBox.

--page-size=ширинаxвысота

Устанавливает предпочитаемый размер страницы в ширина пикселов × высота пикселов. Действительный размер страницы может изменяться для соблюдения соотношения и из-за ограничений DjVu. (Этот параметр имеет приоритет над -d/--dpi.)

--guess-dpi

Попробовать предположить оригинальное разрешение проверяя внедрённые изображения. Используйте с осторожностью.

### Качество изображения
--bg-slices=n+...+n, --bg-slices=n,...,n

Устанавливает качество кодирования фонового слоя IW44. Этот параметр похож на параметр -slice для c44. Обратитесь за справкой к man-странице c44(1). По умолчанию 72+11+10+10.

--bg-subsample=n

Устанавливает отношение подвыборки фона. По умолчанию 3. Допустимые значения находятся между 1 и 12 включительно.

--fg-colors=default

Попробовать сохранить все цвета переднего плана. Используется по умолчанию.

--fg-colors=web

Уменьшить количество цветов переднего плана до web-палитры (216 цветов). Не рекомендуется использовать.

--fg-colors=n

Использует GraphicsMagick для уменьшения количества явных цветов в слое переднего плана. Допустимые значения от 1 до 4080. Не рекомендуется использовать.

--fg-colors=black

Не использовать любую информацию о цветах из слоя переднего плана.

--monochrome

Рендерить страницы как монохромные изображения. С этим параметром опции --bg-... и --fg-... не принимаются во внимание.

--loss-level=n

Устанавливает агрессивность компрессии с потерями. По умолчанию 0 (без потерь). Допустимые значения от 0 до 200 включительно. Этот параметр похож на параметр -losslevel для cjb2. Обратитесь за справкой к man-странице cjb2(1). Этот параметр принимается во внимание только вместе с параметром --monochrome.

--lossy

Равносильно --loss-level=100.

--anti-alias

Разрешить сглаживание шрифтов и векторной графики. Не рекомендуется использовать.

### Извлечение
--no-metadata

Не извлекать метаданные. По умолчанию:

•Извлекаются следующие значения информации документа: Title, Author, Subject, Creator, Producer, CreationDate, ModDate. Временные отметки форматируются согласно стандарту RFC 3999[1]. Дата и время разделены одиночным пробелом.

•Соответственно извлекаются (или создаются) и обновляются метаданные XMP.

Примечание

В случае нескольких входных документов используются только метаданные из первого.

--verbatim-metadata

Сохранять метаданные нетронутыми.

--no-outline

Не извлекать оглавление документа.

--hyperlinks=border-avis

Делать границы ссылок всегда видимыми. По умолчанию границы ссылок становятся видимыми только при наведении на ссылку мыши.

--hyperlinks=#RRGGBB

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

--no-hyperlinks, --hyperlinks=none

Не извлекать ссылки.

--no-text

Не извлекать текст.

--words

Извлечь текст. Записать расположение каждого слова. Используется по умолчанию.

--lines

Извлечь текст. Записать расположение каждой строки, а не слова.

--crop-text

Не извлекать текст, который находится за пределами страницы.

--no-nfkc

Не применять NFKC[2] нормализацию к тексту за исключением символов из Alphabetic Presentation Forms block[3] (U+FB00–U+FB4F), которые нормализованы безоговорочно. По умолчанию применяется NFKC нормализация для всех символов.

--filter-text=командная строка

Фильтровать текст через командная строка. Данный фильтр должен сохранить пробелы, управляющие символы и десятичные цифры. Этот параметр подразумевает --no-nfkc.

-p, --pages=диапазон-страниц

Устанавливает страницы для конвертирования. диапазон-страниц — это разделяемый запятыми список поддиапазонов. Каждый поддиапазон является одиночной страницей (например, 17) или последовательным диапазоном страниц (например, 37-42). Повторяющиеся номера страниц не допускаются. Страницы нумеруются с 1. По умолчанию конвертируются все страницы.

### Производительность
-j, --jobs=n

Использовать n потоков для конвертации. По умолчанию используется один поток.

-j0, --jobs=0

Определить автоматически, сколько потоков использовать для конвертации.

### Подробности, справка
-v, --verbose

Показывать больше информационных сообщений при конвертации файла.

-q, --quiet

Не показывать информационные сообщения при конвертации файла.

--version

Вывести информацию о версии и выйти.

-h, --help

Показать справку и выйти.

## ОКРУЖЕНИЕ
Следующие переменные окружения оказывают влияние на pdf2djvu в Unix-системах:

OMP_*

Поведением, с точки зрения распараллеливания, можно управлять с помощью нескольких переменных окружения. За деталями обратитесь к спецификации OpenMP API[4].

TMPDIR

pdf2djvu интенсивно использует временные файлы. Программа сохраняет их в каталоге заданном этой переменной. По умолчанию /tmp.

## ЯЗЫК ШАБЛОНОВ

### Синтаксис шаблонов
Язык шаблонов использует как образец синтаксис форматирования строк в Python[5].

Шаблон — это текст, который содержит поля, окружённые фигурными скобками {}. Когда шаблон применяется, поля заменяются соответствующим образом отформатированными значениями. Кроме того, {{ и }} заменяются одиночными { и } соответственно.

### Синтаксис полей
Каждое поле состоит из имени переменной, за которым может следовать сдвиг (не обязательно) и спецификация формата (не обязательно).

Сдвиг — целое число со знаком (т. е. начинающееся на + or -).

Формат спецификации включает двоеточие, а затем спецификатор ширины поля.

Спецификатор ширины поля — это целое десятичное число определяющее минимальную ширину поля. Если не указано, тогда ширина поля вычисляется по содержимому. Предшествующий спецификатору знак нуля (0) делает возможным заполнение нулями.

После спецификатора ширины поля может располагаться знак звёздочки (*), что увеличивает минимальную ширину поля до максимально возможной длины переменной.

### Доступные переменные
dpage

Количество страниц в документе DjVu.

page, spage

Количество страниц в документе PDF.

label

Метка страницы (логический номер страницы) в документе PDF. Эта переменная доступна только для заголовков страницы.

## ДЕТАЛИ РЕАЛИЗАЦИИ

### Алгоритм разделения слоёв
Если не используется параметр --monochrome, pdf2djvu использует следующий простой алгоритм:

1.Для каждой страницы сделать следующее:

1.Преобразовать страницу в растровое изображение обычным порядком.

2.Преобразовать страницу в другое растровое изображение пропуская следующие элементы страницы:

•текст,

•растровые изображения с глубиной 1 бит на пиксел,

•векторные элементы (за исключением больших заполненных площадей).

3.Сравнить оба изображения, пиксел за пикселом:

1.Если их цвета совпадают, классифицировать пиксел как часть фонового слоя.

2.В противоположном случае классифицировать пиксел как часть слоя переднего плана.

## СООБЩЕНИЯ ОБ ОШИБКАХ
Если вы нашли ошибку в pdf2djvu, сообщите о ней в баг-трекер[6] или в список рассылки[7].

## СМОТРИТЕ ТАКЖЕ
djvu(1), djvudigital(1), csepdjvu(1)

## ПРИМЕЧАНИЯ
1.

RFC 3999

https://www.ietf.org/rfc/rfc3339

2.

NFKC

https://unicode.org/reports/tr15/

3.

Alphabetic Presentation Forms block

https://unicode.org/charts/PDF/UFB00.pdf

4.

спецификации OpenMP API

https://www.openmp.org/specifications/

5.

синтаксис форматирования строк в Python

https://docs.python.org/2/library/string.html#format-string-syntax

6.

баг-трекер

https://github.com/jwilk/pdf2djvu/issues

7.

список рассылки

https://groups.io/g/pdf2djvu


podsec-create-imagemakeruser

package: podsec

title: podsec-create-imagemakeruser(1)

text:
# podsec-create-imagemakeruser(1)

## NAME
podsec-create-imagemakeruser - создание пользователей разработчиков образов контейнеров

## SYNOPSIS
podsec-create-imagemakeruser [имя_пользователя[@тропа_репозитория]] ...

## DESCRIPTION
Cкрипт создает пользователей разработчиков образов контейнеров, обладающими правами: - менять установленный администратором безопасности средства контейнеризации пароль; - создавать, модифицировать и удалять образы контейнеров.

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

○

пароль пользователя;

○

тип ключа: RSA, DSA и Elgamal, DSA (только для подписи), RSA (только для подписи), имеющийся на карте ключ;

○

срок действия ключа;

○

полное имя;

○

Email (используется в дальнейшем для подписи образов);

○

примечание;

○

пароль для подписи образов.

Скрипт должен вызываться после вызова скрипта podsec-create-policy

## OPTIONS
Список пользователей и тропы регистратороы для которых они подписывают образы передаются параметрами в формате: имя_пользователя@тропа_репозитория

○

В списке не должно быть пользователей с одинаковыми тропами.

○

Если пользователь единственный и тропа не указана, то принимается тропа registry.local

○

Если имя пользователя не указано первым параметром принимается имя imagemaker@registry.local.

## EXAMPLES
podsec-create-imagemakeruser immkk8s@registry.local/k8s-c10f1 imklocal@registry.local immkalt@registry.altlinux.org

Создаются три пользователя с правами на подпись:

○

immkk8s - локальных образов kubernetes с тропой registry.local/k8s-c10f1;

○

imklocal - локальных образов registry.local за исключением образов kubernetes

○

immkalt - образов регистратора registry.altlinux.org

## SECURITY CONSIDERATIONS
○

Данный скрипт должен запускаться только на узле с доменами registry.local, sigstore-local. Если это не так, скрипт прекращает свою работу.

○

Пользователи разработчики образов должны сами контролировать список подписываемых образов. Если пользователь imklocal подпишет образ с тропой registry.local/k8s-c10f1, то разворачивание данного образа будет неуспешным, так как при проверке подписи будет использоваться открытый ключ пользователя immkk8s, а не imklocal.

○

Все создаваемые в кластере пользователи должны располагаться на одном сервере с доменом storage.local. Там же должен быть развернут WEB-сервер подписей образов.

○

Все открытые ключи пользователей располагаются в каталоге /var/sigstore/keys/ и должны быть скопированы на каждый сервер кластера к каталог /var/sigstore/keys/

○

Подписи образов хранятся в каталоге /var/sigstore/sigstore/ с отброшенными именами регистраторов. Таким образом, если в системе контролируются подписи образов с разных регистраторов (например: registry.altlinux.org и registry.local) и образ registry.local/k8s-c10f1/pause:3.9 c @sha256\=347a15493d0a38d9ce74f23ea9f081583728a20dbdc11d7c17ef286d9cade3ec подписан, то будут считаться подписанными все образы с данным sha256: registry.altlinux.orh/k8s-c10f1/pause:3.9, ...

## SEE ALSO
○

Разработчик образов контейнеров (imagemaker) https://github.com/alt-cloud/podsec/tree/master/SigningImages.

○

Описание периодического контроля целостности образов контейнеров и параметров настройки средства контейнеризации https://github.com/alt-cloud/podsec/tree/master/ImageSignatureVerification

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-create-podmanusers

title: podsec-create-podmanusers(1)

text:
# podsec-create-podmanusers(1)

## NAME
podsec-create-podmanusers - создание пользователей, запускающих контейнеры подписанных образов

## SYNOPSIS
podsec-create-podmanusers имя_пользователя ...

## DESCRIPTION
Cкрипт создает пользователей образов контейнеров, обладающих правами на запуск подписанных образов в rootless режиме.

## OPTIONS
○

Скрипту параметрами передается список создаваемых пользователей.

○

Пользователям присваивается группа podman. В качестве политик доступа к образам пользователи используют системные файлы /etc/containers/policy.json, /etc/containers/registries.d/default.yaml.

○

Сформированные скриптом локальные файлы конфигурации пользователей в каталоге ~/.config/containers/ закрываются на изменения.

## EXAMPLES
podsec-create-podmanusers user1 user2 user3

## SECURITY CONSIDERATIONS
○

Для каждого пользователя создается свой namespace.

○

Все используемые образы скачиваются только с указанных в файле политик /etc/containers/policy.json регистраторов и помещаются в локальный кэш пользователя;

○

Контейнеры запускаются в собственном namespace, хранятся в локальном кэше и недоступны другим пользователям

○

Для проверки подписи образов используется системый файл /etc/containers/registries.d/defaylt.yaml. Все подписи хранятся в локальном для создаваемого кластера WEB-сервере по адресу: ` http://sigstore.local:81/sigstore/`

## SEE ALSO
○

Описание периодического контроля целостности образов контейнеров и параметров настройки средства контейнеризации https://github.com/alt-cloud/podsec/tree/master/ImageSignatureVerification

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-create-policy

title: podsec-create-policy(1)

text:
# podsec-create-policy(1)

## NAME
podsec-create-policy - создание системных политик и файлов конфигурации

## SYNOPSIS
podsec-create-policy ip-адрес_регистратора_и_сервера_подписей

## DESCRIPTION
Cкрипт создает файлы политик и настраивает системные сервисы для работы podman как в rootfull, так и в rootless режиме:

○

Добавляет в файл /etc/hosts привязку доменов registry.local, sigstore.local к указанному ip-адресу_регистратора_и_сервера_подписей;

○

Создает с сохранением предыдущих файл политик /etc/containers/policy.json;

○

Создает с сохранением предыдущих файл /etc/containers/registries.d/default.yaml описания доступа к открытым ключам подписантов;

○

Создает группу podman;

○

Если ip-адрес_регистратора_и_сервера_подписей совпадает с локальным IP-адресом, создает группу podmen_dev и инициализирует каталог /var/sigstore/ и подкаталоги хранения открытых ключей и подписей образов;

○

Добавлеяет insecure-доступ к регистратору registry.local в файл /etc/containers/registries.conf;

○

Настраивает использование образа registry.local/k8s-c10f1/pause:3.9 при запуска pod´ов в podman (podman pod init);

## SECURITY CONSIDERATIONS
○

IP-адрес регистратора и сервера подписей не должен быть локальным 127.0.0.1

○

Если привязка доменов registry.local, sigstore.local в файле /etc/hosts уже существует скрипт прекращает свою работу с кодом завершения 1. Необходимо удалить строку привязки и перезапустить скрипт.

○

Если скрипт запускается на узле кластера отличным от sigstore.local, то после работы скрипта необходимо скопировать с узла sigstore.local файл политик /etc/containets/policy.json в соответствующий каталог /etc/containets/. Данную операцию необходимо производить при каждом добавлении пользователя подписывающего образы на sigstore.local.

## SEE ALSO
○

Описание периодического контроля целостности образов контейнеров и параметров настройки средства контейнеризации https://github.com/alt-cloud/podsec/tree/master/ImageSignatureVerification

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-create-services

title: podsec-create-services(1)

text:
# podsec-create-services(1)

## NAME
podsec-create-services - создание сервисов для поддержки регистратора докер образов и сервера подписей образов

## SYNOPSIS
podsec-create-services

## DESCRIPTION
Скрипт поднимает сервисы docker-registry и nginx для поддержки регистратора докер образов и сервера подписей образов.

○

регистратор образов принимает запросы по адресу http://registry.local и хранит образы в каталоге /var/lib/containers/storage/volumes/registry/_data/;

○

сервис подписей образов принимает запросы по адресу http://sigstore.local:81, хранит подписи образов в каталоге /var/sigstore/sigstore/, открытые ключи в каталоге /var/sigstore/keys/

## SECURITY CONSIDERATIONS
Данный скрипт должен запускаться только на узле с доменами registry.local, sigstore-local, где располагаются пользователи создающие и подписывающие образы. Если это не так, скрипт прекращает свою работу не запуская сервисы.

## SEE ALSO
○

Описание периодического контроля целостности образов контейнеров и параметров настройки средства контейнеризации https://github.com/alt-cloud/podsec/tree/master/ImageSignatureVerification

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-load-sign-oci

title: podsec-load-sign-oci(1)

summary: разворачивание образов из сжатого xz\-oci\-архива, их подпись и помещение на регистратор

text:
# podsec-load-sign-oci(1)

## NAME
podsec-load-sign-oci - разворачивание образов из сжатого xz-oci-архива, их подпись и помещение на регистратор

## SYNOPSIS
podsec-load-sign-oci имя_архивного_файла архитектура EMail_подписанта [регистратор/тропа]

## DESCRIPTION
Скрипт:

○

извлекает из сжатого xz-oci-архива образы,

○

разворачивает их в файловой системе,

○

подписывает и помещает на регистратор по указаной тропе.

## OPTIONS
1.

Архив oci-файла, передаваемый первым параметром должен быть сжат компрессором xz.

2.

Имя архитектуры должно принадлежать списку amd64, arm64, arm, ppc64le, 386.

3.

EMail_подписанта должно быть указано в подписи пользователя и указывается без обрамляющих скобок <>.

4.

регистратор/тропа должна содержать имя подкаталога регистратора. Формат регистратор недопустим Если регистратор/тропа не указана, принимается тропа registry.local/k8s-c10f1

## EXAMPLES
podsec-load-sign-oci /mnt/cdrom/containers/amd64.tar.xz amd64 immklocal@baseat.ru registry.local

podsec-load-sign-oci /mnt/cdrom/containers/amd64.tar.xz amd64 immkk8s@baseat.ru

## SECURITY CONSIDERATIONS
○

Данный скрипт должен запускаться только на узле с доменами registry.local, sigstore-local. Если это не так, скрипт прекращает свою работу.

○

Скрипт должен вызываться пользователем входящим в группу podman_dev.

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


package: podsec-dev

title: podsec-k8s-save-oci(1)

summary: архивация образов kubernetes версии 1\.26\.3 различных архитектур в указанный первым параметром каталог c последующим сжатием и формированием xz\-oci\-архива

text:
# podsec-k8s-save-oci(1)

## NAME
podsec-k8s-save-oci - архивация образов kubernetes версии 1.26.3 различных архитектур в указанный первым параметром каталог c последующим сжатием и формированием xz-oci-архива

## SYNOPSIS
podsec-save-oci каталог_архивирования_образов архитектура,архитектура,...|all образ ...

## DESCRIPTION
○

Скрипт производит архивацию образов в указанный первым параметром каталог

○

Второй параметры задает через запятую архивируемые архитектуры. Если второй параметр имеет значение all архивируются все архитектуры: amd64, arm64, arm ppc64le, 386.

○

Скрипт производит загрузку образов k8s-c10f1/coredns:v1.9.3, k8s-c10f1/kube-controller-manager:v1.26.3, k8s-c10f1/kube-apiserver:v1.26.3, k8s-c10f1/kube-proxy:v1.26.3, k8s-c10f1/etcd:3.5.6-0, k8s-c10f1/flannel:v0.19.2, k8s-c10f1/kube-scheduler:v1.26.3, k8s-c10f1/pause:3.9, k8s-c10f1/flannel-cni-plugin:v1.2.0, k8s-c10f1/cert-manager-controller:v1.9.1, k8s-c10f1/cert-manager-cainjector:v1.9.1, k8s-c10f1/cert-manager-webhook:v1.9.1 с регистратора registry.altlinux.org в containers-storage: системы с последующим помещением их в указанный первым параметром каталог в подкаталог с именем архитектуры $ociDir/$arch. Для улучшения последующей компресии слои образа помещаются несжатыми (параметр --dest-oci-accept-uncompressed-layers)

○

После окончания наполнения подкаталога архитектуры он архивируется, сжимается и помещается в файл $ociDir/$arch.tar.xz

## EXAMPLES
podsec-k8s-save-oci /tmp/ociDir/ amd64,arm64

## SECURITY CONSIDERATIONS
○

Так как скрипт производит загрузку образов различных архитектур последняя загруженная в containers-storage: архитектура может отличаться от текущей архитектуры процессора. При необходимости нужно будет произвести перезагрузку образов для рабочей архитектуры процессора

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-save-oci

title: podsec-save-oci(1)

summary: архивация образов различных архитектур в указанный первым параметром каталог c последующим сжатием и формированием xz\-oci\-архива

text:
# podsec-save-oci(1)

## NAME
podsec-save-oci - архивация образов различных архитектур в указанный первым параметром каталог c последующим сжатием и формированием xz-oci-архива

## SYNOPSIS
podsec-save-oci каталог_архивирования_образов архитектура,архитектура,...|all образ ...

## OPTIONS
○

Скрипт производит архивацию образов в указанный первым параметром каталог

○

Второй параметры задает через запятую архивируемые архитектуры. Если второй параметр имеет значение all архивируются все архитектуры: amd64, arm64, arm ppc64le, 386.

○

Скрипт производит загрузку образов, указанных 3-м и последующими параметрами с регистратора registry.altlinux.org в containers-storage: системы с последующим помещением их в указанный первым параметром каталог в подкаталог с именем архитектуры $ociDir/$arch. Для улучшения последующей компресии слои образа помещаются несжатыми (параметр --dest-oci-accept-uncompressed-layers)

○

После окончания наполнения подкаталога архитектуры он архивируется, сжимается и помещается в файл $ociDir/$arch.tar.xz

## EXAMPLES
podsec-save-oci /tmp/ociDir/ amd64,arm64 k8s-c10f1/flannel:v0.19.2 k8s-c10f1/flannel-cni-plugin:v1.2.0

## SECURITY CONSIDERATIONS
○

Так как скрипт производит загрузку образов различных архитектур последняя загруженная в containers-storage: архитектура может отличаться от текущей архитектуры процессора. При необходимости нужно будет произвести перезагрузку образов для рабочей архитектуры процессора

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-inotify-build-invulnerable-image

package: podsec-inotify

summary: скрипт создания docker\-образов и проверки их сканером безопасности trivy

text:
# podsec-inotify-build-invulnerable-image(1)

## NAME
podsec-inotify-build-invulnerable-image - скрипт создания docker-образов и проверки их сканером безопасности trivy

## SYNOPSIS
podsec-inotify-build-invulnerable-image <имя_образа> [ <docker_файл> [ <каталог_контекста> [ <параметры_podman_build>

## DESCRIPTION
Для корректной работы скрипта необходимо запустить сервис trivy: systemctl enable --now trivy

Скрипт производит создание docker-образа имя_образа, описанного в docker_файл (по умолчанию Dockerfile) в каталоге каталог_контекста (по умолчанию текущий) с параметрами сборки параметры_podman_build.

После создание образа он проверяется на наличие уязвимостей сервисом trivy.

## EXAMPLES
podsec-inotify-build-invulnerable-image my-first-image

## SEE ALSO
The all-in-one open source security scanner https://trivy.dev/

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-inotify-check-containers

title: podsec-inotify-check-containers(1)

text:
# podsec-inotify-check-containers(1)

## NAME
podsec-inotify-check-containers - проверка наличия изменений критических файлов rootfull и rootless контейнеров

## SYNOPSIS
podsec-inotify-check-containers

## DESCRIPTION
Скрипт:

○

создаёт список директорий rootless и rootfull контейнеров, существующих в системе,

○

запускает проверку на добавление,удаление, и изменение файлов в директориях контейнеров,

○

отсылает уведомление об изменении в системный лог.

Скрипт запускает два процесса мониторинга каталогов:

○

мониторинг добавления пользователей в каталоге /home/, добавления контейнеров в каталогах */storage/overlay/ rootless и rootfull пользователей (список формируется в файле /tmp/inotifyMonitor.tmp);

○

мониторинг изменения файлов в контейнерах rootless и rootfull пользователей (список формируется в файле /tmp/inotifyOverlays.tmp).

Первый процесс при изменении отслеживаемых каталогов формирует списки в файлах мониторинга /tmp/inotifyMonitor.tmp, /tmp/inotifyOverlays.tmp, перезапускает себя и второй процесс мониторинга изменения файлов в контейнерах.

Второй процесс изменения файлов в контейнерах монитрит все файлы и каталоги за исключением файлов и каталогов в корневых каталогах /var/, /proc/, /tmp/, /run/, которые могут инфенсивно изменяться при работе контейнеров сервисами контейнеров.

Изменения в каталогах /home/, /root/, /etc/ логируются в системный лог как предупреждения (уровень Warning). Изменения в остальных каталогах логируются в системный лог как критические (уровень Critical).

Сообщения в системный лог имеют формат: An event <event> occurred in the container <container> [in home directory|in configuration directory] on the file <file>

## SECURITY CONSIDERATIONS
○

Данный скрипт запускается сервисом podsec-inotify-check-containers.service.

## EXAMPLES
Если в системе развернуты контейнеры, и требуется следить за модификацией файлов внутри этих контейнеров, запустите сервис podsec-inotify-check-containers.service: # systemctl enable --now podsec-inotify-check-containers.service

## AUTHOR
Burykin Nikolay, ALT Linux Team, bne@altlinux.org Kostarev Alexey, ALT Linux Team, kaf@basealt.ru


podsec-inotify-check-images

title: podsec-inotify-check-images(1)

text:
# podsec-inotify-check-images(1)

## NAME
podsec-inotify-check-images - Плугин проверяет образы на предмет их соответствия настройки политикам контейнеризации на узле

\## SYNOPSIS

podsec-inotify-check-images [-v[vv]] [-a интервал] [-f интервал] -c интервал -h интервал [-m интервал] х-w интервалъ [-l интервал] [-d интервал] [-M EMail]

## DESCRIPTION
Плугин проверяет образы на предмет их соответствия настройки политикам контейнеризации на узле. Проверка идет по следующим параметрам:

Параметр контроля пользователей

Вес метрики

наличие в политике пользователя регистраторов не поддерживающие электронную подпись

101

наличие в кэше образов неподписанных образов

102

наличие в кэше образов вне поддерживаемых политик

103

Все веса метрик суммируются и формируется итоговая метрика.

## OPTIONS
При указании флага -M Email итоговое сообщение отсылается указанному пользователю.

Уровень опасности определяется при запуске флагами:

для системных логов:

```
    Имя уровня  | Уровень | Префикс    | Флаг | Рекомендуемое значение интервала

    ------------|---------|------------|------|------------------------

    аварийный   |    7    | Crash      | `-a` | не указывать

    фатальный   |    6    | Fatal      | `-f` | не указывать

    критический |    5    | Critical   | `-c` | 100

    высокий     |    4    | Heigh      | `-h` | 0

    средний     |    3    | Middle     | `-m` | не указывать

    низкий      |    2    | Low        | `-l` | не указывать

    отладочный  |    1    | Debug      | `-d` | не указывать
```

для сервера icigna:

```
    Имя уровня     | Уровень | Префикс    | Флаг | Рекомендуемое значение интервала

    ---------------|---------|------------|------|-----------------------

    критический    |    2    | Critical   | `-c` | 100

    предупреждение |    1    | Warning    | `-w` | 0
```

Любой параметр может отсутствовать. В этом случае он не рассматривается при просмотре соответствия полученной метрики интервалам.

Значение параметров имеют формат интервала, описанного в документации по nagios: Threshold and Ranges https://nagios-plugins.org/doc/guidelines.html#THRESHOLDFORMAT.

Общее описание:

[@]start:end

Замечания:

○

start ≤ end

○

start и : не требуется если start=0

○

если интервал задан в формате start: и конец не задан, то концом интервала считается бесконечность ꝏ

○

для указания отрицательной бесконечности (-ꝏ) используйте ~

○

триггер срабатывает когда значение метрики ВНЕ УКАЗАННОГО ИНТЕРВАЛА (начальные и конечные точки включаются в интервал)

○

если интервал начинается с символа @, тогда условие инвертируется - триггер срабатывает при значении метрики В УКАЗАННОМ ИНТЕРВАЛЕ (начальные и конечные точки включаются в интервал)

Примеры возможных форматов:

```
Формат интервала | Описание условия срабатывания триггера
-----------------|--------------------------------------
100              | metrica < 0 || metrica > 100 (вне интервала 0-100)
100:             | metrica < 100 (вне интервала 100-ꝏ)
~:100            | metrica > 100 (вне интервала -ꝏ-100)
20-100           | metrica < 20 || metrica > 100 (вне интервала 20-100)
@20-100          | metrica >= 20 && metrica <= 100 (в интервале 20-100)
```

### Системные логи
Для системных логов уровень опасности определяется для каждого сообщения. Интервалы уровней опасностей, заданные параметрами просматриваются в порядке от большого к меньшему. Уровень сообщения определяется по первому найденному соответствию (не забываете, что триггер срабатывает при нахождении метрики ВНЕ интервала). Если соответствие не найдено, сообщение в системный лог не выводится.

Исходя найденного уровня определяет приоритет сообщения и его тег (префикс). В системный лог командой logger посылается сообщение с указанным приоритетом и тегом:

```
# logger -p приоритет -t тег "тег: сообщение"
```

Кроме основного сообщения для icigna формируются:

○

список пользователей нарушителей;

○

укороченные сообщения для уровня детализации 1.

### Логи icigna
Форматы сообщений и кодов завершения плугина описаны в Plugin Output for Nagios https://nagios-plugins.org/doc/guidelines.html#PLUGOUTPUT.

Уровень опасности для логов icigna определяется СУММАРНОЙ метрике. Суммарная метрика определяется для определения уровня сравнивается с интервалами, задаваемыми флагами

○

-c - Critical

○

-w - Warning

Если соответствие не найдено, в icigna выводится сообщение:

```
POLICY OK: Политики контейнеризации не нарушены
```

Код завершение программы (которое обрабатывается на стороне сервера icigna) - 0.

Формат логов для nagios зависит от уровня детализации, задаваемый флагом -v[vv] (см. Verbose Output https://nagios-plugins.org/doc/guidelines.html#AEN41):

```
Флаг        | Уровень
------------|--------
отcутствует | 0
-v          | 1
-vv         | 2
-vvv        | 3
...         | 3
```

Для всех уровней формируется префикс сообщение формата:

```
POLICY $prefix:
```

Где prefix в зависимости от уровня опасности принимает значения:

○

-c - Critical

○

-w - Warning

Если уровень детализации - 0, то выводится укороченное сообщение.

```
POLICY $prefix: Нарушение политик контейнеризации пользователей users
```

Где users - список пользователей у которых обнаружены нарушения.

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

```
POLICY $prefix: Нарушение политик контейнеризации пользователей $users | Есть пользователи:
укороченное сообщение
...
```

Если уровень детализации - 2, то к сообщению добавляется второй уровень детализации из списка полных сообщений сформированных при формировании системных логов.

```
POLICY $prefix: Нарушение политик контейнеризации пользователей $users | Есть пользователи:
укороченное сообщение
...
укороченное сообщение |
полное сообщение
...
```

После вывода сообщений плугин завершается кодом завершения:

○

Critical - 2

○

Warning - 1

### Запуск сервиса через systemd/Timers
Кроме запуска скрипта через nagios скрипт может запускаться через systemd/Timers.

В состав пакета входит systemd-файлы podsec-inotify-check-images.service, podsec-inotify-check-images.timer. Файл сервисов podsec-inotify-check-images.service описывает в параметре ExecStart строку с описанием режима запуска скрипта podsec-inotify-check-images. Скрипт запускается с флагами -vvv -c 100 - выводить подробную информацию, все сообщения имеют уровень c - критический. Если во время работы скрипта обнаружены некорректные настройки политики, они выводятся в системный лог и передаются почтой системному администратору (root).

Расписание запуска сервиса podsec-inotify-check-images.service описывается в параметре OnCalendar файла расписания podsec-inotify-check-images.timer. Сервис вызывается ежечасно.

По умолчанию таймер запуска сервиса выключен. Для его включения наберите команду:

```
#  systemctl enable --now podsec-inotify-check-images.timer
```

Если необходимо изменить режим запуска скрипта отредактируйте параметр OnCalendar файла расписания podsec-inotify-check-images.timer.

## EXAMPLES
podsec-inotify-check-images -vvv -w 0 -h 0 -c 100

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-inotify-check-kubeapi

title: podsec-inotify-check-kubeapi(1)

summary: скрипт мониторинга аудита API\-интерфейса kube\-apiserver control\-plane узла

text:
# podsec-inotify-check-kubeapi(1)

## NAME
podsec-inotify-check-kubeapi - скрипт мониторинга аудита API-интерфейса kube-apiserver control-plane узла

## SYNOPSIS
podsec-inotify-check-kubeapi [-d]

## DESCRIPTION
Скрипт производит мониторинг файла /etc/kubernetes/audit/audit.log аудита API-интерфейса kube-apiserver.

Политика аудита располагается в файле /etc/kubernetes/audit/policy.yaml:

```
apiVersion: audit.k8s.io/v1
kind: Policy
omitManagedFields: true
rules:
# do not log requests to the following
- level: None

  nonResourceURLs:

  - "/healthz*"

  - "/logs"

  - "/metrics"

  - "/swagger*"

  - "/version"

  - "/readyz"

  - "/livez"
- level: None

  users:

    - system:kube-scheduler

    - system:kube-proxy

    - system:apiserver

    - system:kube-controller-manager

    - system:serviceaccount:gatekeeper-system:gatekeeper-admin
- level: None

  userGroups:

    - system:nodes

    - system:serviceaccounts

    - system:masters
# limit level to Metadata so token is not included in the spec/status
- level: Metadata

  omitStages:

  - RequestReceived

  resources:

  - group: authentication.k8s.io

    resources:

    - tokenreviews
# extended audit of auth delegation
- level: RequestResponse

  omitStages:

  - RequestReceived

  resources:

  - group: authorization.k8s.io

    resources:

    - subjectaccessreviews
# log changes to pods at RequestResponse level
- level: RequestResponse

  omitStages:

  - RequestReceived

  resources:

  - group: "" # core API group; add third-party API services and your API services if needed

    resources: ["pods"]

    verbs: ["create", "patch", "update", "delete"]
# log everything else at Metadata level
- level: Metadata

  omitStages:

  - RequestReceived
```

Текущие настройки производят логирование всех обращений "несистемных" пользователей (в том числе анонимных) к ресурсам kubernetes.

Скрипт производит выборку всех обращений, в ответ на которые был сформирован код более 400 - запрет доступа. Все эти факты записываются в системный журнал и накапливаются в файле логов /var/lib/podsec/u7s/log/kubeapi/forbidden.log, который периодически передается через посту системному адмиристратору.

## OPTIONS
○

-d - скирпт запускается в режиме демона, производящего онлайн мониторинг файла /etc/kubernetes/audit/audit.log и записывающего факты запросов с запретом доступа в системный журнал и файл логов /var/lib/podsec/u7s/log/kubeapi/forbidden.log.

○

-m - скрипт посылает файл логов /var/lib/podsec/u7s/log/kubeapi/forbidden.log почтой системному администратору (пользователь root) и обнуляет файл логов.

В состав пакета кроме этого скрипта входят:

○

файл описания сервиса /lib/systemd/system/podsec-inotify-check-kubeapi.service. Для его запуска необходимо выполнить команды:

○

Файла расписания /lib/systemd/system/podsec-inotify-check-kubeapi-mail.timer, задающий в параметре OnCalendar расписание запуска сервиса /lib/systemd/system/podsec-inotify-check-kubeapi-mail.timer. Таймер вызывается ежечасно.

По умолчанию таймер запуска сервиса выключен. Для его включения наберите команду:

```
#  systemctl enable --now podsec-inotify-check-kubeapi-mail.timer
```

Если необходимо изменить режим запуска скрипта отредактируйте параметр OnCalendar файла расписания podsec-inotify-check-kubeapi-mail.timer.

## EXAMPLE
podsec-inotify-check-kubeapi -d

podsec-inotify-check-kubeapi -m

## SECURITY CONSIDERATIONS
Кроме мониторинга фактов запрета доступа возможен мониторинг других фактов подозрительной активности.

## SEE ALSO
○

Auditing https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

○

kube-apiserver Audit Configuration (v1) https://kubernetes.io/docs/reference/config-api/apiserver-audit.v1/

○

Kubernetes Audit Logs - Best Practices And Configuration https://signoz.io/blog/kubernetes-audit-logs/

○

How to monitor Kubernetes audit logs https://www.datadoghq.com/blog/monitor-kubernetes-audit-logs/#monitor-api-authentication-issues

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-inotify-check-policy

title: podsec-inotify-check-policy(1)

text:
# podsec-inotify-check-policy(1)

## NAME
podsec-inotify-check-policy - Плугин проверяет настройки политики контейнеризации на узле

## SYNOPSIS
podsec-inotify-check-policy [-v[vv]] [-a интервал] [-f интервал] -c интервал -h интервал [-m интервал] -w интервалъ [-l интервал] [-d интервал] [-M EMail]

## DESCRIPTION

### Общее описание
Плугин проверяет настройки политики контейнеризации на узле.

Проверка идет по следующим параметрам:

файл policy.json установки транспортов и политик доступа к регистраторам:

```
    Параметр контроля пользователей                                                                                | Вес метрики

    --------------------------------------------------------------------------------------------------------------------------|-------------

    имеющих `defaultPolicy != reject`, но не входящих в группу `podman_dev`                                                   | 102

    не имеющих не имеющих `registry.local` в списке регистраторов для которых проверяется наличие электронной подписи образов | 103

    имеющих в политике регистраторы для которых не проверяется наличие электронной подписи образов                            | 104

    имеющих в списке поддерживаемых транспорты отличные от `docker` (транспорт получения образов с регистратора)              | 105
```

файлы привязки регистраторов к серверам хранящим электронные подписи (файл привязки о умолчанию default.yaml и файлы привязки регистраторов *.yaml каталога registries.d). Наличие (число) пользователей:

```
    Параметр контроля  пользователей                                                                             | Вес метрики

    -------------------------------------------------------------------------------------------------------------|-------------

    не использующих хранилище подписей  `http://sigstore.local:81/sigstore/` как хранилище подписей по умолчанию | 106
```

○

контроль групп пользователей

наличие пользователей имеющих образы, но не входящих в группу podman:

```
        Параметр контроля пользователей                                        | Вес метрики

        -----------------------------------------------------------------------|-------------

        наличие пользователей имеющих образы, но не входящих в группу `podman` | 101
```

```
* наличие пользователей группы `podman` (за исключением входящих в группу `podman_dev`):
```

```
        Параметр контроля  пользователей                                     | Вес метрики

        ---------------------------------------------------------------------|-------------

        входящих в группу `wheel`                                            | 107

        имеющих каталог `.config/containers/` открытым на запись и изменения | 90 * `доля_нарушителей`

        не имеющих файла конфигурации `.config/containers/storage.conf`      | 90 * `доля_нарушителей
```

доля_нарушителей считается как: число_нарушителей / число_пользователей_группы_podman

Все веса метрик суммируются и формируется итоговая метрика.

## OPTIONS
При указании флага -M Email итоговое сообщение отсылается указанному пользователю.

Уровень опасности определяется при запуске флагами:

для системных логов:

```
    Имя уровня  | Уровень | Префикс    | Флаг | Рекомендуемое значение интервала

    ------------|---------|------------|------|------------------------

    аварийный   |    7    | Crash      | `-a` | не указывать

    фатальный   |    6    | Fatal      | `-f` | не указывать

    критический |    5    | Critical   | `-c` | 100

    высокий     |    4    | Heigh      | `-h` | 0

    средний     |    3    | Middle     | `-m` | не указывать

    низкий      |    2    | Low        | `-l` | не указывать

    отладочный  |    1    | Debug      | `-d` | не указывать
```

для сервера icigna:

```
    Имя уровня     | Уровень | Префикс    | Флаг | Рекомендуемое значение интервала

    ---------------|---------|------------|------|-----------------------

    критический    |    2    | Critical   | `-c` | 100

    предупреждение |    1    | Warning    | `-w` | 0
```

Любой параметр может отсутствовать. В этом случае он не рассматривается при просмотре соответствия полученной метрики интервалам.

Значение параметров имеют формат интервала, описанного в документации по nagios: Threshold and Ranges https://nagios-plugins.org/doc/guidelines.html#THRESHOLDFORMAT.

Общее описание:

[@]start:end

Замечания:

○

start ≤ end

○

start и : не требуется если start=0

○

если интервал задан в формате start: и конец не задан, то концом интервала считается бесконечность ꝏ

○

для указания отрицательной бесконечности (-ꝏ) используйте ~

○

триггер срабатывает когда значение метрики ВНЕ УКАЗАННОГО ИНТЕРВАЛА (начальные и конечные точки включаются в интервал)

○

если интервал начинается с символа @, тогда условие инвертируется - триггер срабатывает при значении метрики В УКАЗАННОМ ИНТЕРВАЛЕ (начальные и конечные точки включаются в интервал)

Примеры возможных форматов:

```
Формат интервала | Описание условия срабатывания триггера
-----------------|--------------------------------------
100              | metrica < 0 || metrica > 100 (вне интервала 0-100)
100:             | metrica < 100 (вне интервала 100-ꝏ)
~:100            | metrica > 100 (вне интервала -ꝏ-100)
20-100           | metrica < 20 || metrica > 100 (вне интервала 20-100)
@20-100          | metrica >= 20 && metrica <= 100 (в интервале 20-100)
```

### Системные логи
Для системных логов уровень опасности определяется для каждого сообщения. Интервалы уровней опасностей, заданные параметрами просматриваются в порядке от большого к меньшему. Уровень сообщения определяется по первому найденному соответствию (не забываете, что триггер срабатывает при нахождении метрики ВНЕ интервала). Если соответствие не найдено, сообщение в системный лог не выводится.

Исходя найденного уровня определяет приоритет сообщения и его тег (префикс). В системный лог командой logger посылается сообщение с указанным приоритетом и тегом:

```
# logger -p приоритет -t тег "тег: сообщение"
```

Кроме основного сообщения для icigna формируются:

○

список пользователей нарушителей;

○

укороченные сообщения для уровня детализации 1.

### Логи icigna
Форматы сообщений и кодов завершения плугина описаны в Plugin Output for Nagios https://nagios-plugins.org/doc/guidelines.html#PLUGOUTPUT.

Уровень опасности для логов icigna определяется СУММАРНОЙ метрике. Суммарная метрика определяется для определения уровня сравнивается с интервалами, задаваемыми флагами

○

-c - Critical

○

-w - Warning

Если соответствие не найдено, в icigna выводится сообщение:

```
POLICY OK: Политики контейнеризации не нарушены
```

Код завершение программы (которое обрабатывается на стороне сервера icigna) - 0.

Формат логов для icigna зависит от уровня детализации, задаваемый флагом -v[vv] (см. Verbose Output https://nagios-plugins.org/doc/guidelines.html#AEN41):

```
Флаг        | Уровень
------------|--------
отcутствует | 0
-v          | 1
-vv         | 2
-vvv        | 3
...         | 3
```

Для всех уровней формируется префикс сообщение формата:

```
POLICY $prefix:
```

Где prefix в зависимости от уровня опасности принимает значения:

○

-c - Critical

○

-w - Warning

Если уровень детализации - 0, то выводится укороченное сообщение.

```
POLICY $prefix: Нарушение политик контейнеризации пользователей users
```

Где users - список пользователей у которых обнаружены нарушения.

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

```
POLICY $prefix: Нарушение политик контейнеризации пользователей $users | Есть пользователи:
укороченное сообщение
...
```

Если уровень детализации - 2, то к сообщению добавляется второй уровень детализации из списка полных сообщений сформированных при формировании системных логов.

```
POLICY $prefix: Нарушение политик контейнеризации пользователей $users | Есть пользователи:
укороченное сообщение
...
укороченное сообщение |
полное сообщение
...
```

После вывода сообщений плугин завершается кодом завершения:

○

Critical - 2

○

Warning - 1

### Запуск сервиса через systemd/Timers
Кроме запуска скрипта через nagios скрипт может запускаться через systemd/Timers. В состав пакета входит systemd-файлы podsec-inotify-check-policy.service, podsec-inotify-check-policy.timer. Файл сервисов podsec-inotify-check-policy.service описывает в параметре ExecStart строку с описанием режима запуска скрипта podsec-inotify-check-policy. Скрипт запускается с флагами -vvv -c 100 - выводить подробную информацию, все сообщения имеют уровень c - критический. Если во время работы скрипта обнаружены некорректные настройки политики, они выводятся в системный лог и передаются почтой системному администратору (root).

Расписание запуска сервиса podsec-inotify-check-policy.service описывается в параметре OnCalendar файла расписания podsec-inotify-check-policy.timer. Сервис вызывается ежечасно.

По умолчанию таймер запуска сервиса выключен. Для его включения наберите команду:

```
#  systemctl enable --now podsec-inotify-check-policy.timer
```

Если необходимо изменить режим запуска скрипта отредактируйте параметр OnCalendar файла расписания podsec-inotify-check-policy.timer.

## EXAMPLES
Проанализировать политики политики с максимальным уровнем детализации. Критический уровень (nagios, system) >100. Уровень предупреждений (nagios) >0. Низкий уровень (system) >0.

```
# podsec-inotify-check-policy -vvv  -w 0 -h 0 -c 100
POLICY Critical(18): Нарушение политик контейнеризации пользователей  "imagedeveloper" "k8s-user1" "kaf" "kafpodman" "podmanuser" "root" "securityadmin" "user" "user1"  | Есть пользователи:
вне группы podman,
способные получать любой образ
способные получать локальный образ без подписи
способные получать любой образ без подписи
способные получать любой образ через запрещенный транспорт
не использующие локальный хранитель подписей
входящие в группу wheel
не имеющих конфигурационного файла
способные изменить конфигурацию" |
Critical(101): Пользователи "kafpodman"  имеют образы, но не входят в группу ´podman´
Critical(102): Пользователи "user"  имеют в policy.json defaultPolicy!=reject, но не входят в группу ´podman_dev´
Critical(103): Пользователи "user"  не имеют registry.local в списке регистраторов для которых проверяется наличие электронной подписи образов
Critical(104): Пользователи "root" "kaf" "kafpodman" "podmanuser" "securityadmin" "user1"  имеют в политике регистраторы для которых не проверяется наличие электронной подписи образов
Critical(105): Пользователи "user"  имеют в списке поддерживаемых транспорты отличные от docker
Critical(106): Пользователи "imagedeveloper" "user"  не используют хранилище подписей  http://sigstore.local:81/sigstore/ как хранилище подписей по умолчанию
Critical(107): Пользователи  "kaf" "securityadmin" входят в группы ´podman´ и ´wheel´
High(72): Пользователи  "k8s-user1" "kaf" "securityadmin" "user1" не имеют конфигурационного файла .config/containers/storage.conf
High(18): Пользователи  "user" имеют открытым для записи каталог конфигурации .config/containers
```

Код завершения программы - 2.

## SEE ALSO
○

Nagios Plugins. Development Guidelines https://nagios-plugins.org/doc/guidelines.html#PLUGOUTPUT

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


podsec-inotify-check-vuln

title: podsec-inotify-check-vuln(1)

summary: скрипт мониторинга docker\-образов узла сканером безопасности trivy

text:
# podsec-inotify-check-vuln(1)

## NAME
podsec-inotify-check-vuln - скрипт мониторинга docker-образов узла сканером безопасности trivy

## SYNOPSIS
podsec-inotify-check-vuln [-m EMail]

## DESCRIPTION
Для корректной работы скрипта необходимо запустить сервис trivy: systemctl enable --now trivy

Скрипт производит мониторинг docker-образов узла сканером безопасности trivy:

○

Если скрипт запускается от имени пользователя root скрипт:

○

проверяет сканером trivy rootfull образы;

○

для всех пользователей каталога /home/ проверяется наличие rootless-образов. При их наличии проверяет сканером trivy эти образы.

○

Если скрипт запускается от имени обычного пользователя проверяется наличие rootless-образов. При их наличии проверяет сканером trivy эти образы.

Результат анализа посылается в системный лог. При наличии флага -m если при анализе образа число обнаруженных угроз уровня HIGH больше 0, результат посылается почтой системному администратору (root).

## OPTIONS
При указании флага -m EMail при наличии уязвимостей уровня ´HIGH´ сообщение отсылается указанному пользователю.

В состав пакета кроме этого скрипта входят:

○

Файл сервисов podsec-inotify-check-vuln.service описывает в параметре ExecStart строку с описанием режима запуска скрипта podsec-inotify-check-vuln для обнаружения уязвимостей, записи их в системный лог и передачи их почтой системному администратору.

○

Файла расписания podsec-inotify-check-vuln.timer, задающий в параметре OnCalendar расписание запуска сервиса podsec-inotify-check-vuln.service. Сервис вызывается ежечасно.

По умолчанию таймер запуска сервиса выключен. Для его включения наберите команду:

```
#  systemctl enable --now podsec-inotify-check-vuln.timer
```

Если необходимо изменить режим запуска скрипта отредактируйте параметр OnCalendar файла расписания podsec-inotify-check-vuln.timer.

## EXAMPLES
podsec-inotify-check-vuln

## SECURITY CONSIDERATIONS
-

## SEE ALSO
The all-in-one open source security scanner https://trivy.dev/

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


title: podsec-u7s-kubeadm(1)

summary: инициализация master\- или worker\-узла в rootless\-kubernetes (alt usernetes)

text:
# podsec-u7s-kubeadm(1)

## NAME
podsec-u7s-kubeadm - инициализация master- или worker-узла в rootless-kubernetes (alt usernetes)

## SYNOPSIS
podsec-u7s-kubeadm init| join <ApiServer>:6443 --token ... --discovery-token-ca-cert-hash ...

## Установка master-узла
1.

Измените переменную PATH:

```
export PATH=/usr/libexec/podsec/u7s/bin/:$PATH
```

1.

Запустите команду:

```
# kubeadm init
```

По умолчанию уровень отладки устанавливается в 0. Если необходимо увеличить уровень отладки укажите перед подкомандой init флаг -v n. Где n принимает значения от 0 до 9-ти.

После:

○

генерации сертификатов в каталоге /etc/kuarnetes/pki,

○

загрузки образов, -генерации conf-файлов в каталоге /etc/kubernetes/manifests/, /etc/kubernetes/manifests/etcd/

○

запуска сервиса kubelet и Pod´ов системных kubernetes-образов

инициализируется kubernet-кластер из одного узла.

По окончании скрипт выводит строки подключения master(Control Plane) и worker-узлов:

```
You can now join any number of control-plane nodes by copying certificate authorities
and service account keys on each node and then running the following as root:
kubeadm join xxx.xxx.xxx.xxx:6443 --token ... --discovery-token-ca-cert-hash sha256:.. --control-plane
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join xxx.xxx.xxx.xxx:6443 --token ... --discovery-token-ca-cert-hash sha256:...
```

1.

После завершения скрипта проверьте работу usernetes (rootless kuber)

```
# kubectl get nodes -o wide
NAME       STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE           KERNEL-VERSION         CONTAINER-RUNTIME
<host>     Ready    control-plane   16m   v1.26.3   10.96.0.1     none        ALT SP Server 11100-01   5.15.105-un-def-alt1   cri-o://1.26.2
```

Проверьте работу usernetes (rootless kuber)

```
# kubectl get all -A
NAMESPACE     NAME                                   READY   STATUS    RESTARTS   AGE
kube-system   pod/coredns-c7df5cd6c-5pkkm            1/1     Running   0          19m
kube-system   pod/coredns-c7df5cd6c-cm6vf            1/1     Running   0          19m
kube-system   pod/etcd-host-212                      1/1     Running   0          19m
kube-system   pod/kube-apiserver-host-212            1/1     Running   0          19m
kube-system   pod/kube-controller-manager-host-212   1/1     Running   0          19m
kube-system   pod/kube-proxy-lqf9c                   1/1     Running   0          19m
kube-system   pod/kube-scheduler-host-212            1/1     Running   0          19m
NAMESPACE     NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes   ClusterIP   10.96.0.1    none        443/TCP                  19m
kube-system   service/kube-dns     ClusterIP   10.96.0.10   none        53/UDP,53/TCP,9153/TCP   19m
NAMESPACE     NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
kube-system   daemonset.apps/kube-proxy   1         1         1       1            1           kubernetes.io/os=linux   19m
NAMESPACE     NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/coredns   2/2     2            2           19m
NAMESPACE     NAME                                DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/coredns-c7df5cd6c   2         2         2       19m
```

Состояние всех Pod´ов должны быть в 1/1.

Проверьте состояние дерева процессов:

```
# pstree
...
├─systemd─┬─(sd-pam)
│         ├─dbus-daemon
│         ├─nsenter.sh───nsenter───_kubelet.sh───kubelet───11*[{kubelet}]
│         └─rootlesskit.sh───rootlesskit─┬─exe─┬─conmon───kube-controller───7*[{kube-controller}]
│                                        │     ├─conmon───kube-apiserver───8*[{kube-apiserver}]
│                                        │     ├─conmon───kube-scheduler───7*[{kube-scheduler}]
│                                        │     ├─conmon───etcd───8*[{etcd}]
│                                        │     ├─conmon───kube-proxy───4*[{kube-proxy}]
│                                        │     ├─2*[conmon───coredns───8*[{coredns}]]
│                                        │     ├─rootlesskit.sh───crio───10*[{crio}]
│                                        │     └─7*[{exe}]
│                                        ├─slirp4netns
│                                        └─8*[{rootlesskit}]
...
```

Процесс kubelet запускается как сервис в user namespace процесса rootlesskit.

Все остальные процессы kube-controller, kube-apiserver, kube-scheduler, kube-proxy, etcd, coredns запускаются как контейнеры от соответствующих образов registry.local/k8s-c10f1/kube-controller-manager:v1.26.3, registry.local/k8s-c10f1/kube-apiserver:v1.26.3, registry.local/k8s-c10f1/kube-scheduler:v1.26.3, registry.local/k8s-c10f1/kube-proxy:v1.26.3, registry.local/k8s-c10f1/etcd:3.5.6-0, registry.local/k8s-c10f1/coredns:v1.9.3.

1.

По умолчанию на master-узле пользовательские Podы не запускаются. Чтобы снять это ограничение наберите команду:

\# kubectl taint nodes <host> node-role.kubernetes.io/control-plane:NoSchedule- node/<host> untainted

1.

Проверьте загрузку deployment nginx:

\# kubectl apply -f https://k8s.io/examples/application/deployment.yaml

После загрузки образов nginx проверьте состояние deployment и Podов: ``` # kubectl get deployments.apps,pods NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx-deployment 2/2 2 2 5m34s

NAME READY STATUS RESTARTS AGE pod/nginx-deployment-85996f8dbd-2dw9h 1/1 Running 0 5m34s pod/nginx-deployment-85996f8dbd-r5dt4 1/1 Running 0 5m34s ```

1.

Проверьте загрузку образа registry.local/alt/alt:

\# kubectl run -it --image=registry.local/alt/alt -- bash If you don´t see a command prompt, try pressing enter. [root@bash /]# pwd

## Подключение worker-узла
1.

Измените переменную PATH:

```
export PATH=/usr/libexec/podsec/u7s/bin/:$PATH
```

1.

Скопируйте команду подключния worker-узла, полученную на этапе установки начального master-узла. Запустите ее:

kubeadm join xxx.xxx.xxx.xxx:6443 --token ... --discovery-token-ca-cert-hash sha256:...

По умолчанию уровень отладки устанавливается в 0. Если необходимо увеличить уровень отладки укажите перед подкомандой join флаг -v n. Где n принимает значения от 0 до 9-ти.

По окончании скрипт выводит текст:

```
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run ´kubectl get nodes´ on the control-plane to see this node join the cluster.
```

1.

Проверьте состояние дерева процессов:

```
# pstree
...
├─systemd─┬─(sd-pam)
│         ├─dbus-daemon
│         ├─nsenter.sh───nsenter───_kubelet.sh───kubelet───10*[{kubelet}]
│         └─rootlesskit.sh───rootlesskit─┬─exe─┬─conmon───kube-proxy───4*[{kube-proxy}]
│                                        │     ├─rootlesskit.sh───crio───9*[{crio}]
│                                        │     └─6*[{exe}]
│                                        ├─slirp4netns
│                                        └─8*[{rootlesskit}]
...
```

Процесс kubelet запускается как сервис в user namespace процесса rootlesskit.

Все остальные процессы kube-proxy, kube-flannel запускаются как контейнеры от соответствующих образов registry.local/k8s-c10f1/kube-proxy:v1.26.3, registry.local/k8s-c10f1/flannel:v0.19.2.

4 Зайдите на master-узел и проверьте подключение worker-узла: # kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME host-212 Ready control-plane 7h54m v1.26.3 10.96.0.1 <none> ALT SP Server 11100-01 5.15.105-un-def-alt1 cri-o://1.26.2 host-226 Ready <none> 8m30s v1.26.3 10.96.0.1 <none> ALT SP Server 11100-01 5.15.105-un-def-alt1 cri-o://1.26.2

1.

На master-узле под пользоваталем root выполните команду:

\# machinectl shell u7s-admin@ ~u7s-admin/usernetes/boot/nsenter.sh \ kubectl apply -f ~u7s-admin/usernetes/manifests/kube-flannel.yml Connected to the local host. Press ^] three times within 1s to exit session. [INFO] Entering RootlessKit namespaces: OK namespace/kube-flannel created clusterrole.rbac.authorization.k8s.io/flannel created clusterrolebinding.rbac.authorization.k8s.io/flannel created serviceaccount/flannel created configmap/kube-flannel-cfg created daemonset.apps/kube-flannel-ds created Connection to the local host terminated.

1.

На master-узле выполните команду: # kubectl get daemonsets.apps -A NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE kube-flannel kube-flannel-ds 2 2 2 2 1 <none> 102s kube-system kube-proxy 2 2 2 2 2 kubernetes.io/os=linux 8h Число READY каждого daemonset должно быть равно числу DESIRED и должно быть равно числу узлов кластера.

## EXAMPLES
podsec-u7s-kubeadm init podsec-u7s-kubeadm join 102.168.122.32:6443 --token ... --discovery-token-ca-cert-hash ...

## SECURITY CONSIDERATIONS
○

Так как все работа с кластером производится по REST-интерфейсу, то для обеспечения повышенных мер безопасности следует заводить ВСЕХ пользователей, включая администратора безопасности средства контейнеризации ВНЕ узлов кластера. Для работы с кластером достаточно команды kubectl, входящую в пакет kubernetes-client.

## SEE ALSO
○

Kubernetes https://www.altlinux.org/Kubernetes;

○

Usernetes: Kubernetes without the root privileges https://github.com/rootless-containers/usernetes;

○

Настройка аудита API-сервиса https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md;

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


title: podsec-k8s-rbac-bindrole(1)

text:
# podsec-k8s-rbac-bindrole(1)

## NAME
podsec-k8s-rbac-bindrole - привязывание пользователя к кластерной или обычной роли

## SYNOPSIS
podsec-k8s-rbac-bindrole имя_пользователя role|role=clusterrole|clusterrole роль имя_связки_роли [namespace]

## DESCRIPTION
Скрипт производит привязку пользователя к обычной или кластерной роли используя имя_связки_роли.

## OPTIONS
○

имя_пользователя должно быть создано командой podsec-k8s-rbac-create-user и сконфигурировано на доступ к кластеру командой podsec-k8s-rbac-create-kubeconfig;

○

тип роли может принимать следующие значения:

* role - пользователь привязывается к обычной роли с именем <роль> (параметр namespace в этом случае обязателен);

* role=clusterrole - пользователь привязывается к обычной роли используя кластерную роль с именем <роль> (параметр namespace в этом случае обязателен);

* clusterrole - пользователь привязывается к кластерной роли используя кластерную роль с именем <роль> (параметр namespace в этом случае должен отсутствовать).

○

роль - имя обычной или кластерной роли в зависимости от предыдущего параметра;

○

имя_связки_роли - имя объекта класса rolebindings или clusterrolebindings в зависимости от параметра тип роли. В рамках этого объекта к кластерной или обычной роли могут быть привязаны несколько пользователей.

○

namespace - имя namespace для обычной роли.

## EXAMPLES

```
podsec-k8s-rbac-bindrole k8s-user1 clusterrole edit sysadmin
podsec-k8s-rbac-bindrole k8s-user1 clusterrole view sysview
podsec-k8s-rbac-bindrole k8s-user1 role=clusterrole edit sysadmin default
podsec-k8s-rbac-bindrole k8s-user1 role=clusterrole system:basic-user basic-user default
podsec-k8s-rbac-bindrole k8s-user1 role=clusterrole system:basic-user basic-user smf
```

## SEE ALSO
○

Генерация сертификатов, создание рабочих мест администратора безопасности средства контейнеризации, администраторов информационной (автоматизированной) системы и назначение им RBAC-ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/README.md;

○

Описание основных классов ролей кластера (Roles, ClusterRoles) и механизмов из связываения с субъектами https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/rolesDescribe.md;

○

Настройка рабочих мест администраторов информационной (автоматизированной) системы (ClusterRole) https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md;

○

Настройка рабочих мест администраторов проектов (Role) https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md;

○

Настройка других ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md.

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


title: podsec-k8s-rbac-create-kubeconfig(1)

text:
# podsec-k8s-rbac-create-kubeconfig(1)

## NAME
podsec-k8s-rbac-create-kubeconfig

podsec-k8s-rbac-create-kubeconfig(1) -- создание ключей, сертификатов и файла конфигурации RBAC-пользователя

## SYNOPSIS
podsec-k8s-rbac-create-kubeconfig имя_пользователя[@<имя_удаленного_пользователя>] [группа ...]

## DESCRIPTION
Скрипт должен вызываться администратором безопасности средства контейнеризации.

Для rootless решения имя удаленного пользователя принимается u7s-admin.

Для rootfull решения необходимо после символа @ указать имя удаленного пользователя.

Скрипт в каталоге ~имя_пользователя/.kube производит:

○

Создании личного (private) ключа пользователя (файл имя_пользователя.key).

○

Создание запроса на подпись сертификата (CSR) (файл имя_пользователя.key).

○

Запись запроса на подпись сертификата CSR в кластер.

○

Подтверждение запроса на подпись сертификата (CSR).

○

Создание сертификата (файл имя_пользователя.crt).

○

Проверку корректности сертификата

○

Формирование файла конфигурации пользователя (файл config)

○

Добавление контекста созданного пользователя

## EXAMPLES
podsec-k8s-rbac-create-kubeconfig k8s-user1

## SEE ALSO
○

Генерация сертификатов, создание рабочих мест администратора безопасности средства контейнеризации, администраторов информационной (автоматизированной) системы и назначение им RBAC-ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/README.md;

○

Создание рабочих мест и сертификатов https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md.

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


title: podsec-k8s-rbac-create-remoteplace(1)

summary: создание удаленного рабочего места

text:
# podsec-k8s-rbac-create-remoteplace(1)

## NAME
podsec-k8s-rbac-create-remoteplace - создание удаленного рабочего места

## SYNOPSIS
podsec-k8s-rbac-create-remoteplace ip-адрес

## DESCRIPTION
Скрипт производит настройку удаленного рабочего места пользователя путем копирования его конфигурационного файла.

## EXAMPLES
podsec-k8s-rbac-create-remoteplace 192.168.122.234

## SECURITY CONSIDERATIONS
Для повышения безопасности работы с кластером имеет смысл вынести рабочие места пользователей на отдельные рабочие места.

Администратор безопасности средства контейнеризации копирует с помощью этого скрипта файл конфигурации .kube/config на свое рабочее место и получает возможность удаленной работы с кластером.

При создании рабочих мест администратор безопасности средства контейнеризации на своем рабочем месте с помощью скриптов podsec-k8s-rbac-create-user, podsec-k8s-rbac-create-kubeconfig, podsec-k8s-rbac-bindrole создает домашние директории и конфигурационный файл .kube/config пользователя, создавая у себя контекст созданного пользователя. Переключаясь в контекст пользователя администратор безопасности средства контейнеризации может тестировать права доступа созданного пользователя.

Пользователь на своем удаленном рабочем месте с помощью этого скрипта копирует конфигурационный файл себе.

Домашний каталог созданного пользователя на рабочем месте администратора безопасности средства контейнеризации удаляется.

## SEE ALSO
○

Генерация сертификатов, создание рабочих мест администратора безопасности средства контейнеризации, администраторов информационной (автоматизированной) системы и назначение им RBAC-ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/README.md;

○

Создание рабочего места администратора безопасности средства контейнеризации https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md.

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


title: podsec-k8s-rbac-create-user(1)

summary: создание RBAC\-пользователя

text:
# podsec-k8s-rbac-create-user(1)

## NAME
podsec-k8s-rbac-create-user - создание RBAC-пользователя

## SYNOPSIS
podsec-k8s-rbac-create-user имя_пользователя

## DESCRIPTION
Скрипт:

○

создает RBAC пользователя

○

создает в домашнем директории каталог .kube

○

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

## EXAMPLES
podsec-k8s-rbac-create-user k8s-user1

## SEE ALSO
○

Генерация сертификатов, создание рабочих мест администратора безопасности средства контейнеризации, администраторов информационной (автоматизированной) системы и назначение им RBAC-ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/README.md;

○

Создание рабочих мест и сертификатов https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md.

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


title: podsec-k8s-rbac-get-userroles(1)

text:
# podsec-k8s-rbac-get-userroles(1)

## NAME
podsec-k8s-rbac-get-userroles - получить список кластерные и обычных ролей пользователя

## SYNOPSIS
podsec-k8s-rbac-get-userroles имя_пользователя [showRules]

## DESCRIPTION
Скрипт формирует список кластерных и обычных ролей которые связаны с пользователем. При указании флага showRules, для каждой роли указывается список правил ("rules:[...]"), которые принадлежат каждой роли пользователя.

Результат возвращается в виде json-строки формата:

```
{

  "username": {

    "clusterRoles": [...],

    "roles": {

      "allNamespaces": [...],

      "namespaces": [

        {

          "namespace1": [...],

          ...

        }

    }

  }
}
```

Где [...] - массив объектов типа:

```
{

  "bindRoleName": "bindRoleName",

  "bindedRoleType": "ClusterRole|Role",

  "bindedRoleName": "bindedRoleName",

  "unbindCmd": "podsec-k8s-rbac-unbindrole ..."
}
```

## EXAMPLES
podsec-k8s-rbac-get-userroles k8s-user1 | yq -y

```
k8s-user1:

  clusterRoles:

    - bindName: sysadmin

      roleType: ClusterRole

      roleName: edit

      unbindCmd: podsec-k8s-rbac-unbindrole k8s-user1 clusterrole edit sysadmin

    - bindName: sysview

      roleType: ClusterRole

      roleName: view

      unbindCmd: podsec-k8s-rbac-unbindrole k8s-user1 clusterrole view sysview

  roles:

    namespaces:

      - default:

          - bindName: basic-user

            roleType: ClusterRole

            roleName: system:basic-user

            unbindCmd: podsec-k8s-rbac-unbindrole k8s-user1 role system:basic-user

              basic-user default

          - bindName: sysadmin

            roleType: ClusterRole

            roleName: edit

            unbindCmd: podsec-k8s-rbac-unbindrole k8s-user1 role edit sysadmin default

      - smf:

          - bindName: basic-user

            roleType: ClusterRole

            roleName: system:basic-user

            unbindCmd: podsec-k8s-rbac-unbindrole k8s-user1 role system:basic-user

              basic-user smf
```

## SEE ALSO
○

Генерация сертификатов, создание рабочих мест администратора безопасности средства контейнеризации, администраторов информационной (автоматизированной) системы и назначение им RBAC-ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/README.md;

○

Описание основных классов ролей кластера (Roles, ClusterRoles) и механизмов из связываения с субъектами https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/rolesDescribe.md;

○

Настройка рабочих мест администраторов информационной (автоматизированной) системы (ClusterRole) https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md;

○

Настройка рабочих мест администраторов проектов (Role) https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md;

○

Настройка других ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md.

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


title: podsec-k8s-rbac-unbindrole(1)

text:
# podsec-k8s-rbac-unbindrole(1)

## NAME
podsec-k8s-rbac-unbindrole - отвязывание пользователя от кластерной или обычной роли

## SYNOPSIS
podsec-k8s-rbac-unbindrole имя_пользователя role|clusterrole роль имя_связки_роли [namespace]

## DESCRIPTION
Скрипт производит отвязку роли от кластерной или обычной роли, созданной командой podsec-k8s-rbac-bindrole. Полный текст команды можно получить в выводе команды podsec-k8s-rbac-get-userroles в поле unbindCmd. Если в указанном имя_связки_роли объекте класса rolebindings или clusterrolebindings еще остаются пользователи - объект модифицируется. Если список становится пуст - объект удаляется.

## OPTIONS
○

имя_пользователя должно быть создано командой podsec-k8s-rbac-create-user и сконфигурировано на доступ к кластеру командой podsec-k8s-rbac-create-kubeconfig;

○

тип роли может принимать следующие значения:

* role - пользователь привязывается к обычной роли с именем <роль> (параметр namespace в этом случае обязателен);

* clusterrole - пользователь привязывается к кластерной роли используя кластерную роль с именем <роль> (параметр namespace в этом случае должен отсутствовать).

○

роль - имя обычной или кластерной роли в зависимости от предыдущего параметра;

○

имя_связки_роли - имя объекта класса rolebindings или clusterrolebindings в зависимости от параметра тип роли. В рамках этого объекта к кластерной или обычной роли могут быть привязаны несколько пользователей.

○

namespace - имя namespace для обычной роли.

## EXAMPLES
podsec-k8s-rbac-unbindrole k8s-user1 clusterrole view sysview

## SEE ALSO
○

Генерация сертификатов, создание рабочих мест администратора безопасности средства контейнеризации, администраторов информационной (автоматизированной) системы и назначение им RBAC-ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/README.md;

○

Описание основных классов ролей кластера (Roles, ClusterRoles) и механизмов из связываения с субъектами https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/rolesDescribe.md;

○

Настройка рабочих мест администраторов информационной (автоматизированной) системы (ClusterRole) https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md;

○

Настройка рабочих мест администраторов проектов (Role) https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md;

○

Настройка других ролей https://github.com/alt-cloud/podsec/blob/master/k8s/RBAC/addUser/clusterroleBinding.md.

## AUTHOR
Костарев Алексей, Базальт СПО kaf@basealt.ru


qbittorrent

package: qbittorrent

title: qbittorrent(1)

summary: клиент сети БитТоррент.

text:
# qbittorrent(1)

## НАЗВАНИЕ
qBittorrent — клиент сети БитТоррент.

## АВТОРЫ
Christophe Dumez chris@qbittorrent.org.


qbittorrent-nox

package: qbittorrent-nox

title: qbittorrent-nox(1)

summary: nox \(em клиент сети БитТоррент для командной строки.

text:
# qbittorrent-nox(1)

## НАЗВАНИЕ
qBittorrent-nox — клиент сети БитТоррент для командной строки.

## АВТОРЫ
Christophe Dumez chris@qbittorrent.org.


qelectrotech

package: qelectrotech

title: qelectrotech(1)

summary: Редактор электросхем

text:
# qelectrotech(1)

## NAME
qelectrotech - Редактор электросхем

## SYNOPSIS
qelectrotech [--common-elements-dir=DIR] [--config-dir=DIR] [--lang-dir=DIR] [--help] [-v|--version] [--license] [FILE]...

## ОПИСАНИЕ
QElectroTech - это редактор электрических схем. Схемы (*.qet) и электрические элементы (*.elmt) хранятся в формате XML. В схемах могут быть использованы элементы как из коллекций QElectroTech, так и из коллекций пользователя. Обычно общие коллекции QElectroTech доступны пользователям для чтения, но недоступны для редактирования. У каждого пользователя есть собственная коллекция, которую он может изменять по своему усмотрению.

## ПАРАМЕТРЫ
--common-elements-dir=DIR

DIR - корневой каталог коллекций QElectroTech. Замечание : Этот параметр доступен только если при компиляции была указана директива QET_ALLOW_OVERRIDE_CED_OPTION.

--config-dir=DIR

DIR - каталог конфигурации текущего пользователя. Этот каталог содержит файл qelectrotech.conf, который содержит настройки программы, и подкаталог elements, содержащий коллекцию элементов пользователя. Замечание : Этот параметр доступен только если при компиляции была указана директива QET_ALLOW_OVERRIDE_CD_OPTION.

--lang-dir=DIR

Ищет фалы локализаций в каталоге DIR.

--help

Показывает короткое описание доступных параметров.

-v, --version

Показывает версию программы (т.е.: 0.1).

--license

Показывает лицензию программы (GNU/GPL).

Обратите внимание, что если в командной строке указан один из трех последних параметров, программа прекратит исполнение после отображения соответствующей информации. Если запущенный пользователем экземпляр программы все еще работает, этот экземпляр примет команду, и особенно файлы для открытия. Тем не менее, параметры, переопределяющие каталоги (общие коллекции, конфигурации и файлов локализации) не будут приняты. Если имена файлов оканчиваются на .elmt, QElectroTech будет пытаться открыть их в редакторе элементов. Иначе они будут открыты как схемы.

## АВТОРЫ
Benoit Ansieau <benoit@qelectrotech.org>

Xavier Guerrin <xavier@qelectrotech.org>

Laurent Trinques <scorpio@qelectrotech.org>

Joshua Claveau <joshua@qelectrotech.org>

Cyril.frausti <cyril@qelectrotech.org>

## СООБЩЕНИЯ ОБ ОШИБКАХ
Если вы заметили необычное для вас поведение программы загляните сперва в FAQ <http://qelectrotech.org/wiki/doku.php?id=doc:faq> и наш BugTracker <http://qelectrotech.org/bugtracker/> чтобы убедиться, что проблема еще не известна. В этом случае сообщите об ошибке через BugTracker.

## АВТОРСКИЕ ПРАВА
Авторские права (c) Разработчики QElectroTech.

Лицензия : GNU/GPL v2+ : <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>

Эта программа - свободное программное обесчение. Вы можете изменять и передавать ее другим. Поставляется как есть и БЕЗ ВСЯКИХ ГАРАНТИЙ.

## СМОТРИТЕ ТАКЖЕ
Официальная страница в сети Интернет : <http://qelectrotech.org/>