https://kubernetes.io/docs/reference/kubectl/conventions/

Create an NGINX Pod

kubectl run nginx --image=nginx

Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)

kubectl run nginx --image=nginx --dry-run=client -o yaml

Create a deployment

kubectl create deployment --image=nginx nginx

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Generate Deployment YAML file (-o yaml). Don’t create it(–dry-run) and save it to a file.

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

Make necessary changes to the file (for example, adding more replicas) and then create the deployment.

kubectl create -f nginx-deployment.yaml

Просмотр подов по метке label

kubectl get pods -l app=myapp

• Наличие модуля TPM2 на материнской плате
• Использование SecureBoot
• Использование LUKS шифрования при установке системы
• Пароль BIOS, SecureBoot, LVM и пароль от учетной записи в системе должны отличаться (для безопасности)

Этапы настройки:

1. Устанавливаем пароль доступа в BIOS
2. Включаем SecureBoot
   BIOS → Security → Secure Boot → Secure Boot [Enabled] (active), ................................Secure Boot mode [Standard]
3. Проверяем доступность модуляTPM2:
BIOS → Advanced → Trusted Computing → Security Device Support [Enable], ......................................SHA256 PCR Bank [Enabled], ......................................Device select [auto]
4. Устанавливаем ОС Ubuntu 22.04.3 (актуально на 15 августа 2023)
5. На этапе установки "Updates and other software" обязательно включаем пароль в SecureBoot
6. На шаге "Installation type" Включаем LVM + Encrypt
7. На следующем шаге вводим пароль для шифрования LVM диска.
8. Далее проводим стандартную установку системы.
9. После установки при первом включении нужно выбрать Continue boot
10. После установки ОС обновляем все пакеты
    sudo apt update && sudo apt upgrade -y
11. Устанавливаем недостающие пакеты:
    Сначала ставим openssh-server и потом можно копипастить все остальное уже через терминал по ssh
    sudo apt install -y openssh-server
sudo apt install -y clevis clevis-tpm2 clevis-luks clevis-dracut
12. Предварительно cоздадим резервную копию LUKS-заголовка на случай возникновения каких-либо проблем в будущем:
    sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file ~/header-nvme0n1p3.img # сделать бэкап заголовков
    Данный файл следует надёжно хранить в безопасном месте на другом носителе. Внутри него находится LUKS заголовок с включением всех созданных ключевых слотов и соответствующих им ключей шифрования. Его восстановление позволит откатить все произведённые ниже изменения.
13. Сгенерируем ключевую пару внутри TPM, "pcr_bank":"sha256" и "pcr_ids":"0,1" и привяжем её к зашифрованному разделу:
    sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_bank":"sha256","pcr_ids":"0,1"}'
# /dev/nvme0n1p3 - наш зашифрованный раздел, можно посмотреть через lsblk
    
    На ошибку:
    Warning: Value 512 is outside of the allowed entropy range, adjusting it.
можно не обращать внимания
    
    Вот краткий обзор наиболее часто используемых идентификаторов PCR:
• PCR 0: Содержит измерения, связанные с прошивкой, включая поставщика прошивки, версию и дату выпуска.
• PCR 1: Содержит измерения, связанные с конфигурацией платформы, включая тип и производителя аппаратной платформы.
• PCR 2: Содержит измерения, связанные с конфигурацией загрузчика, включая версию загрузчика и параметры конфигурации.
• PCR 3: Содержит измерения, связанные с конфигурацией ядра, включая версию ядра и параметры конфигурации.
• PCR 4: Содержит измерения, относящиеся к начальному виртуальному диску (initrd), который используется для загрузки ядра.
• PCR 5-7: Содержит измерения, связанные с процессом загрузки, включая загрузчики, файлы конфигурации и компоненты для конкретных платформ.
14. Проверим, появился ли пункт clevis в списке доступных слотов:
    sudo cryptsetup luksDump /dev/nvme0n1p3 
Вывод команды:
...
...
Tokens:
0: clevis
Keyslot: 1
...
...
Если видим подобный вывод, значит токен добавился.
    Для сведения: при необходимости  можно добавлять несколько таких токенов, они будут пронумерованы по порядку кейслотами начиная с Keyslot: 1, так же можно удалить кейслот командой:
    sudo clevis luks unbind -d /dev/nvme0n1p3 -s 1
# ВНИМАНИЕ! эта команда УДАЛЯЕТ добавленный токен
15. При успешном добавлении токена пересоздаем образ initrd ядра, который будет включать в себя модуль работы с TPM для ранней стадии загрузки системы:
    sudo dracut -f # при изменении\добавлении новых токенов снова запускать dracut не требуется
16. Перезагружаем систему:
    sudo systemctl reboot
    После этого при включении будет выполнен запрос на ввод пароля, а Clevis подставит пин разблокировки из модуля TPM

Примечания:

sudo tpm2_pcrread # Отобразить PCR значения из модуля TPM

Авторизация от TPM происходит примерно на 24 секунде, полная загрузка ОС на 34 секунде

Решение проблем:

• При сбросе BIOS или при попытке подключить другой SSD к материнке - настроки будут сбиты.
• Если подключить флешку и перезагрузиться - потребуется пароль. После отключения флешки снова загрузится стандартно.
• Для восстановления работоспособности нужно вернуть SecureBoot в режим Active (Standard) и проверить загрузку.
• Если LUKS не расшифровывается, то  удаляем существующий токен командой:
  sudo clevis luks unbind -d /dev/nvme0n1p3 -s 1 
  и затем повторяем шаги 13, 14.

Источники:

https://www.easycoding.org/2019/09/24/avtomaticheski-razblokiruem-luks-diski-pri-pomoshhi-tpm.html
https://techjungle.gitlab.io/post/binding_luks_with_tpm/
https://github.com/latchset/clevis

> $ docker inspect dbe556947aef

Такая команда выведет вс информацию в stdout

Есть другой вариант:

> $ docker inspect --format='{{json .}}'  dbe556947aef

Такой вывод будет в виде JSON, который можно обработать через jq:

> $ docker inspect --format='{{json .}}'  antipy_postgres_test | jq .Id
"dbe556947aefcc8f02e195a903a3e894a3ca532952ce373a47708b552cef7d71"

Но еще удобнее прсить запрос сразу же в команде docker inspect:

> $ docker inspect --format='{{json .Config.Labels.maintainer}}'  dbe556947aef
"PostGIS Project - https://postgis.net"

Но есть проблема, если ключ содержить побелы или точки в имени, то такой подход не сработает, например если мы попытаемся забрать значение "com.docker.compose.config-hash" из
.Config.Labels.maintainer."com.docker.compose.config-hash":

> $ docker inspect --format='{{json .Config.Labels.com.docker.compose.config-hash}}'  dbe556947aef                                                                                                                  
template parsing error: template: :1: bad character U+002D '-'

> $ docker inspect --format='{{json .Config.Labels.["com.docker.compose.config-hash"]}}'  dbe556947aef                                                                                                              
template parsing error: template: :1: bad character U+005B '['

Решение: Использовать в таких случаях index:

> $ docker inspect dbe556947aef -f '{{index .Config.Labels "com.docker.compose.config-hash"}}'                                                                                                                      
4ee3f97c83ef9c92e29b809eac2ac70aa53bbf0862c01da9c258580428aecd99

Подробнее обо всех способах вывода в Docker:

https://docs.docker.com/config/formatting/

https://docs.gitlab.com/ee/update/

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

https://docs.gitlab.com/ee/update/#upgrade-paths

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

https://gitlab-com.gitlab.io/support/toolbox/upgrade-path

но сейча снедоступна. Имеется исходный код этой утилиты для локального запуска:

https://gitlab.com/gitlab-com/support/toolbox/upgrade-path

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

Полезные команды, которые надо запускать внутри контейнера с gitlab:

Перед началом апгрейда (перед заменой образа на новый) обязательно нужно проверить не запущены ли фоновые миграции

gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigrationJob.pending.count'

Если контейнер падает с permission ошибками, следует запустить утилиту фикации:

update-permissions - обновить права на все файлы и папки, бывает полезно если по ошибке сменились права на некоторые каталоги

gitlab-ctl reconfigure - переконфигурировать гитлаб. При этом данные не удаляются, а лишь перепроверяются конфиги и считываются заново

gitlab-rake gitlab:env:info и gitlab-rake gitlab:check - проверить состояние запущенной системы

• ${var#pattern}- Удаляет наименьшую строку с левой стороны, соответствующую шаблону.
• ${var##pattern}- Удаляет самую большую строку с левой стороны, соответствующую шаблону.
• ${var%pattern}- Удаляет наименьшую строку с правой стороны, соответствующую шаблону.
• ${var%%pattern}- Удаляет самую большую строку с правой стороны, соответствующую шаблону.

Вот несколько примеров:

foo="foo-bar-foobar"
echo ${foo#*-}   # echoes 'bar-foobar'  (Removes 'foo-' because that matches '*-')
echo ${foo##*-}  # echoes 'foobar' (Removes 'foo-bar-')
echo ${foo%-*}   # echoes 'foo-bar'
echo ${foo%%-*}  # echoes 'foo'

При использовании OpenSSL нужно также создать ключи Диффи-Хеллмана, которые нужны для поддержки PFS:

openssl dhparam -out dhparams.pem 4096

Источник: https://www.8host.com/blog/sozdanie-samopodpisannogo-ssl-sertifikata-dlya-nginx-v-ubuntu-16-04/

UPD: лучше использовать вариант ниже, с автогенерацией и использованием собственного центра сертификации:

#!/bin/bash

if [ -z "$1" ]
then
  echo "Please enter domain name and ip address to create a certificate for";
  echo "e.g. domain.local 192.168.1.1"
  exit;
fi

if [ -z "$2" ]
then
  echo "Please enter domain name and ip address to create a certificate for";
  echo "e.g. domain.local 192.168.1.1"
  exit;
fi

COMMON_NAME=$1
COMMON_IP=$2

# # генерируем закрытый ключ центра сертификации
openssl genrsa -out rootCA.key 2048
# # генерируем сертификат центра сертификации
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -subj "/C=CA/ST=None/L=NB/O=None/CN=domain.local" -out rootCA.pem
# C=CA    # Country Name
# ST=None # State or Province Name (full name)
# L=NB    # Locality Name (eg, city)
# O=None  # Organization Name (eg, company)
# CN=domain.local #Common Name (e.g. server FQDN or YOUR name)


if [ -f $COMMON_NAME.key ]; then
  KEY_OPT="-key"
else
  KEY_OPT="-keyout"
fi

>$COMMON_NAME.ext cat <<-EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = $COMMON_NAME 
DNS.2 = www.$COMMON_NAME 
IP.1 = $COMMON_IP
EOF

SUBJECT="/C=RU/ST=None/L=Moscow/O=Kaspersky/CN=$COMMON_NAME"
NUM_OF_DAYS=999

# Сформируем csr файл
openssl req -new -newkey rsa:2048 -sha256 -nodes $KEY_OPT $COMMON_NAME.key -subj "$SUBJECT" -out $COMMON_NAME.csr

# Выпускаем сертификат:
openssl x509 -req -in $COMMON_NAME.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out $COMMON_NAME.crt -days $NUM_OF_DAYS -sha256 -extfile $COMMON_NAME.ext
rm $COMMON_NAME.ext

# Сконвертировать pem в pfx для Windows:
openssl pkcs12 -export -out rootCA.pfx -inkey rootCA.key -in rootCA.pem -password pass:

Для начала останавливаем сервис и сокет докера

sudo systemctl stop docker.service
sudo systemctl stop docker.socket

Создаем файл (если он еще не был создан)

sudo vim /etc/docker/daemon.json

Вносим в него такие изменения:

{
    "data-root": "/mnt/raid1/docker"
}

Теперь нужно скопировать все файлы из старого каталога в новый, с сохранением прав

sudo rsync -ahv /var/lib/docker/ /mnt/raid1/docker/

Делаем daemon-reload и запускаем docker

sudo systemctl daemon-reload
sudo systemctl restart docker

После удачного запуска проверяем фактический путь хранения данных докер на примере volume'ов:

$ docker volume ls
DRIVER    VOLUME NAME
local     0000c1c24079fb673a4572d8ddc29700fa14...
local     1ae637e8a588a87e5d57d7293d197ac9eefd...


$ docker volume inspect 0000c1c24079fb673a4572d8ddc29700fa14...
[
    {
        "CreatedAt": "2023-02-06T17:43:21+03:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/mnt/raid1/docker/volumes/0000c1c24079fb673a4572d8ddc29700fa14.../_data",
        "Name": "0000c1c24079fb673a4572d8ddc29700fa14...",
        "Options": null,
        "Scope": "local"
    }
]

Как видим Mountpoint изменился, теперь можно удалить или переименовать старую директорию хранения файлов докера

sudo rm -rf /var/lib/docker

Имеем ПК в собственной ЛВС ip_pc1 за натом, , сервер в DMZ (ip_server), ПК клиента ip_other тоже за натом.

Собственная ЛВС закрыта фаерволом, доступ можно получить только изнутри до сервера ip_server

Цель:

Получить доступ по SSH с ip_pc1 до ip_other

Процесс настройки:

На сервере ip_server создаем нового пользователя:

useradd -m -s /bin/false -g nogroup -G nogroup user

-m - Create the user's home directory if it does not exist
-s - The name of the user's login shell.
-g - The group name or number of the user's initial login group.
-G - A list of supplementary groups which the user is also a member of.

Задаем новому пользователю пароль:

sudo passwd user

Логинимся под пользователем, генерируем пару ключей

su user
cd ~
ssh-keygen

Создаем файл ~/.ssh/authorized_keys и добавляем в него следующие строки:

command="read a; exit",no-agent-forwarding,no-X11-forwarding,no-user-rc ssh-rsa <<здесь вставляем только что созданный публичный ключ>>

где:
command="read a; exit" - позволяет при поднятии соединения закрыть доступ к shell. При нажатии любой клавиши будет выполнен exit.
no-agent-forwarding,no-X11-forwarding,no-user-rc - запрещаем любые другие возможности пользователя

Закрытый ключ передаем клиенту

Клиент на своей машине подключается к нашему серверу:

sh -R 4897:localhost:22 user@server

где:
22 - порт ssh который слушает машина клиента
4897 - порт перенаправления на наш сервер, можно выбрать любой другой

На собственном пк подключаемся к серверу:

ssh -L 2222:localhost:4897 user@server

где:
2222 - порт куда мы будем коннектится по SSH
4897 - порт должен совпадать с портом перенаправления на наш сервер из прошлого шага (с него забираем туннель)

Теперь на нашем пк открываем новый терминал и можем войти на ПК клиента:

ssh -o "StrictHostKeyChecking=no" -p 2222 -i id_rsa_client another_user@localhost

Где:
-o "StrictHostKeyChecking=no" - отключает проверку публичного ключа тачки, куда мы подключаемся, т.к. это всегда будет localhost
-p 2222 принудительно указываем порт для подключения
-i id_rsa_client путь до закрытого ключа для подключения к клиенту (может отсутствовать при авторизации по паролю)
another_user@localhost - пользователь another_user должен существовать на ПК ip_other, адрес сервера localhost, т.к. подключаемся через открытый порт на своей машине.

Готово!

Посмотреть активные туннели можно командой:

sudo lsof -i -n | egrep '\<ssh\>'

Что-бы принудительно отключить сессию (и все процессы) пользователя, на сервере выполнить:

pkill -u username

ssh -o PreferredAuthentications=password username@11.22.33.44

Что-бы указать эту опцию для всех подключений пользователя, добавляем в файл

~/.ssh/config

Host *
        IdentitiesOnly=yes

Проброс портов

Пробросить все порты за сервером к себе, тем самым подняв socks proxy

ssh -D localhost:1080 remote-server-ip

Далее в firefox в разделе proxy указываем настройки:

После этого в браузере можем открывать любые веб адреса, доступные с удаленного сервера

Проброс удаленного порта к себе

Например, мы имеем удаленный сервер remote_server, у которого на 127.0.0.1:5432 запущен postgresql, мы хотим пробросить этот порт к себе для локального подключения\тестирования БД.

ssh -L 6543:127.0.0.1:5432 remote_server

После этого мы можем подключиться к порту 6543 на локальной машине и попадем на порт 5432 удаленного сервера.

Та же самая команда используется если надо добраться до третьего хоста, который доступен только за remote_server

localhost <--> remote_server <--> third_server:8080

ssh -L 8181:third_server:8080 remote_server

Теперь обратившись на 127.0.0.1:8181 мы попадем на third_server:8080

Проброс своего порта на удаленный сервер

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

ssh -R 6543:localhost:5432 remote_server

В данном примере порт 5432 с локальной машины был проброшен на порт 6543 удаленного сервера