Share via

Włączanie punktu końcowego PROTOKOŁU TLS w kontenerze przyczepki

  • Artykuł

W tym artykule pokazano, jak utworzyć grupę kontenerów z kontenerem aplikacji i kontenerem przyczepki z uruchomionym dostawcą protokołu TLS/SSL. Konfigurując grupę kontenerów przy użyciu oddzielnego punktu końcowego protokołu TLS, można włączyć połączenia TLS dla aplikacji bez konieczności zmieniania kodu aplikacji.

Skonfiguruj przykładową grupę kontenerów składającą się z dwóch kontenerów:

  • Kontener aplikacji, który uruchamia prostą aplikację internetową przy użyciu publicznego obrazu aci-helloworld firmy Microsoft.
  • Kontener przyczepki z publicznym obrazem Nginx skonfigurowanym do używania protokołu TLS.

W tym przykładzie grupa kontenerów uwidacznia tylko port 443 dla serwera Nginx z publicznym adresem IP. Serwer Nginx kieruje żądania HTTPS do towarzyszącej aplikacji internetowej, która nasłuchuje wewnętrznie na porcie 80. Możesz dostosować przykład dla aplikacji kontenerów, które nasłuchują na innych portach.

Zobacz Następne kroki , aby zapoznać się z innymi metodami włączania protokołu TLS w grupie kontenerów.

Wymagania wstępne

  • Ten artykuł wymaga wersji 2.0.55 lub nowszej interfejsu wiersza polecenia platformy Azure. Jeśli korzystasz z usługi Azure Cloud Shell, najnowsza wersja jest już zainstalowana.

Tworzenie certyfikatu z podpisem własnym

Do skonfigurowania serwera Nginx jako dostawcy protokołu TLS potrzebny jest certyfikat TLS/SSL. W tym artykule pokazano, jak utworzyć i skonfigurować certyfikat TLS/SSL z podpisem własnym. W przypadku scenariuszy produkcyjnych należy uzyskać certyfikat z urzędu certyfikacji.

Aby utworzyć certyfikat TLS/SSL z podpisem własnym, użyj narzędzia OpenSSL dostępnego w usłudze Azure Cloud Shell i wielu dystrybucjach systemu Linux lub użyj porównywalnego narzędzia klienckiego w systemie operacyjnym.

Najpierw utwórz żądanie certyfikatu (plik csr) w lokalnym katalogu roboczym:

openssl req -new -newkey rsa:2048 -nodes -keyout ssl.key -out ssl.csr

Postępuj zgodnie z monitami, aby dodać informacje identyfikacyjne. W polu Nazwa pospolita wprowadź nazwę hosta skojarzona z certyfikatem. Po wyświetleniu monitu o hasło naciśnij klawisz Enter bez wpisywania, aby pominąć dodawanie hasła.

Uruchom następujące polecenie, aby utworzyć certyfikat z podpisem własnym (plik crt) z żądania certyfikatu. Przykład:

openssl x509 -req -days 365 -in ssl.csr -signkey ssl.key -out ssl.crt

W katalogu powinny być teraz widoczne trzy pliki: żądanie certyfikatu (ssl.csr), klucz prywatny (ssl.key) i certyfikat z podpisem własnym (ssl.crt). Użyj polecenia ssl.key i ssl.crt w kolejnych krokach.

Konfigurowanie serwera Nginx do używania protokołu TLS

Tworzenie pliku konfiguracji serwera Nginx

W tej sekcji utworzysz plik konfiguracji dla serwera Nginx do używania protokołu TLS. Zacznij od skopiowania następującego tekstu do nowego pliku o nazwie nginx.conf. W usłudze Azure Cloud Shell możesz użyć Visual Studio Code, aby utworzyć plik w katalogu roboczym:

code nginx.conf

W locationpliku upewnij się, że ustawiono proxy_pass prawidłowy port dla aplikacji. W tym przykładzie ustawimy port 80 dla kontenera 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;
        }
    }
}

Kodowanie wpisów tajnych i pliku konfiguracji Base64

Base64 koduje plik konfiguracji Nginx, certyfikat TLS/SSL i klucz TLS. W następnej sekcji wprowadzisz zakodowaną zawartość w pliku YAML używanym do wdrożenia grupy kontenerów.

cat nginx.conf | base64 > base64-nginx.conf
cat ssl.crt | base64 > base64-ssl.crt
cat ssl.key | base64 > base64-ssl.key

Wdrażanie grupy kontenerów

Teraz wdróż grupę kontenerów, określając konfiguracje kontenera w pliku YAML.

Tworzenie pliku YAML

Skopiuj następujący kod YAML do nowego pliku o nazwie deploy-aci.yaml. W usłudze Azure Cloud Shell możesz użyć Visual Studio Code, aby utworzyć plik w katalogu roboczym:

code deploy-aci.yaml

Wprowadź zawartość plików zakodowanych w formacie base64, gdzie wskazano w obszarze secret. Na przykład cat każdy z plików zakodowanych w formacie Base64 w celu wyświetlenia jego zawartości. Podczas wdrażania te pliki są dodawane do woluminu tajnego w grupie kontenerów. W tym przykładzie wolumin tajny jest instalowany w kontenerze 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

Wdrażanie grupy kontenerów

Utwórz grupę zasobów za pomocą polecenia az group create :

az group create --name myResourceGroup --location westus

Wdróż grupę kontenerów za pomocą polecenia az container create , przekazując plik YAML jako argument.

az container create --resource-group <myResourceGroup> --file deploy-aci.yaml

Wyświetlanie stanu wdrożenia

Aby wyświetlić stan wdrożenia, użyj następującego polecenia az container show :

az container show --resource-group <myResourceGroup> --name app-with-ssl --output table

W przypadku pomyślnego wdrożenia dane wyjściowe są podobne do następujących:

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

Weryfikowanie połączenia TLS

Użyj przeglądarki, aby przejść do publicznego adresu IP grupy kontenerów. Adres IP pokazany w tym przykładzie to 52.157.22.76, więc adres URL to https://52.157.22.76. Aby wyświetlić uruchomioną aplikację, należy użyć protokołu HTTPS ze względu na konfigurację serwera Nginx. Próby nawiązania połączenia za pośrednictwem protokołu HTTP kończą się niepowodzeniem.

Zrzut ekranu przedstawiający aplikację uruchomioną w wystąpieniu kontenera platformy Azure

Uwaga

Ponieważ w tym przykładzie użyto certyfikatu z podpisem własnym, a nie certyfikatu z urzędu certyfikacji, przeglądarka wyświetla ostrzeżenie o zabezpieczeniach podczas nawiązywania połączenia z witryną za pośrednictwem protokołu HTTPS. Może być konieczne zaakceptowanie ostrzeżenia lub dostosowanie ustawień przeglądarki lub certyfikatu, aby przejść do strony. Takie zachowanie jest oczekiwane.

Następne kroki

W tym artykule pokazano, jak skonfigurować kontener Nginx w celu włączenia połączeń TLS z aplikacją internetową działającą w grupie kontenerów. Ten przykład można dostosować dla aplikacji, które nasłuchują na portach innych niż port 80. Możesz również zaktualizować plik konfiguracji serwera Nginx, aby automatycznie przekierowywać połączenia serwera na porcie 80 (HTTP) do korzystania z protokołu HTTPS.

Chociaż w tym artykule jest używany serwer Nginx w przyczepce, możesz użyć innego dostawcy protokołu TLS, takiego jak Caddy.

Jeśli wdrożysz grupę kontenerów w sieci wirtualnej platformy Azure, możesz rozważyć inne opcje włączenia punktu końcowego TLS dla wystąpienia kontenera zaplecza, w tym: