트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법

속도 저하 없이 클라우드 네이티브 앱 보호에서 논의한 바와 같이 클라우드 네이티브 앱을 기존 앱보다 보호하기 어렵게 만드는 세 가지 요소를 관찰했습니다.

  1. 클라우드 네이티브 앱 제공은 도구의 무분별한 확장을 유발하고 일관성 없는 엔터프라이즈급 서비스를 제공합니다.
  2. 클라우드 네이티브 앱 제공 비용은 예측할 수 없고 높을 수 있습니다.
  3. SecOps 팀은 클라우드 네이티브 앱을 보호하기 위해 고군분투하고 DevOps와 대립합니다.

세 가지 요소 모두 보안에 똑같이 영향을 미칠 수 있지만 세 번째 요소는 가장 “인간적인” 문제이기 때문에 해결하기 가장 어려운 문제일 수 있습니다. SecOps가 클라우드 네이티브 앱을 보호할 수 없거나 권한이 부여되지 않은 경우 일부 결과(취약점 및 침해)는 명백하지만 민첩성 저하 및 디지털 혁신 지연을 포함하여 다른 결과는 숨겨집니다.

그 숨겨진 비용에 대해 더 깊이 파헤쳐 보겠습니다. 조직은 민첩성과 비용 절감을 약속하는 Kubernetes를 선택합니다. 그러나 Kubernetes 환경에 보안 사고가 발생하면 대부분의 조직에서 Kubernetes 배포를 프로덕션에서 제외합니다. 이는 조직의 미래에 필수적인 디지털 혁신 이니셔티브의 속도를 늦춥니다. 낭비되는 엔지니어링 노력과 비용에 신경 쓰지 마십시오. 논리적인 결론은 다음과 같습니다. 테스트에서 프로덕션으로 Kubernetes를 가져오려면 보안을 조직의 모든 사람이 소유하는 전략적 구성 요소로 간주해야 합니다.

이 가이드에서는 SecOps가 DevOps 및 NetOps와 협력하여 클라우드 네이티브 앱 및 API를 더 잘 보호할 수 있도록 하는 Kubernetes 트래픽 관리 도구로 해결할 수 있는 6가지 보안 사용 사례를 다룹니다. 이러한 기술의 조합은 종종 고객에 대한 영향을 최소화하면서 앱과 API를 안전하게 유지하도록 설계된 포괄적인 보안 전략을 만드는 데 사용됩니다.

  1. 사이버 공격을 피하기 위해 CVE를 신속하게 해결
  2. OWASP Top 10 및 서비스 거부 공격 차단
  3. 앱에서 인증 및 권한 부여 오프로드(offload)
  4. Guardrails으로 셀프 서비스 설정
  5. 종단 간 암호화 구현
  6. 클라이언트가 신뢰할 수 있는 구현과 함께 강력한 암호를 사용하고 있는지 확인합니다.

목차

1. 보안 및 Identity 용어(Security and Identity Terminology)
  1-1. 사용 사례(Use Case): 사이버 공격을 피하기 위해 CVE를 신속하게 해결
  1-2. 사용 사례(Use Case): OWASP Top 10 및 DoS 공격 중지
  1-3. 사용 사례(Use Case): 앱에서 인증 및 권한 부여 오프로드(Offload)
  1-4. 사용 사례(Use Case): Guardrails로 셀프 서비스 설정
  1-5. 사용 사례(Use Case): 종단 간 암호화 구현
  1-6. 사용 사례(Use Case): 클라이언트가 신뢰할 수 있는 구현과 함께 강력한 암호를 사용하고 있는지 확인
2. NGINX로 Kubernetes를 더욱 안전하게 만드세요.

1. 보안 및 Identity 용어(Security and Identity Terminology)

사용 사례로 넘어가기 전에 이 가이드 전체에서 접하게 될 몇 가지 보안 및 ID 용어에 대한 간략한 개요가 있습니다.

  • 인증 및 권한 부여(Authentication and authorization) – “적절한” 사용자 및 서비스만 backend 또는 애플리케이션 구성 요소에 액세스할 수 있도록 하는 데 필요한 기능:
    • 인증(Authentication) – 요청을 하는 클라이언트가 자신이 주장하는 사람인지 확인하기 위한 신원 확인. 비밀번호 또는 JWT(JSON 웹 토큰)와 같은 ID 토큰을 통해 수행됩니다.
    • 권한 부여(Authorization) – 리소스 또는 기능에 액세스할 수 있는 권한 확인. 세션 쿠키, 세션 ID, 그룹 ID 또는 토큰 콘텐츠와 같은 Layer 7 속성과 같은 액세스 토큰을 통해 수행됩니다.
  • CVE(Critical Vulnerabilities and Exposures) – 소프트웨어, 펌웨어, 하드웨어 또는 서비스 구성요소의 공개적으로 공개된 결함의 데이터베이스로, 취약점이 악용될 수 있어 영향을 받는 시스템의 기밀성, 무결성 또는 가용성에 부정적인 영향을 줍니다. CVE는 도구를 관리하는 개발자, 침투 테스터, 사용자 또는 고객 또는 커뮤니티의 누군가(예: “버그 헌터”)가 발견할 수 있습니다. 취약점이 공개되기 전에 소프트웨어 소유자에게 패치를 개발할 시간을 주어 악의적인 사용자에게 이점을 주지 않는 것이 일반적입니다.
  • 서비스 거부 공격(Denial-of-service attack) – 악의적인 행위자가 사이트 충돌을 일으킬 목적으로 웹사이트에 요청(TCP/UDP 또는 HTTP/HTTPS)을 플러딩하는 공격입니다. DoS 공격은 가용성에 영향을 미치므로 주요 결과는 대상의 평판에 대한 손상입니다. 여러 소스가 동일한 네트워크 또는 서비스를 대상으로 하는 DDoS(분산 서비스 거부) 공격은 잠재적으로 대규모 공격자 네트워크로 인해 방어하기가 더 어렵습니다. DoS 보호에는 공격을 적응적으로 식별하고 방지하는 도구가 필요합니다.
  • 종단 간 암호화(End-to-end encryption) – 데이터가 사용자에서 앱으로 그리고 그 반대로 전달될 때 데이터를 완전히 암호화하는 방식입니다. E2EE에는 SSL 인증서와 잠재적으로 mTLS가 필요합니다.
  • 상호 TLS(mTLS) – 클라이언트와 호스트 모두에 대해 인증(SSL/TLS 인증서를 통해)을 요구하는 방식입니다. mTLS를 사용하면 클라이언트와 호스트 간에 전달되는 데이터의 기밀성과 무결성도 보호할 수 있습니다. mTLS는 동일한 클러스터의 두 서비스 간에 Kubernetes 파드(Pod) 수준까지 완전히 수행할 수 있습니다.
  • 싱글 사인온(SSO) – SSO 기술(SAML, OAuth 및 OIDC 포함)을 사용하면 인증 및 권한 부여를 더 쉽게 관리할 수 있습니다.
    • 간소화된 인증(Simplified authentication) – SSO를 사용하면 사용자가 각기 다른 리소스 또는 기능에 대해 고유한 ID 토큰을 가질 필요가 없습니다.
    • 표준화된 권한 부여(Standardized authorization) – SSO를 사용하면 역할, 부서 및 직급에 따라 사용자 액세스 권한을 쉽게 설정할 수 있으므로 각 사용자에 대해 권한을 개별적으로 구성할 필요가 없습니다.
  • SSL(Secure Sockets Layer)/TLS(Transport Layer Security) – 네트워크로 연결된 컴퓨터 간에 인증되고 암호화된 링크를 설정하기 위한 프로토콜입니다. SSL/TLS 인증서는 웹사이트의 ID를 인증하고 암호화된 연결을 설정합니다. SSL 프로토콜은 1999년에 더 이상 사용되지 않고 TLS 프로토콜로 대체되었지만 이러한 관련 기술을 “SSL” 또는 “SSL/TLS”로 지칭하는 것이 여전히 일반적입니다. 일관성을 위해 SSL/TLS를 사용합니다.
  • 웹 애플리케이션 방화벽(WAF) – 앱 및 API에 대한 정교한 공격(OWASP Top 10 및 기타 지능형 위협 포함)을 탐지하고 차단하는 동시에 “안전한” 트래픽을 통과시키는 리버시 프록시입니다. WAF는 민감한 데이터를 훔치거나 시스템을 하이재킹하여 대상을 해치려는 공격을 방어합니다. 일부 공급업체는 동일한 도구에서 WAF 및 DoS 보호를 통합하는 반면 다른 공급업체는 별도의 WAF 및 DoS 도구를 제공합니다.
  • 제로 트러스트(Zero trust) – 높은 수준의 보안 조직에서 자주 사용되지만 모든 사람과 관련이 있는 보안 개념으로 모든 저장 및 전송 단계에서 데이터를 보호해야 합니다. 이는 조직이 기본적으로 사용자나 장치를 “신뢰”하지 않고 모든 트래픽을 철저하게 조사하도록 결정했음을 의미합니다. 제로 트러스트(zero‑trust) 아키텍처에는 일반적으로 조직에서 E2EE를 구현할 가능성이 높은 인증, 권한 부여 및 mTLS의 조합이 포함됩니다.

1-1. 사용 사례(Use Case): 사이버 공격을 피하기 위해 CVE를 신속하게 해결

솔루션(Solution): 시기 적절하고 사전 예방적인 패치 알림이 있는 도구 사용

Ponemon Institute의 연구에 따르면 2019년에 중요하거나 우선 순위가 높은 취약점에 대한 패치 릴리스와 취약점을 악용하려는 공격을 목격한 조직 사이에 평균 43일의 “유예 기간”이 있었습니다. NGINX에서 우리는 다음 몇 년 동안(2021년 Apple iOS 15의 경우 0일까지) 기간이 크게 좁아지는 것을 보았으므로 가능한 한 빨리 패치를 권장합니다. 그러나 CVE가 발표된 후 몇 주 또는 몇 달 동안 트래픽 관리 도구에 대한 패치를 사용할 수 없다면 어떻게 될까요?

(전담 엔지니어링 팀이 아닌) 커뮤니티 기여자가 개발하고 유지 관리하는 도구는 CVE 발표보다 몇 주 또는 몇 달이 늦어질 가능성이 있으므로 조직이 해당 43일 기간 내에 패치를 적용할 수 없을 것입니다. 한 경우에는 OpenResty가 NGINX 관련 보안 패치를 적용하는 데 4개월이 걸렸습니다. 이로 인해 OpenResty 기반 Ingress Controller를 사용하는 모든 사람은 최소 4개월 동안 취약했지만, 실제로는 일반적으로 오픈소스 프로젝트에 의존하는 소프트웨어에 패치가 제공되기까지 추가 지연이 있습니다.

가장 빠른 CVE 패치를 얻으려면 트래픽 관리 도구를 선택할 때 다음 두 가지 특성을 찾으십시오.

전담 엔지니어링 팀 – 커뮤니티 자원 봉사자 대신 엔지니어링 팀에서 도구 개발을 관리하는 경우 도구 상태에 전념하고 가능한 한 빨리 패치 릴리스를 우선시할 수 있는 사람들 그룹이 있다는 것을 알 수 있습니다.

통합 코드 기반 – OpenResty에서 논의한 것처럼 외부 종속성이 없기 때문에 패치는 애자일 스프린트 거리에 있습니다.

1-2. 사용 사례(Use Case): OWASP Top 10 및 DoS 공격 중지

솔루션(Solution): 유연하고 Kubernetes 친화적인 WAF 및 DoS 보호 배포

Kubernetes 앱에 적합한 WAF 및 DoS 보호를 선택하는 것은 기능 외에 두 가지 요소에 따라 달라집니다.

  • 유연성(Flexibility) – Kubernetes 내부에 도구를 배포하는 것이 가장 좋은 시나리오가 있으므로 Kubernetes 내부 또는 외부에서 실행할 수 있는 인프라에 구애받지 않는 도구가 필요합니다. 모든 배포에 동일한 도구를 사용하면 정책을 재사용하고 SecOps 팀의 학습 곡선을 줄일 수 있습니다.
  • 공간(Footprint) – 최고의 Kubernetes 도구는 공간이 작기 때문에 처리량, 초당 요청 수 및 대기 시간에 미치는 영향을 최소화하면서 적절한 리소스 소비를 허용합니다. DevOps 팀은 종종 앱 속도를 저하시킨다는 인식 때문에 보안 도구에 저항하는 경우가 많기 때문에 설치 공간이 작은 고성능 도구를 선택하면 채택 가능성이 높아질 수 있습니다.

WAF 및 DoS 보호를 통합하는 도구가 더 효율적으로 보일 수 있지만 실제로는 CPU 사용량(설치 공간이 더 크기 때문에)과 유연성 모두에 문제가 있을 것으로 예상됩니다. 둘 다 필요하지 않더라도 WAF와 DoS 보호를 함께 배포해야 합니다. 궁극적으로 두 문제 모두 Kubernetes 배포의 총 소유 비용을 높이는 동시에 다른 필수 도구 및 서비스에 대한 예산 문제를 생성할 수 있습니다.

조직에 적합한 보안 도구를 선택했다면 이제 해당 도구를 배포할 위치를 결정할 차례입니다. Kubernetes 앱을 보호하기 위해 일반적으로 애플리케이션 서비스를 배포할 수 있는 4개의 위치가 있습니다.

  • front door에서(NGINX Plus 또는 F5 BIG‑IP와 같은 외부 load balancer에서) – 여러 클러스터에 글로벌 정책을 적용할 수 있으므로 “거친” 글로벌 보호에 적합
  • edge에서(NGINX Ingress Controller와 같은 Ingress Controller에서) – 단일 클러스터에서 표준인 “세밀한” 보호를 제공하는 데 이상적입니다.
  • service에서(NGINX Plus와 같은 경량 load balancer에서) – 고유한 정책에 대한 공유 요구 사항이 있는 클러스터 내에 소수의 서비스가 있는 경우 필요한 접근 방식일 수 있습니다.
  • pod에서(application의 일부로) – 정책이 앱에 특정할 때 사용할 수 있는 맞춤형 접근 방식

그렇다면 4가지 옵션 중 어떤 것이 가장 좋을까요? 글쎄요…그건 달라요!

WAF 배포(Deploy) 위치

먼저 WAF 배포 옵션이 더 미묘한 선택이 되는 경향이 있기 때문에 WAF 배포 옵션을 살펴보겠습니다.

  • Front door 및 edge – 조직에서 “심층 방어” 보안 전략을 선호하는 경우 외부 load balancer와 Ingress Controller 모두에 WAF를 배포하여 전역 및 사용자 지정 보호의 효율적인 균형을 제공하는 것이 좋습니다.
  • Front door 또는 edge – “심층 방어” 전략이 없는 경우 단일 위치가 허용되며 배포 위치는 소유권에 따라 다릅니다. 기존 NetOps 팀이 보안을 소유하면 기존 Proxy(외부 load balancer)에서 보안을 관리하는 것이 더 편할 수 있습니다. 그러나 Kubernetes에 익숙하고 클러스터 구성 근처에 보안 구성을 두는 것을 선호하는 DevSecOps 팀은 수신 수준에서 WAF를 배포하도록 선택할 수 있습니다.
  • service 또는 pod당 – 팀에 서비스 또는 앱에 대한 특정 요구 사항이 있는 경우 일품 방식으로 추가 WAF를 배포할 수 있습니다. 그러나 이러한 위치에는 더 높은 비용이 따릅니다. 이 선택은 개발 시간 증가와 클라우드 예산 증가 외에도 “우리 WAF 중 의도하지 않게 트래픽을 차단하는 WAF는 무엇입니까?”를 결정할 때와 같은 문제 해결 노력과 관련된 운영 비용을 증가시킬 수 있습니다.

DoS 보호를 배포할 위치

DoS 공격에 대한 보호는 현관문이나 Ingress Controller의 한 위치에서만 필요하기 때문에 더 간단합니다. front door와 edge 모두에 WAF를 배포하는 경우 가장 글로벌하므로 front door WAF 앞에 DoS 보호를 배포(depoloy)하는 것이 좋습니다. 그렇게 하면 WAF에 도달하기 전에 원치 않는 트래픽을 제거할 수 있으므로 컴퓨팅 리소스를 보다 효율적으로 사용할 수 있습니다.

1-3. 사용 사례(Use Case): 앱에서 인증 및 권한 부여 오프로드(Offload)

솔루션(Solution): ingress 지점에서 인증 및 권한 부여 중앙 집중화

앱과 서비스에 내장되는 일반적인 기능 외 요구 사항은 인증 및 권한 부여입니다. 작은 규모에서 이 방법은 앱이 자주 업데이트될 필요가 없을 때 수용할 수 있는 관리 가능한 정도의 복잡성을 추가합니다. 그러나 대규모로 릴리스 속도가 빨라지면 인증 및 권한 부여를 앱에 통합하는 것이 불가능해집니다. 각 앱이 적절한 액세스 프로토콜을 유지하도록 하면 앱의 비즈니스 로직이 산만해질 수 있으며, 더 심각한 경우에는 간과되어 정보 유출로 이어질 수 있습니다. SSO 기술을 사용하면 하나의 자격 증명 집합을 위해 별도의 사용자 이름과 암호를 제거하여 보안을 향상시킬 수 있지만 개발자는 여전히 SSO 시스템과 인터페이스하기 위해 앱에 코드를 포함해야 합니다.

더 좋은 방법이 있습니다. 인증 및 권한 부여를 Ingress Controller로 오프로드(offload)하는 것입니다.

Ingress Controller는 이미 클러스터에 들어오는 모든 트래픽을 조사하고 적절한 서비스로 라우팅하기 때문에 중앙 집중식 인증 및 권한 부여를 위한 효율적인 선택입니다. 이를 통해 개발자는 애플리케이션 코드에서 로직을 구축, 유지 관리 및 복제해야 하는 부담을 덜 수 있습니다. 대신 기본 Kubernetes API를 사용하여 수신 계층에서 SSO 기술을 빠르게 활용할 수 있습니다.

1-4. 사용 사례(Use Case): Guardrails로 셀프 서비스 설정

솔루션(Solution): RBAC(역할 기반 액세스 제어) 구현

Kubernetes는 RBAC를 사용하여 다양한 유형의 사용자가 사용할 수 있는 리소스와 작업을 제어합니다. 이는 관리자 또는 수퍼유저가 사용자 또는 사용자 그룹이 클러스터의 Kubernetes 개체 또는 특정 네임스페이스와 상호 작용할 수 있는 방법을 결정할 수 있도록 하는 귀중한 보안 수단입니다.

Kubernetes RBAC는 기본적으로 활성화되어 있지만 Kubernetes 트래픽 관리 도구도 RBAC를 활성화하고 조직의 보안 요구 사항에 맞출 수 있다는 점에 주의해야 합니다. RBAC를 사용하면 사용자는 티켓이 처리될 때까지 기다리지 않고 작업을 수행하는 데 필요한 기능에 대한 게이트 액세스를 얻을 수 있습니다. 그러나 RBAC를 구성하지 않으면 사용자가 필요하지 않거나 자격이 없는 권한을 얻을 수 있으며, 이는 권한이 오용될 경우 취약점으로 이어질 수 있습니다.

Ingress Controller는 RBAC로 구성할 때 수많은 사람과 팀에 서비스를 제공할 수 있는 도구의 대표적인 예입니다. Ingress Controller가 단일 네임스페이스까지 세분화된 액세스 관리를 허용하는 경우 RBAC를 사용하여 멀티 테넌시를 통해 리소스를 효율적으로 사용할 수 있습니다.

예를 들어 여러 팀에서 다음과 같이 Ingress Controller를 사용할 수 있습니다.

  • NetOps팀 – 애플리케이션의 외부 진입점(예: 호스트 이름 및 TLS 인증서)을 구성하고 트래픽 제어 정책을 다양한 팀에 위임합니다.
  • DevOps팀A – TCP/UDP load balancing 및 라우팅 정책 제공
  • DevOps팀B – 과도한 요청으로부터 서비스를 보호하기 위한 속도 제한(rate-limiting) 정책 구성
  • Identity팀 – 종단 간 암호화 전략의 일부로 mTLS 정책을 구성하는 동안 인증 및 권한 부여 구성 요소를 관리합니다.
  • DevSecOps팀 – WAF 정책 설정

1-5. 사용 사례(Use Case): 종단 간 암호화 구현

솔루션(Solution): 트래픽 관리 도구 사용

종단 간 암호화(E2EE)는 민감한 개인 정보를 처리하는 조직에서 점점 더 일반적인 요구 사항이 되고 있습니다. 금융 데이터든 소셜 미디어 메시징이든 GDPR 및 HIPAA와 같은 규정과 결합된 소비자 개인 정보 보호 기대는 이러한 유형의 보호에 대한 수요를 주도하고 있습니다. E2EE를 달성하는 첫 번째 단계는 SSL/TLS 트래픽을 허용하도록 backend 앱을 설계하거나 앱에서 SSL/TLS 관리를 오프로드(offload)하는 도구를 사용하는 것입니다(보안 기능, 성능, 키 관리 등을 분리하는 데 선호되는 옵션). 그런 다음 환경의 복잡성에 따라 트래픽 관리 도구를 구성합니다.

가장 일반적인 시나리오: Ingress Controller를 사용하는 E2EE

endpoint가 하나뿐인 앱(단순 앱 또는 Kubernetes로 “lifted and shifted”한 모놀리식 앱)이 있거나 서비스 간 통신이 없는 경우 Ingress Controller를 사용하여 Kubernetes 내에서 E2EE를 구현할 수 있습니다.

1단계: Ingress Controller가 ingress 및 egress 트래픽 모두에 대해 이상적으로는 서비스 측 또는 mTLS 인증서를 사용하여 암호화된 SSL/TLS 연결만 허용하는지 확인합니다.

2단계: Ingress Controller가 트래픽을 앱으로 보내기 전에 암호를 해독하고 다시 암호화해야 하는 일반적인 기본 설정을 처리합니다. 이것은 몇 가지 방법으로 수행할 수 있습니다. 선택하는 방법은 Ingress Controller 및 요구 사항에 따라 다릅니다.

  • Ingress Controller가 SSL/TLS 패스스루(passthrough)를 지원하는 경우 SNI(서비스 이름 표시) 헤더를 기반으로 SSL/TLS 암호화 연결을 해독하거나 SSL/TLS 인증서 또는 키에 대한 액세스를 요구하지 않고 라우팅할 수 있습니다.
  • 또는 SSL/TLS termination를 설정할 수 있습니다. 여기서 Ingress Controller는 트래픽을 종료한 다음 mTLS 또는 Kubernetes 서비스 측 SSL/TLS로 트래픽을 다시 암호화하여 일반 텍스트로 트래픽을 backend 또는 upstream에 Proxy합니다.

덜 일반적인 시나리오: Ingress Controller 및 Service Mesh를 사용하는 E2EE

클러스터 내에 서비스 간 통신이 있는 경우 Ingress Controller가 있는 ingress-egress 트래픽과 Service Mesh가 있는 서비스 간 트래픽의 두 평면에서 E2EE를 구현해야 합니다. E2EE에서 Service Mesh의 역할은 특정 서비스만 서로 통신할 수 있고 안전한 방식으로 통신할 수 있도록 하는 것입니다. E2EE용 Service Mesh를 설정할 때 두 가지 요소를 통해 제로 트러스트(zero-trust) 환경을 활성화해야 합니다. 서비스 간 mTLS(인증서가 필요하도록 설정) 및 서비스 간 트래픽 액세스 제어(통신 권한이 부여된 서비스 지정) . 이상적으로는 Kubernetes 클러스터 전체에서 진정한 E2EE 보안을 위해 애플리케이션(Service Mesh 및 ingress-egress controller로 관리) 간에 mTLS도 구현합니다.

1-6. 사용 사례(Use Case): 클라이언트가 신뢰할 수 있는 구현과 함께 강력한 암호를 사용하고 있는지 확인

솔루션(Solution): FIPS(연방 정보 처리 표준) 준수

소프트웨어 산업에서 FIPS는 일반적으로 미국과 캐나다 간의 공동 노력인 암호화 모듈에 대한 FIPS PUB 140-2 보안 요구 사항인 암호화에 관한 간행물을 참조합니다. 민감한 정보 보호를 위해 양국의 연방 기관에서 승인한 암호화 모듈의 테스트 및 인증을 표준화합니다. “하지만 기다려!” 당신은 말한다. “나는 북미 정부 기관과 일하지 않기 때문에 FIPS에 관심이 없습니다.” FIPS는 사실상의 글로벌 암호화 기준이기도 하기 때문에 FIPS를 준수하는 것은 산업이나 지역에 관계없이 현명한 조치가 될 수 있습니다.

FIPS를 준수하는 것이 어려울 필요는 없지만 운영 체제와 관련 트래픽 관리 도구가 모두 FIPS 모드에서 작동할 수 있어야 합니다. FIPS 모드에서 운영체제를 실행하기만 하면 FIPS 준수가 달성된다는 일반적인 오해가 있습니다. 운영 체제가 FIPS 모드인 경우에도 Ingress Controller와 통신하는 클라이언트가 강력한 암호를 사용하지 않을 가능성이 있습니다. FIPS 모드에서 작동할 때 운영 체제와 Ingress Controller는 일반적인 SSL/TLS 암호의 하위 집합만 사용할 수 있습니다.

Kubernetes 배포를 위한 FIPS 설정은 4단계 프로세스입니다.

  • 1단계: FIPS 모드용 운영 체제 구성
  • 2단계: 운영체제 및 OpenSSL이 FIPS 모드인지 확인
  • 3단계: Ingress Controller 설치
  • 4단계: FIPS 상태 확인을 수행하여 FIPS 140-2 준수 확인

아래 예에서 운영체제와 NGINX Plus에서 사용하는 OpenSSL 구현 모두에 대해 FIPS 모드가 활성화된 경우 NGINX Plus에서 들어오고 나가는 모든 최종 사용자 트래픽은 검증된 FIPS 활성화 암호화 엔진을 사용하여 해독되고 암호화됩니다.

2. NGINX로 Kubernetes를 더욱 안전하게 만드세요.

이러한 보안 방법 중 일부(또는 전체)를 구현할 준비가 되었다면 도구에 사용 사례(Use Case)를 지원하는 데 적합한 기능과 기능이 있는지 확인해야 합니다. NGINX는 프로덕션 준비가 완료된 Kubernetes 트래픽 관리 도구 제품군을 지원합니다.

  • NGINX Ingress Controller – 고급 트래픽 제어 및 형성, 모니터링 및 가시성, 인증 및 SSO를 처리하고 API Gateway 역할을 하는 Kubernetes용 NGINX Plus 기반 Ingress Controller.
  • NGINX App Protect – NGINX Ingress Controller 및 NGINX Plus와 통합되는 F5의 시장 선도적인 보안 기술을 기반으로 구축된 최신 앱 및 API를 위한 전체적인 보호. 배포 시나리오의 유연성과 최적의 리소스 활용을 위해 모듈식 접근 방식을 사용합니다.
    • NGINX App Protect WAF – PCI DDS 준수로 OWASP Top 10 이상으로부터 보호하는 강력하고 가벼운 WAF입니다.
    • NGINX App Protect DoS – 클라우드 및 아키텍처 전반에 걸쳐 일관되고 적응형 보호를 통해 행동 기반 DoS 탐지 및 완화.
  • NGINX Service Mesh – NGINX Plus를 엔터프라이즈 Sidecar로 제공하는 경량 턴키 방식의 개발자 친화적인 Service Mesh.