Kubernetes에서 셀프서비스 DNS 및 인증서 관리 활성화

NGINX | 2022년 11월 01일
Jason Schmidt
Jason Schmidt

애플리케이션 개발의 궁극적인 목표는 물론 앱을 인터넷에 공개하는 것입니다. Kubernetes는 애플리케이션으로 요청을 라우팅하는 메커니즘으로 Ingress 컨트롤러를 제공하여 개발자가 이 과정을 어느 정도 간소화할 수 있도록 합니다. 하지만 모든 작업을 원하는 만큼 셀프서비스 방식으로 처리할 수 있는 것은 아닙니다. 앱의 도메인 이름을 Ingress 컨트롤러의 IP 주소에 매핑하려면 DNS(Domain Name System) 레코드가 필요하고, HTTPS를 사용해 연결을 보호하려면 TLS 인증서도 필요합니다. 대부분의 조직에서는 개발자가 DNS나 TLS를 직접 관리하지 않으므로 이를 담당하는 운영 그룹과 협의해야 합니다.

운영자라고 해서 반드시 더 쉬운 것은 아닙니다. 대부분의 조직에서는 DNS 레코드를 업데이트할 일이 드물기 때문에 비즈니스 규칙과 실제 기술적 절차가 제대로 마련되어 있지 않거나 아예 없는 경우가 많습니다. 따라서 DNS 레코드를 추가해야 할 때는 먼저 관련 문서를 찾거나 동료에게 물어봐야 하며, 최악의 경우에는 직접 방법을 알아내야 합니다. 또한 모든 기업 보안 규칙을 준수하는지 확인하고, 방화벽에서 인그레스를 올바르게 식별할 수 있도록 적절한 태그가 지정되어 있는지도 확인해야 합니다.

다행히 개발자와 운영자 모두의 업무를 더 수월하게 만드는 방법이 있습니다. 이 글에서는 운영자가 Kubernetes 배포를 구성하여 개발자가 Kubernetes 환경에서 DNS 레코드를 업데이트하고 TLS 인증서를 생성할 수 있도록 셀프서비스 기능을 제공하는 방법을 설명합니다. 인프라를 미리 구축해 두면 필요한 모든 비즈니스 및 기술 요구 사항이 충족되도록 보장할 수 있습니다.

개요 및 사전 요구 사항

솔루션을 구축한 후 개발자가 애플리케이션을 인터넷에 공개하려면, Kubernetes 설치 환경에서 관리하는 도메인 내의 정규화된 도메인 이름(FQDN)이 포함된 제공 템플릿에 따라 Ingress 컨트롤러를 생성하기만 하면 됩니다. Kubernetes는 이 템플릿을 사용하여 Ingress 컨트롤러에 IP 주소를 할당하고, FQDN을 IP 주소에 매핑하는 DNS A 레코드를 생성하며, FQDN용 TLS 인증서를 생성하여 Ingress 컨트롤러에 추가합니다. 정리도 매우 간단합니다. Ingress를 제거하면 DNS 레코드도 정리됩니다.

이 솔루션은 다음 기술을 활용합니다(설치 및 구성 지침은 아래에서 제공합니다).

솔루션을 구성하기 전에 다음이 필요합니다:

  • 송신 트래픽용 LoadBalancer 객체가 있는 Kubernetes 클라우드 설치 환경. 이 솔루션에서는 Linode를 사용하지만 다른 클라우드 제공업체도 사용할 수 있습니다.
  • 다음에서 호스팅되는 도메인 이름: Cloudflare. Cloudflare를 선택한 이유는 cert-manager에서 지원하는 DNS 제공업체 중 하나이며 ExternalDNS를 지원하기 때문입니다(이 글을 작성하는 시점에는 베타 버전). 이 도메인은 프로덕션이나 기타 중요한 용도로 사용하지 않는 것이 좋습니다.
  • 무료 요금제에 포함된 Cloudflare API 액세스 권한.
  • Helm을 사용하여 Kubernetes를 설치하고 배포합니다.
  • kubectl을 Kubernetes용 명령줄 인터페이스로 사용합니다.
  • 선택적으로 K9s, Kubernetes와 더욱 체계적으로 상호 작용할 수 있도록 잘 설계된 텍스트 사용자 인터페이스(TUI)입니다.

또한 Kubernetes에 대한 기본적인 이해(매니페스트를 적용하고, Helm 차트를 사용하며, 출력을 확인하고 문제를 해결하기 위해 kubectl 명령을 실행하는 방법)가 있다고 가정합니다. Let’s Encrypt의 기본 개념을 이해하면 도움이 되지만 필수는 아닙니다. 개요는 블로그를 참조하세요. cert-manager의 작동 방식을 알 필요도 없지만, cert-manager와 인증서 전반이 NGINX Ingress Controller에서 어떻게 작동하는지 궁금하다면 최근에 작성한 Kubernetes 환경에서 인증서 관리 자동화 게시물을 참조하세요.

이 솔루션은 macOS와 Linux에서 모두 테스트했습니다. Windows Subsystem for Linux 버전 2(WSL2)에서는 테스트하지 않았지만, 별다른 문제는 없을 것으로 예상합니다.

참고: 이 솔루션은 개념 증명을 위한 예시로 제공되며 프로덕션 환경에서 사용하기 위한 것이 아닙니다. 특히 운영 및 보안에 관한 모든 모범 사례가 적용되어 있지는 않습니다. 이러한 주제에 관한 자세한 내용은 cert-manager 및 ExternalDNS 설명서를 참조하세요.

솔루션 배포

솔루션을 배포하려면 다음 섹션의 단계를 따르세요:

소프트웨어 다운로드

  1. Download your Cloudflare API 토큰을 다운로드합니다.
  2. NGINX Ingress Controller 리포지토리를 복제합니다:
$ git clone https://github.com/nginxinc/kubernetes-ingress.gitCloning into 'kubernetes-ingress'...
remote: Enumerating objects: 45176, done.
remote: Counting objects: 100% (373/373), done.
remote: Compressing objects: 100% (274/274), done.
remote: Total 45176 (delta 173), reused 219 (delta 79), pack-reused 44803
Receiving objects: 100% (45176/45176), 60.45 MiB | 26.81 MiB/s, done.
Resolving deltas: 100% (26592/26592), done.
  1. Kubernetes 클러스터에 연결할 수 있는지 확인합니다.
$ kubectl cluster-infoKubernetes control plane is running at https://ba35bacf-b072-4600-9a04-e04...6a3d.us-west-2.linodelke.net:443
KubeDNS is running at https://ba35bacf-b072-4600-9a04-e04...6a3d.us-west-2.linodelke.net:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
 
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

NGINX Ingress Controller 배포

  1. Helm을 사용하여 NGINX Ingress Controller를 배포합니다. 여기서는 세 가지 비표준 구성 옵션을 추가한다는 점에 유의하세요:
$ helm install nginx-kic nginx-stable/nginx-ingress --namespace nginx-ingress --set controller.enableCustomResources=true --create-namespace --set controller.enableCertManager=true --set controller.enableExternalDNS=trueNAME: nginx-kic
LAST DEPLOYED: Day Mon DD hh:mm:ss YYYY
NAMESPACE: nginx-ingress
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The NGINX Ingress Controller has been installed.
  • controller.enableCustomResources – NGINX VirtualServer 및 VirtualServerRoute 사용자 지정 리소스를 생성하는 데 사용되는 사용자 지정 리소스 정의(CRD)를 설치하도록 Helm에 지시합니다.
  • controller.enableCertManager – NGINX Ingress Controller가 cert-manager 구성 요소와 통신하도록 구성합니다.
  • controller.enableExternalDNS – Ingress Controller가 ExternalDNS 구성 요소와 통신하도록 구성합니다.
  1. NGINX Ingress Controller가 실행 중인지 확인하고 EXTERNAL-IP 필드의 값을 기록합니다. 이 값은 NGINX Ingress Controller의 IP 주소입니다(여기서는 www.xxx.yyy.zzz). 가독성을 위해 출력은 두 줄로 나누어 표시했습니다.
$ kubectl get services --namespace nginx-ingressNAME                      TYPE           CLUSTER-IP      ...
nginx-kic-nginx-ingress   LoadBalancer   10.128.152.88   ... 

   ... EXTERNAL-IP       PORT(S)                      AGE
   ... www.xxx.yyy.zzz   80:32457/TCP,443:31971/TCP   3h8m

cert-manager 배포

이 솔루션에서 cert-manager는 TLS 인증서를 발급받을 때 DNS-01 챌린지 유형을 사용하며, 이를 위해 ClusterIssuer 리소스를 생성할 때 Cloudflare API 토큰을 제공해야 합니다. 이 솔루션에서는 API 토큰을 Kubernetes Secret으로 제공합니다.

  1. Helm을 사용하여 cert-manager를 배포:
$ helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.9.1 --set installCRDs=trueNAME: cert-manager
LAST DEPLOYED: Day Mon DD hh:mm:ss YYYY
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager v1.9.1 has been deployed successfully!
  1. Cloudflare API 토큰을 Kubernetes Secret으로 배포하고, 다음 값을 <your-API-token>:
$ kubectl apply -f - <<EOFapiVersion: v1 kind: Secret metadata: name: Cloudflare-api-token-secret namespace: cert-manager type: Opaque stringData: api-token: "<your-API-token>" EOF
secret/Cloudflare-api-token-secret created
  1. 토큰을 가져올 위치로 Cloudflare-api-token-secret(이전 단계에서 정의함)을 지정하여 ClusterIssuer 객체를 생성합니다. 원하는 경우 example-issuer를 metadata.name 필드에서 다른 이름으로 바꾸고, example-issuer-account-key를 spec.acme.privateKeySecretRef.name 필드에서 다른 이름으로 바꿀 수 있습니다.
$ kubectl apply -f - <<EOFapiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: example-issuer namespace: cert-manager spec: acme: email: example@example.com server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: example-issuer-account-key solvers: - dns01: Cloudflare: apiTokenSecretRef: name: Cloudflare-api-token-secret key: api-token EOF
clusterissuer.cert-manager.io/example-issuer created
  1. ClusterIssuer가 배포되어 준비되었는지 확인합니다(READY 필드의 값이 True인지 확인).
$ kubectl get clusterissuerNAME             READY   AGE
example-issuer   True    3h9m

ExternalDNS 배포

cert-manager와 마찬가지로 ExternalDNS 프로젝트에서 DNS를 관리하려면 Cloudflare API 토큰이 필요합니다. 두 프로젝트에 동일한 토큰을 사용할 수 있지만, 반드시 그래야 하는 것은 아닙니다.

  1. 프로젝트 간 통합을 활성화하려면 NGINX Ingress Controller용 ExternalDNS CRD를 생성합니다.
$ kubectl create -f ./kubernetes-ingress/deployments/common/crds/externaldns.nginx.org_dnsendpoints.yamlcustomresourcedefinition.apiextensions.k8s.io/dnsendpoints.externaldns.nginx.org created
  1. 외부 DNS 서비스를 생성합니다(external-dns). 매니페스트가 상당히 길기 때문에 여기서는 두 부분으로 나눕니다. 첫 번째 부분에서는 계정, 역할 및 권한을 구성합니다:
$ kubectl apply -f - <<EOFapiVersion: v1 kind: ServiceAccount metadata: name: external-dns --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: external-dns rules: - apiGroups: [""] resources: ["services","endpoints","pods"] verbs: ["get","watch","list"] - apiGroups: ["extensions","networking.k8s.io"] resources: ["ingresses"] verbs: ["get","watch","list"] - apiGroups: ["externaldns.nginx.org"] resources: ["dnsendpoints"] verbs: ["get","watch","list"] - apiGroups: ["externaldns.nginx.org"] resources: ["dnsendpoints/status"] verbs: ["update"] - apiGroups: [""] resources: ["nodes"] verbs: ["list","watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: external-dns-viewer roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: external-dns subjects: - kind: ServiceAccount name: external-dns namespace: default EOF
serviceaccount/external-dns created
clusterrole.rbac.authorization.k8s.io/external-dns created
clusterrolebinding.rbac.authorization.k8s.io/external-dns-viewer created
  1. 매니페스트의 두 번째 부분에서는 ExternalDNS 배포를 생성합니다:
$  kubectl apply -f - <<EOF --- apiVersion: apps/v1 kind: Deployment metadata: name: external-dns spec: strategy: type: Recreate selector: matchLabels: app: external-dns template: metadata: labels: app: external-dns spec: serviceAccountName: external-dns containers: - name: external-dns image: k8s.gcr.io/external-dns/external-dns:v0.12.0 args: - --source=service - --source=ingress - --source=crd - --crd-source-apiversion=externaldns.nginx.org/v1 - --crd-source-kind=DNSEndpoint - --domain-filter=example.com - --provider=Cloudflare env: - name: CF_API_TOKEN value: "<your-API-token>" - name: FREE_TIER value: "true" EOF
serviceaccount/external-dns created
clusterrole.rbac.authorization.k8s.io/external-dns created
clusterrolebinding.rbac.authorization.k8s.io/external-dns-viewer created
deployment.apps/external-dns created
  • DNS 관리를 위한 모든 쓰기 및 업데이트 작업을 관리하는 external-dns라는 ServiceAccount 객체를 생성합니다.
  • 필요한 권한을 정의하는 ClusterRole 객체(이름: external-dns)를 생성합니다.
  • ClusterRole을 ServiceAccount에 바인딩합니다.
  • 도메인을 관리하는 ExternalDNS로 인해 발생할 수 있는 피해 범위를 제한하는 도메인 필터를 생성합니다. 예를 들어 프로덕션 환경이 변경되지 않도록 스테이징 환경의 도메인 이름을 지정할 수 있습니다. 이 예에서는 domain-filter를 example.com으로 설정합니다.
  • Cloudflare API 토큰을 사용하도록 CF_API_TOKEN 환경 변수를 설정합니다. <your-API-token>에는 실제 토큰 또는 토큰이 포함된 Secret을 지정합니다. 후자의 경우 환경 변수를 사용하여 Secret을 컨테이너에 프로젝션해야 합니다.
  • Sets the FREE_TIER 환경 변수를 "true"로 설정합니다(유료 Cloudflare 구독을 사용 중인 경우가 아니라면 적합한 설정입니다).

샘플 애플리케이션 배포

테스트를 위해 Cafe라는 표준 NGINX Ingress Controller 샘플 애플리케이션을 사용합니다.

  1. Cafe 애플리케이션을 배포합니다.
$ kubectl apply -f ./kubernetes-ingress/examples/ingress-resources/complete-example/cafe.yamldeployment.apps/coffee created
service/coffee-svc created
deployment.apps/tea created
service/tea-svc created
  1. Cafe 애플리케이션용 NGINX Ingress Controller를 배포합니다. 다음 설정에 유의하세요. Kubernetes가 DNS 공급자의 API와 상호 작용하므로 이 단계를 완료하는 데 걸리는 시간은 DNS 공급자에 따라 크게 달라질 수 있습니다.
$ kubectl apply -f - <<EOFapiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: cafe spec: host: cafe.example.com tls: secret: cafe-secret cert-manager: cluster-issuer: example-issuer externalDNS: enable: true upstreams: - name: tea service: tea-svc port: 80 - name: coffee service: coffee-svc port: 80 routes: - path: /tea action: pass: tea - path: /coffee action: pass: coffee EOF
virtualserver.k8s.nginx.org/cafe created
  • kind: VirtualServer – 표준 Kubernetes Ingress 리소스가 아닌 NGINX VirtualServer 사용자 지정 리소스를 사용합니다.
  • spec.host – cafe.example.com을(를) 배포하려는 호스트의 이름으로 바꾸세요. 호스트는 ExternalDNS로 관리되는 도메인에 속해야 합니다.
  • spec.tls.cert-manager.cluster-issuer – 이 게시물에 명시된 값을 사용해 왔다면 이 값은 example-issuer입니다. 필요한 경우 cert‑manager 배포의 3단계에서 선택한 이름으로 바꾸세요.
  • spec.externalDNS.enable – true 값은 ExternalDNS가 DNS A 레코드를 생성하도록 합니다.

솔루션 검증

  1. DNS A 레코드를 확인합니다. 특히 ANSWER SECTION 블록에서 FQDN(여기서는 cafe.example.com)이 올바른 IP 주소(www.xxx.yyy.zzz)에 매핑되어 있는지 확인합니다. 
$ dig cafe.example.com 
; <<>> DiG 9.10.6 <<>> cafe.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22633
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cafe.example.com.		IN	A
 
;; ANSWER SECTION:
cafe.example.com.	279	IN	A	www.xxx.yyy.zzz
 
;; Query time: 1 msec
;; SERVER: 2607:fb91:119b:4ac4:2e0:xxxx:fe1e:1359#53(2607:fb91:119b:4ac4:2e0:xxxx:fe1e:1359)
;; WHEN: Day Mon DD hh:mm:ss TZ YYYY
;; MSG SIZE  rcvd: 67
  1. 인증서가 유효한지 확인합니다(READY 필드의 값이 True인지 확인).
$ kubectl get certificatesNAME          READY   SECRET        AGE
cafe-secret   True    cafe-secret   8m51s
  1. 애플리케이션에 접속할 수 있는지 확인합니다.
$ curl https://cafe.example.com/coffeeServer address: 10.2.2.4:8080
Server name: coffee-7c86d7d67c-lsfs6
Date: DD/Mon/YYYY:hh:mm:ss +TZ-offset
URI: /coffee
Request ID: 91077575f19e6e735a91b9d06e9684cd
$ curl https://cafe.example.com/tea
Server address: 10.2.2.5:8080
Server name: tea-5c457db9-ztpns
Date: DD/Mon/YYYY:hh:mm:ss +TZ-offset
URI: /tea
Request ID: 2164c245a495d22c11e900aa0103b00f

개발자가 NGINX Ingress Controller를 배포하면 어떤 일이 발생하나요?

솔루션이 구축되고 나면 내부적으로 많은 작업이 이루어집니다. 이 다이어그램은 개발자가 NGINX VirtualServer 사용자 지정 리소스와 함께 NGINX Ingress Controller를 배포할 때 어떤 일이 일어나는지 보여줍니다. 일부 운영 세부 정보는 생략되어 있습니다.

개발자가 NGINX VirtualServer 사용자 정의 리소스와 함께 NGINX Ingress Controller를 배포할 때의 처리 과정: (1) 개발자가 NGINX CRD를 사용하여 VirtualServer 리소스를 배포합니다. (2) Kubernetes가 NGINX Ingress Controller를 사용하여 VirtualServer를 생성합니다. (3) NGINX Ingress Controller가 DNS A 레코드를 생성하도록 ExternalDNS를 호출합니다. (4) ExternalDNS가 DNS에 A 레코드를 생성합니다. (5) NGINX Ingress Controller가 TLS 인증서를 요청하도록 cert-manager를 호출합니다. (6) cert-manager가 DNS-01 챌린지에 사용할 DNS 레코드를 추가합니다. (7) cert-manager가 챌린지를 완료하기 위해 Let’s Encrypt에 연결합니다. (8) Let’s Encrypt가 DNS를 통해 챌린지를 검증합니다. (9) Let’s Encrypt가 TLS 인증서를 발급합니다. (10) cert-manager가 NGINX Ingress Controller에 TLS 인증서를 제공합니다. (11) NGINX Ingress Controller가 TLS로 보호된 외부 요청을 애플리케이션 파드로 라우팅합니다.

  1. 개발자가 NGINX CRD를 사용하여 VirtualServer 리소스를 배포합니다
  2. Kubernetes는 NGINX Ingress Controller를 사용하여 VirtualServer를 생성합니다.
  3. NGINX Ingress Controller가 ExternalDNS를 호출하여 DNS A 레코드를 생성합니다
  4. ExternalDNS가 DNS에 A 레코드를 생성합니다
  5. NGINX Ingress Controller가 cert-manager를 호출하여 TLS 인증서를 요청합니다
  6. cert-manager가 DNS-01 챌린지에 사용할 DNS 레코드를 추가합니다
  7. cert-manager가 챌린지를 완료하기 위해 Let’s Encrypt에 연결합니다
  8. Let’s Encrypt가 DNS를 통해 챌린지를 검증합니다
  9. Let’s Encrypt가 TLS 인증서를 발급합니다
  10. cert-manager가 NGINX Ingress Controller에 TLS 인증서를 제공합니다
  11. NGINX Ingress Controller는 TLS로 보호된 외부 요청을 애플리케이션 파드로 라우팅합니다

문제 해결

Kubernetes와 현재 사용 중인 구성 요소의 복잡성을 고려하면 포괄적인 문제 해결 가이드를 제공하기는 어렵습니다. 다만, 문제의 원인을 파악하는 데 도움이 되는 몇 가지 기본적인 방법을 제안해 드릴 수 있습니다.

  • 배포된 객체의 구성을 확인하려면 kubectl get 및 kubectl describe 명령을 사용하세요.
  • 다양한 배포 구성 요소의 로그 파일을 보려면 kubectl logs <component> 명령을 사용합니다.
  • 설치 상태를 점검하려면 K9s를 사용하십시오. 이 소프트웨어는 심각도에 따라 문제를 노란색 또는 빨간색으로 표시하며, 로그와 객체 세부 정보에 액세스할 수 있는 인터페이스를 제공합니다.

문제가 계속 발생한다면 NGINXCommunity Slack에서 저희를 찾아 도움을 요청해 주세요! 활발한 커뮤니티가 여러분의 문제 해결을 언제나 기꺼이 도와드립니다.

NGINX Plus 기반 NGINX Ingress Controller를 사용해 보려면 지금 30일 무료 체험을 시작하거나 문의하여 사용 사례에 대해 상담해 보세요.

공유
추천 블로그 게시물
클라우드 네이티브 기술, 플랫폼 엔지니어링 및 AI의 최신 동향F5 NGINX One을 통한 앱 및 API 제공의 전체 수명 주기 관리최신 애플리케이션 제공 간소화: F5 NGINX One과 함께한 9개월
태그: DNS, F5 NGINX, Tech

작성자 소개

Jason Schmidt
Jason Schmidt

Jason Schmidt의 다른 블로그 게시물

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.

실행 위치와 관계없이 모든 애플리케이션과 API를 제공하고 보호하세요
F5는 현대 디지털 비즈니스가 운영되는 복잡한 환경 전반에서 애플리케이션과 API를 빠르고, 가용성이 높으며, 안전하게 유지합니다. F5 Application Delivery and Security Platform에 대해 자세히 알아보세요.
F5와 소통하기