Udostępnij przez


Kontrola dostępu (Ingress) w usłudze Azure Container Apps

Usługa Azure Container Apps umożliwia uwidocznienie aplikacji kontenera w publicznej sieci Web, sieci wirtualnej i innych aplikacji kontenerów w środowisku przez włączenie ruchu przychodzącego. Ustawienia Ingress są egzekwowane za pomocą zestawu reguł kontrolujących routing ruchu zewnętrznego i wewnętrznego do aplikacji kontenerowej. Po włączeniu mechanizmu ingressnie musisz tworzyć ani usługi Azure Load Balancer, ani publicznego adresu IP, ani innych zasobów platformy Azure w celu obsługi przychodzących żądań HTTP lub ruchu TCP (Transmission Control Protocol).

Obsługa ruchu przychodzącego:

Przykładowa konfiguracja wejścia przedstawiająca podział ruchu między dwie wersje.

Diagram przedstawiający konfigurację wejściową dzielącą ruch między dwie wersje.

Aby uzyskać szczegółowe informacje o konfiguracji, zobacz Konfigurowanie ruchu przychodzącego.

Dostęp zewnętrzny i wewnętrzny

Po włączeniu ruchu przychodzącego można wybrać między dwoma typami ruchu przychodzącego:

  • Zewnętrzne: akceptuje ruch zarówno z publicznego Internetu, jak i środowiska wewnętrznego aplikacji kontenera.
  • Wewnętrzne: zezwala tylko na dostęp wewnętrzny z poziomu środowiska aplikacji kontenera.

Każda aplikacja kontenerowa w środowisku może być skonfigurowana z użyciem różnych ustawień dostępu. Na przykład w scenariuszu z wieloma aplikacjami mikrousług w celu zwiększenia bezpieczeństwa może istnieć jedna aplikacja kontenera, która odbiera żądania publiczne i przekazuje żądania do usługi w tle. W tym scenariuszu skonfigurujesz publiczną aplikację kontenerową z zewnętrznym wejściem i wewnętrzną aplikację kontenerową z wewnętrznym wejściem.

Typy protokołów

Usługa Container Apps obsługuje dwa protokoły dla ruchu przychodzącego: HTTP i TCP.

HTTP

Po włączeniu ruchu przychodzącego HTTP aplikacja kontenerowa ma:

  • Obsługa terminacji protokołu TLS (Transport Layer Security)
  • Obsługa protokołów HTTP/1.1 i HTTP/2
  • Obsługa protokołu WebSocket i gRPC
  • Punkty końcowe HTTPS, które zawsze używają protokołu TLS 1.2 lub 1.3, zakończone w punkcie wejściowym
  • Punkty końcowe, które uwidaczniają porty 80 (dla protokołu HTTP) i 443 (dla protokołu HTTPS)
    • Domyślnie żądania HTTP do portu 80 są automatycznie przekierowywane do protokołu HTTPS na 443
  • W pełni kwalifikowana nazwa domeny (FQDN)
  • Limit czasu żądania wynosi 240 sekund

Nagłówki HTTP

Wejście HTTP dodaje nagłówki w celu przekazywania metadanych dotyczących żądania klienta do aplikacji kontenerowej. Na przykład X-Forwarded-Proto nagłówek służy do identyfikowania protokołu używanego przez klienta do nawiązywania połączenia z usługą Container Apps. W poniższej tabeli wymieniono nagłówki HTTP, które są istotne dla wejścia w aplikacjach kontenerowych.

Nagłówek opis Wartości
X-Forwarded-Proto Protokół używany przez klienta do nawiązywania połączenia z usługą Container Apps. http lub https. Wartość ta jest nadpisywana, jeśli zostanie wysłana przez klienta.
X-Forwarded-For Adresy IP klienta i/lub pośrednie serwery proxy, które wysłały żądanie. Adresy IP nadawców. Jeśli zostało określone w początkowym żądaniu, zostaje to dodane. Tylko najbardziej odpowiedni adres IP jest udostępniany przez usługę Azure Container Apps. Wszelkie inne wartości muszą być weryfikowane przez użytkownika, aby zapobiec fałszowaniu adresów IP.
X-Forwarded-Client-Cert Certyfikat klienta, jeśli clientCertificateMode został ustawiony. Rozdzielana średnikami lista skrótów, certyfikatów i łańcuchów. Na przykład: Hash=....;Cert="...";Chain="...";. Wartość ta jest nadpisywana, jeśli zostanie wysłana przez klienta.

TCP

Usługa Container Apps obsługuje protokoły oparte na protokole TCP inne niż HTTP lub HTTPS. Na przykład możesz użyć ruchu przychodzącego TCP, aby uwidocznić aplikację kontenera korzystającą z protokołu Redis.

Uwaga

Zewnętrzny ingres TCP jest obsługiwany tylko w środowiskach usługi Container Apps korzystających z sieci wirtualnej.

Po włączeniu wejściowego TCP, Twoja aplikacja kontenera:

  • Jest dostępny dla innych aplikacji kontenerów w tym samym środowisku za pośrednictwem jego nazwy (zdefiniowanej name przez właściwość w zasobie usługi Container Apps) i uwidocznionego numeru portu.
  • Jest dostępny zewnętrznie za pośrednictwem w pełni kwalifikowanej nazwy domeny (FQDN) oraz odsłoniętego numeru portu, jeśli ustawiono wartość external dla ruchu przychodzącego.

Dodatkowe porty TCP

Oprócz głównego portu HTTP/TCP dla aplikacji kontenera można uwidocznić dodatkowe porty TCP, aby umożliwić aplikacjom akceptowanie połączeń TCP na wielu portach.

Uwaga

Aby korzystać z tej funkcji, musisz mieć rozszerzenie interfejsu wiersza polecenia aplikacji kontenera. Uruchom polecenie az extension add -n containerapp , aby zainstalować najnowszą wersję rozszerzenia interfejsu wiersza polecenia aplikacji kontenera.

Następujące elementy dotyczą dodatkowych portów TCP:

  • Więcej portów TCP może być zewnętrznych tylko wtedy, gdy sama aplikacja jest ustawiona jako zewnętrzna, a aplikacja kontenera korzysta z sieci wirtualnej.

  • Wszystkie zewnętrznie uwidocznione dodatkowe porty TCP muszą być unikatowe w całym środowisku usługi Container Apps. Obejmuje to wszystkie zewnętrzne dodatkowe porty TCP, zewnętrzne główne porty TCP i porty 80/443 używane przez wbudowany ruch przychodzący HTTP. Jeśli dodatkowe porty są wewnętrzne, możesz współużytkować ten sam port w wielu aplikacjach.

  • Jeśli nie podano uwidocznionego portu, uwidoczniony port jest domyślnie zgodny z portem docelowym.

  • Każdy port docelowy musi być unikatowy, a ten sam port docelowy nie może być udostępniony na różnych portach udostępnionych.

  • Istnieje maksymalnie pięć dodatkowych portów na aplikację. Jeśli wymagane są dodatkowe porty, otwórz wniosek o pomoc techniczną.

  • Tylko główny port przychodzący obsługuje wbudowane funkcje HTTP, takie jak CORS i koligacja sesji. W przypadku uruchamiania protokołu HTTP na dodatkowych portach TCP te wbudowane funkcje nie są obsługiwane.

  • Liczba portu 36985 jest zarezerwowana do wewnętrznych kontroli kondycji systemu i nie jest dostępna dla aplikacji TCP ani dodatkowych udostępnionych portów w aplikacjach HTTP.

Aby uzyskać więcej informacji na temat włączania dodatkowych portów, zobacz Konfigurowanie ruchu przychodzącego dla aplikacji.

Nazwy domen

Dostęp do aplikacji można uzyskać w następujący sposób:

  • Domyślna w pełni kwalifikowana nazwa domeny (FQDN): Każda aplikacja w środowisku Container Apps jest automatycznie przypisywana w pełni kwalifikowana nazwa domeny FQDN na podstawie sufiksu DNS (systemu nazw domen). Ten sufiks jest określany przez zmienną środowiskowąCONTAINER_APP_ENV_DNS_SUFFIX. Aby dostosować sufiks DNS środowiska, zobacz Niestandardowy sufiks DNS środowiska.

  • Niestandardowa nazwa domeny: możesz skonfigurować niestandardową domenę DNS dla środowiska usługi Container Apps. Aby uzyskać więcej informacji, zobacz Niestandardowe nazwy domen i certyfikaty.

  • Nazwa aplikacji: możesz użyć nazwy aplikacji do komunikacji między aplikacjami w tym samym środowisku.

Aby uzyskać nazwę FQDN aplikacji, zobacz Lokalizacja.

Ograniczenia adresów IP

Usługa Container Apps obsługuje ograniczenia adresów IP dla ruchu przychodzącego. Możesz utworzyć reguły, aby skonfigurować adresy IP, które są dozwolone lub blokowane przed dostępem do aplikacji kontenera. Aby uzyskać więcej informacji, zobacz Konfigurowanie ograniczeń adresów IP.

Uwierzytelnianie

Usługa Azure Container Apps udostępnia wbudowane funkcje uwierzytelniania i autoryzacji w celu zabezpieczenia zewnętrznej aplikacji kontenera z obsługą ruchu przychodzącego. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie i autoryzacja w usłudze Azure Container Apps.

Aplikację można skonfigurować tak, aby obsługiwała certyfikaty klienta (mTLS) na potrzeby uwierzytelniania i szyfrowania ruchu. Aby uzyskać więcej informacji, zobacz Konfigurowanie certyfikatów klienta.

Aby uzyskać szczegółowe informacje na temat korzystania z szyfrowania sieci na poziomie P2P, zobacz konfiguracja sieci.

Dzielenie ruchu

Usługa Containers Apps umożliwia podzielenie ruchu przychodzącego między aktywne wersje aplikacji. Podczas definiowania reguły dzielenia przypisuje się procent ruchu przychodzącego do różnych wersji. Aby uzyskać więcej informacji, zobacz Podział ruchu.

Wiązanie sesji

Koligacja sesji, znana również jako sesje sticky, to funkcja, która umożliwia kierowanie wszystkich żądań HTTP od klienta do tej samej repliki aplikacji kontenera. Ta funkcja jest przydatna w przypadku aplikacji stanowych, które wymagają stałego połączenia z tą samą repliką. Aby uzyskać więcej informacji, zobacz Afinitet sesji.

Udostępnianie zasobów pochodzących z różnych źródeł (CORS)

Domyślnie wszystkie żądania wysyłane za pośrednictwem przeglądarki ze strony do domeny, która nie jest zgodna z domeną pochodzenia strony, są blokowane. Aby uniknąć tego ograniczenia dla usług wdrożonych w usłudze Container Apps, możesz włączyć współużytkowanie zasobów między źródłami (CORS).

Aby uzyskać więcej informacji, zobacz Konfigurowanie mechanizmu CORS w usłudze Azure Container Apps.

Następne kroki