PROM 13: Prometheus Security

Описание:

Всем привет!

Продолжаем рассказывать про дополнительные фичи prometheus и сегодня у нас на очереди всеми любимая тема безопасности! Все, что мы делали с вами до этого момента, по сути являлось разбором функциональности самого prometheus. Но внимательный слушатель не мог не заметить, что все, что мы запускаем, свободно доступно всем желающим, включая и сам prometheus, к которому вы можете подключиться в любой момент. Эту ситуацию пора исправить. Сегодня мы с вами пробежимся по базовой теоретической информации, охватывающей базовые правила настройки любых систем, а так же настроим наш prometheus для работы по tls протоколу с basic аутентификацией.

В реальной жизни пренебрежение указанными ниже правилами может привести к довольно печальным последствиям. Представьте себе ситуацию, что вы настроили prometheus, раскатали везде экспортеры и настроили alertmanager. Вроде все работает хорошо и без сбоев, но в какой-то момент, какой-то "скрипт-кидди" натыкается с помощью nmap на ваш открытый prometheus. И тут же узнает очень много детальной информации о вашей инфраструктуре. Какие сервисы где запущены, какие метрики они отдают, какие базы у вас есть и так далее. Ну а дальше все просто - берем свежие эксплойты под ваш фтп сервер, про который вы успешно забыли, но который все так же торчит в мониторинге и проникаем внутрь вашей системы. Чтобы избежать такой неприятной ситуации - лучше заранее начать соблюдать базовые гигиенические правила безопасности.

Итак, поехали!

Общая теоретическая информация

Как вы могли видеть в предыдущих примерах, мы всегда запускали экспортеры и сам prometheus в открытом режиме. И такой вариант вполне имеет право на жизнь если вы делаете это в закрытом контуре. Я вообще всем рекомендую реализовывать примерно такую схему своего проекта - у вас есть внутренняя и внешняя сеть. Через внешнюю сеть доступно только три эндпоинта - 80 порт - http, 443 порт - https и vpn. VPN может быть абсолютно любой - хоть checkpoint, хоть openvpn, хоть ipsec - не важно. Главное что извне обратиться к внутренним сервисам никак нельзя. Если вы хотите подключаться к вашим серверам по ssh - стоит сначала подключиться к vpn. Такая схема настройки позволит вам отрезать бОльшую часть атак на вашу инфраструктуру, поскольку единственной точкой входа является ваше веб приложение. А с ним возиться намного тяжелее, нежели запустить какой-нибудь эксплойт на открытый smtp. Обратите внимание, что при такой схеме работы все внутренние утилиты типа prometheus так же доступны только через vpn и подключиться к ним извне без прохождения аутентификации нет никакой возможности. Поэтому в данной ситуации вы можете спокойно не добавлять дополнительную защиту в виде логина/пароля и ssl сертификатов, поскольку трафик и так шифруется на стороне vpn.

Если же в вашей инфраструктуре нет возможности реализовать приватную сеть, ну например, когда вам выдают bare metal сервера только с одним внешним интерфейсом, то тут есть разные варианты. Первый - это построить свою приватную сеть на базе tinc (VPN), например, а дальше следовать рекомендациям из первого пункта. Второй вариант (и самый правильный) - это ввести практику настройки firewall на каждом сервере, который у вас есть. На всех наших проектах мы используем примерно такую конфигурацию iptables:

root@db01:~# cat /etc/iptables/rules.v4
# Generated by iptables-save v1.4.21 on Tue Jun 23 15:46:13 2020
*nat
:PREROUTING ACCEPT [17566285:1114295190]
:INPUT ACCEPT [8292701:445269860]
:OUTPUT ACCEPT [12857064:888777529]
:POSTROUTING ACCEPT [12857064:888777529]
COMMIT
*filter
:INPUT DROP [4:176]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67101:106192188]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT

Данная конфигурация полностью запрещает все входящие соединения (INPUT DROP), кроме тех что разрешены. А разрешаем мы только общение по loopback интерфейсу, входящие соединения на 22 порт и все соединения, которые уже установлены. Таким образом, даже если я забуду добавить правила в firewall и подниму открытый prometheus, то ничего страшного не случится - firewall по умолчанию закрывает все. И если нужно что-то разрешить - вот тогда придется лезть в конфиги. Возьмите этот пример за шаблон и используйте его на своих проектах - очень хорошее правило.

Итак, с основными моментами разобрались. Теперь все же переходим к варианту, когда у нас есть внешний интерфейс и нам нужно заходить на prometheus без vpn. Что же делать в этом случае? Тут есть несколько вариантов:

Поставить проксирующий сервер, например, nginx. Nginx будет заниматься аутентификацией - basic auth, а так же терминировать ssl соединение с действующим сертификатом (например от letsencrypt). После этого все запросы будут отправлены через proxy_pass на локальный prometheus, который будет запущен только на localhost:9090. Таким образом никто не сможет ни перехватить ваш обмен данными с prometheus, ни зайти на него.

Первый вариант был единственным до последнего времени. В 2018 году, Linux Foundation оплатила расходы на аудит безопасности prometheus и в итоге команда cure53 провела аудит и составила полный отчет о состоянии дел в prometheus, где рекомендовала добавить возможности настройки TLS и аутентификации. Что в итоге команда prometheus и сделала. Теперь можно настраивать prometheus для работы с SSL и basic auth из коробки. Именно этим мы скоро и займемся.

Собственно эти два варианта полностью закрывают нашу проблему с prometheus сервером - мы используем ssl и аутентификацию для доступа к серверу. Отлично!

Теперь пришла пора переключиться к остальным компонентам, которые у нас есть - это экспортеры. Экспортеры так же висят на каком-то порту и слушают входящие запросы. И тут возникает две проблемы:

Не все экспортеры умеют работать по SSL/TLS. Например, в node_exporter такая функциональность была добавлена не так давно.

Не все экспортеры умеют проводить аутентификацию по basic auth.

Если быть более точным, то на самом деле 99% экспортеров не реализуют данный функционал. И тем самым возлагают на нас обязанности по обеспечению своей безопасности. Как же можно решить данную задачку? Вместо реализации аутентификации нам подойдет старый добрый firewall - мы просто разрешим входящие соединения на нужный порт только prometheus серверу, а остальным запретим. А вот с ssl/tls все сложнее - по-хорошему придется ставить какой-то прокси типа nginx перед экспортерами, чтобы он терминировал на себе TLS соединение. Или же можно взять какой-нибудь stunnel. И это начинает выглядеть монстрообразно.

Если вернуться к реальной жизни, то я бы посоветовал делать так. Если у вас есть приватная сеть - используйте вариант с vpn, а prometheus будет опрашивать все экспортеры по приватной сети. Если приватной сети нет - сделайте ее с помощью tinc и так же опрашивайте экспортеры по защищенному каналу. Если ни первый ни второй вариант не подходят, то остается только настроить firewall, чтобы разрешать подключение к экспортерам с адреса prometheus сервера. Это конечно не защитит от перехвата трафика, но при этом не даст возможности запросить данные с самого экспортера. В общем смотреть и выбирать придется вам. Я естественно голосую за первый вариант с внутренней локалкой.

Настройка prometheus

Итак, с теоретической частью разобрались, давайте теперь переходить к настройке prometheus. В нашем примере мы будем использовать самоподписный сертификат. Для начала нам нужно будет сгенерировать корневой ключ и сертификат, чтобы мы могли потом выдавать сертификаты для prometheus и node_exporter. Сделать это можно с помощью утилиты openssl:

root@prom-test:/opt/prometheus# cd /opt/
root@prom-test:/opt# mkdir ssl
root@prom-test:/opt# cd ssl

root@prom-test:/opt/ssl# openssl genrsa -out ca.key 4096

Generating RSA private key, 4096 bit long modulus (2 primes)
......................................................................................................++++
.....................................................................................................................++++
e is 65537 (0x010001)

root@prom-test:/opt/ssl# openssl req -new -x509 -days 720 -key ca.key -out ca.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Moscow
Locality Name (eg, city) []:Moscow
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Rebrain
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:CA
Email Address []:[email-masked]

root@prom-test:/opt/ssl# ls -la
total 16
drwxr-xr-x 2 root root 4096 Jun 16 10:23 .
drwxr-xr-x 8 root root 4096 Jun 16 10:22 ..
-rw-r--r-- 1 root root 2151 Jun 16 10:23 ca.crt
-rw------- 1 root root 3243 Jun 16 10:22 ca.key
root@prom-test:/opt/ssl#

Здесь мы создали приватный ключ ca.key, а так же сертификат ca.crt, в который добавили общую информацию про нас. Теперь осталось сгенерировать серверный сертификат и ключ для prometheus, а затем подписать его корневым сертификатом:

root@prom-test:/opt/ssl# openssl genrsa -out server.key 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
.....................................................................................................++++
.......................................................++++
e is 65537 (0x010001)

root@prom-test:/opt/ssl# openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Moscow
Locality Name (eg, city) []:Moscow
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Rebrain
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:prom.kis.im
Email Address []:[email-masked]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

root@prom-test:/opt/ssl# openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 1 -out server.crt
Signature ok
subject=C = RU, ST = Moscow, L = Moscow, O = Rebrain, OU = IT, CN = prom.kis.im, emailAddress = [email-masked]
Getting CA Private Key
root@prom-test:/opt/ssl#

В итоге у нас должны получиться ключ server.key и сертификат server.crt:

root@prom-test:/opt/ssl# ls -la server.key
-rw------- 1 root root 3243 Jun 16 10:24 server.key
root@prom-test:/opt/ssl# ls -la server.crt
-rw-r--r-- 1 root root 1984 Jun 16 10:25 server.crt
root@prom-test:/opt/ssl#

Теперь мы можем описать настройки TLS и basic auth в файле /opt/prometheus/web.config для нашего prometheus сервера:

tls_server_config:
cert_file: /opt/ssl/server.crt
key_file: /opt/ssl/server.key

http_server_config:
http2: true

basic_auth_users:
vozerov: $2a$10$j6bz1OjUBADJ.dx5CxZGA.KVMAsNvAEEmJdrk0W1LHlxQDyqXGte.

В данном примере мы просто указали серверный ключ и сертификат, включили поддержку http2, а так же задали логин/пароль для нашего пользователя vozerov. Пароль мы получили с помощью htpasswd. Вы должны использовать шифрование bcrypt:

root@prom-test:/opt/prometheus# apt install apache2-utils
... skipped ...
root@prom-test:/opt/prometheus# htpasswd -bnBC 10 "" password | tr -d ':\n' | sed 's/$2y/$2a/'
$2a$10$j6bz1OjUBADJ.dx5CxZGA.KVMAsNvAEEmJdrk0W1LHlxQDyqXGte.

Здесь мы сгененировали хеш для пароля password. Давайте теперь назначим права нашим сертификатам, поскольку prometheus запускается из-под пользователя prometheus:

root@prom-test:/opt/prometheus# chown prometheus:prometheus /opt/ssl/server.*

Теперь добавим новый параметр для запуска (--web.config.file), где опишем наш web.config в /etc/systemd/system/prometheus.service:

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
ExecStart=/opt/prometheus/prometheus \
--config.file=/opt/prometheus/prometheus.yml \
--storage.tsdb.path=/opt/prometheus/data \
--web.console.templates=/opt/prometheus/consoles \
--web.console.libraries=/opt/prometheus/console_libraries \
--web.config.file=/opt/prometheus/web.config

[Install]
WantedBy=default.target

Теперь можно перезагружать systemd и запускать prometheus:

root@prom-test:/opt/prometheus# systemctl daemon-reload
root@prom-test:/opt/prometheus# systemctl restart prometheus
root@prom-test:/opt/prometheus# systemctl status prometheus
● prometheus.service - Prometheus
Loaded: loaded (/etc/systemd/system/prometheus.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-06-16 10:33:31 UTC; 2s ago
Main PID: 35228 (prometheus)
Tasks: 6 (limit: 2345)
Memory: 31.3M
CGroup: /system.slice/prometheus.service
└─35228 /opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/opt/prometheus/data --web.console.templates=/opt/prometheus/con>

Вроде все запустилось, давайте попробуем обратиться к prometheus:

root@prom-test:/opt/prometheus# curl -D - -u vozerov:password --cacert /opt/ssl/ca.crt --resolve prom.kis.im:9090:127.0.0.1 https://prom.kis.im:9090
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /graph
Date: Wed, 16 Jun 2021 10:36:54 GMT
Content-Length: 29

<a href="/graph">Found</a>.

Давайте разбираться с указанными параметрами. Первый параметр -D - заставит curl выводить все хедеры на экран. Второй параметр --cacert /opt/ssl/ca.crt указывает путь к нашему корневому сертификату, что позволит проверить его валидность, поскольку именно им подписан серверный сертификат prometheus. Третий параметр самый трудный - --resolve prom.kis.im:9090:127.0.0.1 - поскольку у нас нет записи в dns для prom.kis.im этим параметром мы заставляем curl определить prom.kis.im:9090 как 127.0.0.1. И поэтому когда в конце мы указываем url https://prom.kis.im:9090, curl обратиться не к dns, а сразу пойдет на 127.0.0.1:9090. Это нам требуется для того чтобы curl смог сверить имя сервера prom.kis.im в нашем серверном сертификате. Ну и собственно мы получили валидный ответ от prometheus: 302 Found.

Настройка node_exporter

Отлично, с prometheus разобрались, теперь давайте попробуем реализовать схему с tls и basic auth для node_exporter. На самом деле вы можете использовать по сути идентичный web.config и запустить node_exporter с ним - тогда он так же будет использовать протокол TLS и basic auth, но я хочу показать вам другой путь - через проксирование в nginx.

Итак, давайте для начала сгенерируем ключ и сертификат для node_exporter, по аналогии с prometheus:

root@prom-test:/opt/ssl# openssl genrsa -out node_exporter.key 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
....................................................................................++++
.....................................................................................................................................................................................................++++
e is 65537 (0x010001)

root@prom-test:/opt/ssl# cat > req.conf << EOF
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = RU
ST = Moscow
L = Moscow
O = Rebrain
OU = IT
CN = node_exporter.kis.im
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = node_exporter.kis.im
EOF

root@prom-test:/opt/ssl# openssl req -new -key node_exporter.key -out node_exporter.csr -config req.conf -extensions 'v3_req'

root@prom-test:/opt/ssl# openssl x509 -req -days 365 -in node_exporter.csr -CA ca.crt -CAkey ca.key -set_serial 1 -extensions 'v3_req' -extfile req.conf -out node_exporter.crt
Signature ok
subject=C = RU, ST = Moscow, L = Moscow, O = Rebrain, OU = IT, CN = node_exporter.kis.im, emailAddress = [email-masked]
Getting CA Private Key
root@prom-test:/opt/ssl#

После выполнения этих действий мы получим файлы node_expoter.key - ключ и node_exporter.crt - сертификат для нашего экспортера. Мы использовали конфигурацию req.conf, в которой описали все нужные нам поля, а так же дополнительные SAN имена для нашего хоста. Это важно, поскольку если сделать старый сертификат (без SAN имен), то prometheus будет ругаться примерно такой ошибкой:

Get "https://127.0.0.1:9101/metrics": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

Теперь установим nginx и составим для него конфигурацию:

root@prom-test:/opt/ssl# apt-get install nginx

Конфигурацию размещаем в /etc/sites-enabled/node_exporter.conf:

server {
listen 9101 ssl;

ssl_certificate /opt/ssl/node_exporter.crt;
ssl_certificate_key /opt/ssl/node_exporter.key;

server_name node_exporter.kis.im;

location / {
proxy_pass http://127.0.0.1:9100/;
auth_basic "Restricted!";
auth_basic_user_file .htpasswd;
}
}

Здесь все достаточно просто - мы используем сгенерированные сертификат и ключ для node_exporter'а, а так же включаем basic аутентификацию для запросов. Слушаем мы на порту 9101 с включенным ssl. Теперь можно создать файл htpasswd и перезапустить nginx:

root@prom-test:/etc/nginx/sites-enabled# htpasswd -n vozerov
New password:
Re-type new password:
vozerov:$apr1$P1sF6Xzd$4rCqbl8FN.Fk9DqmUSEeb0

root@prom-test:/etc/nginx/sites-enabled# echo 'vozerov:$apr1$P1sF6Xzd$4rCqbl8FN.Fk9DqmUSEeb0' > /etc/nginx/.htpasswd
root@prom-test:/etc/nginx/sites-enabled# /etc/init.d/nginx reload
Reloading nginx configuration (via systemctl): nginx.service.
root@prom-test:/etc/nginx/sites-enabled#

Отлично, осталось только запустить node exporter и проверить его работу:

root@prom-test:~# cd /opt/
root@prom-test:/opt# wget https://github.com/prometheus/node_exporter/releases/download/v1.1.2/node_exporter-1.1.2.linux-amd64.tar.gz

... skipped ...

root@prom-test:/opt# tar zxf node_exporter-1.1.2.linux-amd64.tar.gz

root@prom-test:/opt# ./node_exporter-1.1.2.linux-amd64/node_exporter --web.listen-address="127.0.0.1:9100"
level=info ts=2021-06-16T11:03:25.655Z caller=node_exporter.go:178 msg="Starting node_exporter" version="(version=1.1.2, branch=HEAD, revision=b597c1244d7bef49e6f3359c87a56dd7707
f6719)"
level=info ts=2021-06-16T11:03:25.656Z caller=node_exporter.go:179 msg="Build context" build_context="(go=go1.15.8, user=root@f07de8ca602a, date=20210305-09:29:10)"
level=warn ts=2021-06-16T11:03:25.656Z caller=node_exporter.go:181 msg="Node Exporter is running as root user. This exporter is designed to run as unpriviledged user, root is not
required."
level=info ts=2021-06-16T11:03:25.658Z caller=filesystem_common.go:74 collector=filesystem msg="Parsed flag --collector.filesystem.ignored-mount-points" flag=^/(dev|proc|sys|var/
lib/docker/.+)($|/)
level=info ts=2021-06-16T11:03:25.659Z caller=filesystem_common.go:76 collector=filesystem msg="Parsed flag --collector.filesystem.ignored-fs-types" flag=^(autofs|binfmt_misc|bpf
|cgroup2?|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|iso9660|mqueue|nsfs|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|selinuxfs|squashfs|sysfs|tracefs)$
level=info ts=2021-06-16T11:03:25.660Z caller=node_exporter.go:106 msg="Enabled collectors"
level=info ts=2021-06-16T11:03:25.660Z caller=node_exporter.go:113 collector=arp
level=info ts=2021-06-16T11:03:25.661Z caller=node_exporter.go:113 collector=bcache
level=info ts=2021-06-16T11:03:25.661Z caller=node_exporter.go:113 collector=bonding
level=info ts=2021-06-16T11:03:25.661Z caller=node_exporter.go:113 collector=btrfs
level=info ts=2021-06-16T11:03:25.662Z caller=node_exporter.go:113 collector=conntrack
level=info ts=2021-06-16T11:03:25.662Z caller=node_exporter.go:113 collector=cpu
level=info ts=2021-06-16T11:03:25.662Z caller=node_exporter.go:113 collector=cpufreq
level=info ts=2021-06-16T11:03:25.663Z caller=node_exporter.go:113 collector=diskstats

... skipped ...

В данном случае мы просто запустили node_exporter в tmux, хотя лучше конечно запускать его через systemd. Главное что мы добавили параметр --web.listen-address=127.0.0.1:9100, таким образом он будет слушать соединения только на loopback интерфейсе и подключиться к нему можно будет только через nginx. Давайте проверим все ли работает:

root@prom-test:/etc/nginx/sites-enabled# curl -D - -u vozerov:password --cacert /opt/ssl/ca.crt --resolve node_exporter.kis.im:9101:127.0.0.1 https://node_exporter.kis.im:9101
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 16 Jun 2021 11:05:15 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 150
Connection: keep-alive

<html>
<head><title>Node Exporter</title></head>
<body>
<h1>Node Exporter</h1>
<p><a href="/metrics">Metrics</a></p>
</body>
</html>root@prom-test:/etc/nginx/sites-enabled#

Все параметры взяты из предыдущей команды, поэтому разбирать их здесь смысла нет - единственное что мы поменяли - это имя сервера на node_exporter.kis.im, как у нас указано в сертификатах и порт 9101, на котором слушает nginx.

Супер, осталось последние действие - это подключить данный экспортер к prometheus:

global:
scrape_interval: 15s
evaluation_interval: 15s

scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']

- job_name: node-exporter
static_configs:
- targets: ['127.0.0.1:9101']
scheme: https
tls_config:
ca_file: /opt/ssl/ca.crt
server_name: node_exporter.kis.im
basic_auth:
username: vozerov
password: password

В данном случае мы определили новую задачу node-exporter, которая подключается к нашему nginx по адресу 127.0.0.1:9101 по протоколу https: scheme: https. Далее мы указываем путь к корневому сертификату, чтобы prometheus мог удостоверится что он подключился к нужному хосту, а так же имя сервера, которое мы задали в сертификате - node_exporter.kis.im. Помимо этого мы добавляем правила прохождения аутентификации - basic_auth. После такой настройки можно перезапустить prometheus и убедиться что все метрики успешно собираются.

Итоги

Итак, сегодня мы проделали с вами большой путь. В первую очередь разобрались, что для экспортеров и prometheus лучше использовать приватную сеть - так к вам точно никто не подберется. В случае если использовать VPN не представляется возможным, то мы просто закрываем все firewall'ом и настраиваем prometheus сервер на работу по tls протоколу. В случае с экспортерами придется повозиться и настроить прокси сервер, который возьмет на себя функции аутентификации и терминирования SSL. В следующем заключительном задании мы разберем небольшие лайфхаки, которые вам смогут пригодиться в реальной жизни.

Полезные ссылки:

Prometheus TLS Config

Stunnel example configuration

Prometheus security report from care53

SSL Certs with san generation

Prometheus Issue with legacy common name

Задание:

В этом задании вам потребуется установить и настроить reverse proxy на базе nginx для доступа к prometheus серверу. На подготовленной виртуальной машине уже установлен Prometheus.

Критерии оценки выполнения задания:

Сгенерируйте самоподписный сертификат (вам придется сначала сделать запрос на сертификат server.csr, а потом подписать его корневым сертификатом).

1.1. Сертификат сохранен в файл /opt/ssl/server.crt, ключ сертификата сохранен в файл /opt/ssl/server.key.

Установите и настройте nginx:

2.1. nginx должен быть установлен из официального репозитория ubuntu с помощью менеджера пакетов apt (пакет nginx)

2.2. В nginx описан виртуальный хост, который работает по протоколу tls и использует сгенерированный ранее серверный ключ и сертификат.

2.3. Виртуальный хост должен слушать порт 9191.

2.4. Виртуальный хост должен использовать basic аутентификацию с пользователем user и паролем 12345678.

2.5. Виртуальный хост должен проксировать все входящие запросы на 127.0.0.1:9090, где будет работать prometheus.

Настройте Prometheus:

3.1. Prometheus должен запускаться на 127.0.0.1:9090 и не слушать никаких других интерфейсов.