Включение конечной точки TLS в контейнере расширения
В этой статье показано, как создать группу контейнеров с контейнером приложения и контейнером расширения, в которой работает поставщик TLS/SSL. Настроив группу контейнеров с отдельной конечной точкой TLS, вы включите TLS-подключения для своего приложения, не изменяя код приложения.
Вы настраиваете пример группы контейнеров, состоящей из двух контейнеров:
- Контейнер приложения, в котором выполняется простое веб-приложение, использующее общедоступный образ Microsoft aci-helloworld.
- Контейнер расширения, в котором выполняется общедоступный образ Nginx, настроен для использования TLS.
В этом примере группа контейнеров предоставляет только порт 443 для Nginx с его общедоступным IP-адресом. Nginx направляет запросы HTTPS в сопутствующее веб-приложение, которое ожидает передачи данных из внутреннего порта 80. Вы можете адаптировать пример для приложений контейнера, ожидающих передачи данных из других портов.
Другие подходы к включению TLS в группе контейнеров см. в разделе Дальнейшие действия.
Необходимые компоненты
Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.
Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.
Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью Azure CLI.
Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.
Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.
- Для работы с этой статьей требуется Azure CLI версии 2.0.55 или более поздней. Если вы используете Azure Cloud Shell, последняя версия уже установлена.
Создание самозаверяющего сертификата
Чтобы настроить Nginx в качестве поставщика TLS, требуется сертификат TLS/SSL. В этой статье показано, как создать и настроить самозаверяющий сертификат TLS/SSL. Для рабочих сценариев следует получить сертификат из центра сертификации.
Чтобы создать самозаверяющий сертификат TLS/SSL, используйте средство OpenSSL, доступное в Azure Cloud Shell и многих дистрибутивах Linux, или используйте сравнимое клиентское средство в вашей операционной системе.
Сначала создайте запрос на сертификат (CSR-файл) в локальном рабочем каталоге:
openssl req -new -newkey rsa:2048 -nodes -keyout ssl.key -out ssl.csr
Выполняйте подсказки, чтобы добавить идентификационную информацию. В поле "Общее имя" введите имя узла, связанное с сертификатом. При запросе пароля нажмите клавишу ВВОД без ввода текста, чтобы пропустить добавление пароля.
Выполните следующую команду, чтобы создать самозаверяющий сертификат (файл CRT) из запроса сертификата. Например:
openssl x509 -req -days 365 -in ssl.csr -signkey ssl.key -out ssl.crt
Теперь в каталоге должны отображаться три файла: запрос сертификата (ssl.csr), закрытый ключ (ssl.key) и самозаверяющий сертификат (ssl.crt). Вы будете использовать ssl.key и ssl.crt в последующих шагах.
Настройка Nginx для использования TLS
Создание файла конфигурации Nginx
В этом разделе вы создадите файл конфигурации для Nginx, чтобы использовать TLS. Для начала скопируйте следующий текст в новый файл с именем nginx.conf. В Azure Cloud Shell для создания файла в рабочей папке можно применить Visual Studio Code.
code nginx.conf
В location обязательно укажите для proxy_pass правильный порт для приложения. В этом примере мы устанавливаем порт 80 для контейнера aci-helloworld.
# nginx Configuration File
# https://wiki.nginx.org/Configuration
# Run as a less privileged user for security reasons.
user nginx;
worker_processes auto;
events {
worker_connections 1024;
}
pid /var/run/nginx.pid;
http {
#Redirect to https, using 307 instead of 301 to preserve post data
server {
listen [::]:443 ssl;
listen 443 ssl;
server_name localhost;
# Protect against the BEAST attack by not using SSLv3 at all. If you need to support older browsers (IE6) you may need to add
# SSLv3 to the list of protocols below.
ssl_protocols TLSv1.2;
# Ciphers set to best allow protection from Beast, while providing forwarding secrecy, as defined by Mozilla - https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;
ssl_prefer_server_ciphers on;
# Optimize TLS/SSL by caching session parameters for 10 minutes. This cuts down on the number of expensive TLS/SSL handshakes.
# The handshake is the most CPU-intensive operation, and by default it is re-negotiated on every new/parallel connection.
# By enabling a cache (of type "shared between all Nginx workers"), we tell the client to re-use the already negotiated state.
# Further optimization can be achieved by raising keepalive_timeout, but that shouldn't be done unless you serve primarily HTTPS.
ssl_session_cache shared:SSL:10m; # a 1mb cache can hold about 4000 sessions, so we can hold 40000 sessions
ssl_session_timeout 24h;
# Use a higher keepalive timeout to reduce the need for repeated handshakes
keepalive_timeout 300; # up from 75 secs default
# remember the certificate for a year and automatically connect to HTTPS
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains';
ssl_certificate /etc/nginx/ssl.crt;
ssl_certificate_key /etc/nginx/ssl.key;
location / {
proxy_pass http://localhost:80; # TODO: replace port if app listens on port other than 80
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
}
Кодирование секретов и файла конфигурации с помощью Base64
Кодирование файла конфигурации Nginx, сертификата TLS/SSL и ключа с помощью кодировки Base64. В следующем разделе вы вводите закодированное содержимое в файл YAML, используемый для развертывания группы контейнеров.
cat nginx.conf | base64 > base64-nginx.conf
cat ssl.crt | base64 > base64-ssl.crt
cat ssl.key | base64 > base64-ssl.key
Развертывание группы контейнеров
Теперь разверните группу контейнеров, указав конфигурации контейнеров в файле YAML.
Создание YAML-файла
Скопируйте следующий код YAML в файл с именем deploy-aci.yaml. В Azure Cloud Shell для создания файла в рабочей папке можно применить Visual Studio Code.
code deploy-aci.yaml
Введите содержимое файлов в кодировке Base64, как указано в разделе secret. Например, для cat каждый из файлов в кодировке Base64 для просмотра его содержимого. Во время развертывания эти файлы добавляются в секретный том в группе контейнеров. В этом примере секретный том подключается к контейнеру Nginx.
api-version: 2019-12-01
location: westus
name: app-with-ssl
properties:
containers:
- name: nginx-with-ssl
properties:
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
ports:
- port: 443
protocol: TCP
resources:
requests:
cpu: 1.0
memoryInGB: 1.5
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx
- name: my-app
properties:
image: mcr.microsoft.com/azuredocs/aci-helloworld
ports:
- port: 80
protocol: TCP
resources:
requests:
cpu: 1.0
memoryInGB: 1.5
volumes:
- secret:
ssl.crt: <Enter contents of base64-ssl.crt here>
ssl.key: <Enter contents of base64-ssl.key here>
nginx.conf: <Enter contents of base64-nginx.conf here>
name: nginx-config
ipAddress:
ports:
- port: 443
protocol: TCP
type: Public
osType: Linux
tags: null
type: Microsoft.ContainerInstance/containerGroups
Развертывание группы контейнеров
Создайте группу ресурсов с помощью команды az group create.
az group create --name myResourceGroup --location westus
Разверните группу контейнеров с помощью команды az container create, передав YAML-файл как аргумент.
az container create --resource-group <myResourceGroup> --file deploy-aci.yaml
Просмотр состояния развертывания
Чтобы просмотреть состояние развертывания, используйте следующую команду az container show.
az container show --resource-group <myResourceGroup> --name app-with-ssl --output table
При успешном развертывании выходные данные будут похожи на следующие:
Name ResourceGroup Status Image IP:ports Network CPU/Memory OsType Location
------------ --------------- -------- ------------------------------------------------------- ------------------- --------- --------------- -------- ----------
app-with-ssl myresourcegroup Running nginx, mcr.microsoft.com/azuredocs/aci-helloworld 52.157.22.76:443 Public 1.0 core/1.5 gb Linux westus
Проверка подключения по протоколу TLS
В браузере перейдите по общедоступному IP-адресу группы контейнеров. IP-адрес, показанный в этом примере, — это 52.157.22.76, поэтому URL-адрес имеет значение https://52.157.22.76. Для просмотра работающего приложения необходимо использовать протокол HTTPS из-за конфигурации сервера Nginx. Сбой при попытке подключения по протоколу HTTP.
Примечание.
Так как в этом примере используется самозаверяющий сертификат, а не сертификат из центра сертификации, браузер отображает предупреждение системы безопасности при подключении к сайту по протоколу HTTPS. Может потребоваться принять предупреждение или настроить параметры браузера или сертификата, чтобы перейти к странице. Это поведение является ожидаемым.
Следующие шаги
В этой статье мы рассмотрели, как настроить контейнер Nginx для включения TLS-подключений к веб приложению, работающему в группе контейнеров. Этот пример можно адаптировать для приложений, ожидающих передачи данных из портов, отличных от порта 80. Кроме того, можно изменить файл конфигурации Nginx таким образом, чтобы автоматически перенаправлять серверные подключения к порту 80 (HTTP) для использования протокола HTTPS.
Хотя в этой статье используется Nginx в расширении, можно использовать другой поставщик TLS, например Caddy.
При развертывании группы контейнеров в виртуальной сети Azure можно рассмотреть другие варианты для включения конечной точки TLS для экземпляра контейнера на стороне сервера, в том числе: