Een TLS-eindpunt inschakelen in een sidecar-container
In dit artikel wordt beschreven hoe u een containergroep maakt met een toepassingscontainer en een sidecarcontainer waarop een TLS/SSL-provider wordt uitgevoerd. Door een containergroep in te stellen met een afzonderlijk TLS-eindpunt, schakelt u TLS-verbindingen voor uw toepassing in zonder de toepassingscode te wijzigen.
U stelt een voorbeeldcontainergroep in die bestaat uit twee containers:
- Een toepassingscontainer die een eenvoudige web-app uitvoert met behulp van de openbare Installatiekopie van Microsoft aci-helloworld.
- Een sidecar-container met de openbare Nginx-installatiekopieën die zijn geconfigureerd voor het gebruik van TLS.
In dit voorbeeld maakt de containergroep alleen poort 443 voor Nginx beschikbaar met het openbare IP-adres. Nginx stuurt HTTPS-aanvragen naar de bijbehorende web-app, die intern luistert op poort 80. U kunt het voorbeeld aanpassen voor containertoepassingen die luisteren op andere poorten.
Zie Volgende stappen voor andere benaderingen voor het inschakelen van TLS in een containergroep.
Vereisten
Gebruik de Bash-omgeving in Azure Cloud Shell. Zie quickstart voor Bash in Azure Cloud Shell voor meer informatie.
Installeer de Azure CLI, indien gewenst, om CLI-referentieopdrachten uit te voeren. Als u in Windows of macOS werkt, kunt u Azure CLI uitvoeren in een Docker-container. Zie De Azure CLI uitvoeren in een Docker-container voor meer informatie.
Als u een lokale installatie gebruikt, meldt u zich aan bij Azure CLI met behulp van de opdracht az login. Volg de stappen die worden weergegeven in de terminal, om het verificatieproces te voltooien. Raadpleeg Aanmelden bij Azure CLI voor aanvullende aanmeldingsopties.
Installeer de Azure CLI-extensie bij het eerste gebruik, wanneer u hierom wordt gevraagd. Raadpleeg Extensies gebruiken met Azure CLI voor meer informatie over extensies.
Voer az version uit om de geïnstalleerde versie en afhankelijke bibliotheken te vinden. Voer az upgrade uit om te upgraden naar de nieuwste versie.
- Voor dit artikel is versie 2.0.55 of hoger van de Azure CLI vereist. Als u Azure Cloud Shell gebruikt, is de nieuwste versie al geïnstalleerd.
Een zelfondertekend certificaat maken
Als u Nginx wilt instellen als een TLS-provider, hebt u een TLS/SSL-certificaat nodig. In dit artikel wordt beschreven hoe u een zelfondertekend TLS/SSL-certificaat maakt en instelt. Voor productiescenario's moet u een certificaat van een certificeringsinstantie verkrijgen.
Als u een zelfondertekend TLS/SSL-certificaat wilt maken, gebruikt u het OpenSSL-hulpprogramma dat beschikbaar is in Azure Cloud Shell en veel Linux-distributies, of gebruikt u een vergelijkbaar clienthulpprogramma in uw besturingssysteem.
Maak eerst een certificaataanvraag (.csr bestand) in een lokale werkmap:
openssl req -new -newkey rsa:2048 -nodes -keyout ssl.key -out ssl.csr
Volg de aanwijzingen om de identificatiegegevens toe te voegen. Voer bij Algemene naam de hostnaam in die is gekoppeld aan het certificaat. Wanneer u wordt gevraagd om een wachtwoord, drukt u op Enter zonder te typen om het toevoegen van een wachtwoord over te slaan.
Voer de volgende opdracht uit om het zelfondertekende certificaat (.crt-bestand) te maken vanuit de certificaataanvraag. Voorbeeld:
openssl x509 -req -days 365 -in ssl.csr -signkey ssl.key -out ssl.crt
U ziet nu drie bestanden in de map: de certificaataanvraag (ssl.csr
), de persoonlijke sleutel (ssl.key
) en het zelfondertekende certificaat (ssl.crt
). U gebruikt ssl.key
en ssl.crt
in latere stappen.
Nginx configureren voor het gebruik van TLS
Nginx-configuratiebestand maken
In deze sectie maakt u een configuratiebestand voor Nginx om TLS te gebruiken. Kopieer eerst de volgende tekst naar een nieuw bestand met de naam nginx.conf
. In Azure Cloud Shell kunt u Visual Studio Code gebruiken om het bestand in uw werkmap te maken:
code nginx.conf
Zorg location
ervoor dat u de juiste poort voor uw app instelt proxy_pass
. In dit voorbeeld stellen we poort 80 in voor de aci-helloworld
container.
# 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;
}
}
}
Geheimen en configuratiebestand met Base64-codering
Base64-codeer het Nginx-configuratiebestand, het TLS/SSL-certificaat en de TLS-sleutel. In de volgende sectie voert u de gecodeerde inhoud in een YAML-bestand in dat wordt gebruikt om de containergroep te implementeren.
cat nginx.conf | base64 > base64-nginx.conf
cat ssl.crt | base64 > base64-ssl.crt
cat ssl.key | base64 > base64-ssl.key
Containergroep implementeren
Implementeer nu de containergroep door de containerconfiguraties op te geven in een YAML-bestand.
YAML-bestand maken
Kopieer de volgende YAML naar een nieuw bestand met de naam deploy-aci.yaml
. In Azure Cloud Shell kunt u Visual Studio Code gebruiken om het bestand in uw werkmap te maken:
code deploy-aci.yaml
Voer de inhoud van de base64-gecodeerde bestanden in, waaronder secret
wordt aangegeven. Bijvoorbeeld cat
, elk van de base64-gecodeerde bestanden om de inhoud ervan te zien. Tijdens de implementatie worden deze bestanden toegevoegd aan een geheim volume in de containergroep. In dit voorbeeld wordt het geheime volume gekoppeld aan de Nginx-container.
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
De containergroep implementeren
Maak een resourcegroep met de opdracht az group create :
az group create --name myResourceGroup --location westus
Implementeer de containergroep met de opdracht az container create , waarbij het YAML-bestand als argument wordt doorgegeven.
az container create --resource-group <myResourceGroup> --file deploy-aci.yaml
Implementatiestatus weergeven
Gebruik de volgende opdracht az container show om de status van de implementatie weer te geven:
az container show --resource-group <myResourceGroup> --name app-with-ssl --output table
Voor een geslaagde implementatie ziet de uitvoer er ongeveer als volgt uit:
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-verbinding controleren
Gebruik uw browser om naar het openbare IP-adres van de containergroep te navigeren. Het IP-adres dat in dit voorbeeld wordt weergegeven, is 52.157.22.76
dus de URL https://52.157.22.76. U moet HTTPS gebruiken om de actieve toepassing te zien vanwege de Nginx-serverconfiguratie. Pogingen om verbinding te maken via HTTP-failover.
Notitie
Omdat in dit voorbeeld een zelfondertekend certificaat wordt gebruikt en niet een certificaat van een certificeringsinstantie, wordt in de browser een beveiligingswaarschuwing weergegeven bij het maken van verbinding met de site via HTTPS. Mogelijk moet u de waarschuwing accepteren of browser- of certificaatinstellingen aanpassen om door te gaan naar de pagina. Dit gedrag is verwacht.
Volgende stappen
In dit artikel hebt u gezien hoe u een Nginx-container instelt om TLS-verbindingen met een web-app in te schakelen die wordt uitgevoerd in de containergroep. U kunt dit voorbeeld aanpassen voor apps die luisteren op andere poorten dan poort 80. U kunt ook het Nginx-configuratiebestand bijwerken om serververbindingen automatisch om te leiden op poort 80 (HTTP) om HTTPS te gebruiken.
Hoewel in dit artikel Nginx in de sidecar wordt gebruikt, kunt u een andere TLS-provider gebruiken, zoals Caddy.
Als u uw containergroep in een virtueel Azure-netwerk implementeert, kunt u andere opties overwegen om een TLS-eindpunt in te schakelen voor een back-endcontainerinstantie, waaronder:
- Azure Functions-proxy's
- Azure API Management
- Azure-toepassing Gateway: bekijk een voorbeeldimplementatiesjabloon.