Kubernetes 를 트래픽 관리 도구를 사용하여 보호하는 6가지 방법
속도 저하 없이 Kubernetes 클라우드 네이티브 앱 보호에서 논의한 바와 같이 클라우드 네이티브 앱을 기존 앱보다 보호하기 어렵게 만드는 세 가지 요소를 관찰했습니다.
- 클라우드 네이티브 앱 제공은 도구의 무분별한 확장을 유발하고 일관성 없는 엔터프라이즈급 서비스를 제공합니다.
- 클라우드 네이티브 앱 제공 비용은 예측할 수 없고 높을 수 있습니다.
- SecOps 팀은 클라우드 네이티브 앱을 보호하기 위해 고군분투하고 DevOps와 대립합니다.
세 가지 요소 모두 보안에 똑같이 영향을 미칠 수 있지만 세 번째 요소는 가장 “인간적인” 문제이기 때문에 해결하기 가장 어려운 문제일 수 있습니다.
이 가이드에서는 SecOps가 DevOps 및 NetOps와 협력하여 클라우드 네이티브 앱 및 API를 더 잘 보호할 수 있도록 하는 Kubernetes 트래픽 관리 도구로 해결할 수 있는 6가지 보안 사용 사례를 다룹니다.
목차
1. 보안 및 Identity 용어(Security and Identity Terminology)
1-1. 사용 사례(Use Case): 사이버 공격을 피하기 위해 CVE를 신속하게 해결
1-2. 사용 사례(Use Case): Kubernetes 앱에 대한 OWASP Top 10 및 DoS 공격 중지
1-3. 사용 사례(Use Case): Kubernetes 앱에서 인증 및 권한 부여 오프로드(Offload)
1-4. 사용 사례(Use Case): Guardrails로 셀프 서비스 설정
1-5. 사용 사례(Use Case): Kubernetes 종단 간 암호화 구현
1-6. 사용 사례(Use Case): 클라이언트가 신뢰할 수 있는 구현과 함께 강력한 암호를 사용하고 있는지 확인
2. NGINX로 Kubernetes 를 더욱 안전하게 만드세요.
1. 보안 및 Identity 용어(Security and Identity Terminology)
사용 사례로 넘어가기 전에 이 가이드 전체에서 접하게 될 몇 가지 보안 및 ID 용어에 대한 간략한 개요가 있습니다.
- 인증 및 권한 부여(Authentication and authorization)
- 인증(Authentication) – 요청을 하는 클라이언트가 자신이 주장하는 사람인지 확인하기 위한 신원 확인.
비밀번호 또는 JWT(JSON 웹 토큰)와 같은 ID 토큰을 통해 수행됩니다. - 권한 부여(Authorization) – 리소스 또는 기능에 액세스할 수 있는 권한 확인.
세션 쿠키, 세션 ID, 그룹 ID 또는 토큰 콘텐츠와 같은 Layer 7 속성과 같은 액세스 토큰을 통해 수행됩니다.
- 인증(Authentication) – 요청을 하는 클라이언트가 자신이 주장하는 사람인지 확인하기 위한 신원 확인.
- CVE(Critical Vulnerabilities and Exposures) – 소프트웨어, 펌웨어, 하드웨어 또는 서비스 구성요소의 공개적으로 공개된 결함의 데이터베이스로, 취약점이 악용될 수 있어 영향을 받는 시스템의 기밀성, 무결성 또는 가용성에 부정적인 영향을 줍니다.
- 서비스 거부 공격(Denial-of-service attack) – 악의적인 행위자가 사이트 충돌을 일으킬 목적으로 웹사이트에 요청(TCP/UDP 또는 HTTP/HTTPS)을 플러딩하는 공격입니다.
- 종단 간 암호화(End-to-end encryption) – 데이터가 사용자에서 앱으로 그리고 그 반대로 전달될 때 데이터를 완전히 암호화하는 방식입니다.
- 상호 TLS(mTLS) – 클라이언트와 호스트 모두에 대해 인증(SSL/TLS 인증서를 통해)을 요구하는 방식입니다.
- 싱글 사인온(SSO) – SSO 기술(SAML, OAuth 및 OIDC 포함)을 사용하면 인증 및 권한 부여를 더 쉽게 관리할 수 있습니다.
- SSL(Secure Sockets Layer)/TLS(Transport Layer Security) – 네트워크로 연결된 컴퓨터 간에 인증되고 암호화된 링크를 설정하기 위한 프로토콜입니다.
- 웹 애플리케이션 방화벽(WAF) – 앱 및 API에 대한 정교한 공격을 탐지하고 차단하는 동시에 “안전한” 트래픽을 통과시키는 리버스 프록시입니다.
- 제로 트러스트(Zero trust) – 높은 수준의 보안 조직에서 자주 사용되지만 모든 사람과 관련이 있는 보안 개념으로 모든 저장 및 전송 단계에서 데이터를 보호해야 합니다.
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개월 동안 취약했지만, 실제로는 일반적으로 오픈소스 프로젝트에 의존하는 소프트웨어에 패치가 제공되기까지 추가 지연이 있습니다.
1-2. 사용 사례(Use Case): Kubernetes 앱에 대한 OWASP Top 10 및 DoS 공격 중지
솔루션(Solution): 유연하고 Kubernetes 친화적인 WAF 및 DoS 보호 배포
Kubernetes 앱에 적합한 WAF 및 DoS 보호를 선택하는 것은 기능 외에 두 가지 요소에 따라 달라집니다.
- 유연성(Flexibility) – 모든 배포에 동일한 도구를 사용하면 정책을 재사용하고 SecOps 팀의 학습 곡선을 줄일 수 있습니다.
- 공간(Footprint) – 최고의 Kubernetes 도구는 공간이 작기 때문에 처리량, 초당 요청 수 및 대기 시간에 미치는 영향을 최소화하면서 적절한 리소스 소비를 허용합니다.
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의 일부로) – 정책이 앱에 특정할 때 사용할 수 있는 맞춤형 접근 방식
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를 배포할 수 있습니다.
DoS 보호를 배포할 위치
DoS 공격에 대한 보호는 현관문이나 Ingress Controller의 한 위치에서만 필요하기 때문에 더 간단합니다.
front door와 edge 모두에 WAF를 배포하는 경우 가장 글로벌하므로 front door WAF 앞에 DoS 보호를 배포(depoloy)하는 것이 좋습니다.
그렇게 하면 WAF에 도달하기 전에 원치 않는 트래픽을 제거할 수 있으므로 컴퓨팅 리소스를 보다 효율적으로 사용할 수 있습니다.
1-3. 사용 사례(Use Case): Kubernetes 앱에서 인증 및 권한 부여 오프로드(Offload)
솔루션(Solution): ingress 지점에서 인증 및 권한 부여 중앙 집중화
앱과 서비스에 내장되는 일반적인 기능 외 요구 사항은 인증 및 권한 부여입니다.
작은 규모에서 이 방법은 앱이 자주 업데이트될 필요가 없을 때 수용할 수 있는 관리 가능한 정도의 복잡성을 추가합니다.
그러나 대규모로 릴리스 속도가 빨라지면 인증 및 권한 부여를 앱에 통합하는 것이 불가능해집니다.
각 앱이 적절한 액세스 프로토콜을 유지하도록 하면 더 심각한 경우에는 간과되어 정보 유출로 이어질 수 있습니다.
SSO 기술을 사용하면 하나의 자격 증명 집합을 위해 보안을 향상시킬 수 있지만 개발자는 여전히 SSO 시스템과 인터페이스하기 위해 앱에 코드를 포함해야 합니다.
더 좋은 방법이 있습니다. 인증 및 권한 부여를 Ingress Controller로 오프로드(offload)하는 것입니다.
Ingress Controller는 이미 클러스터에 들어오는 모든 트래픽을 조사하고 적절한 서비스로 라우팅하기 때문에 중앙 집중식 인증 및 권한 부여를 위한 효율적인 선택입니다.
이를 통해 개발자는 애플리케이션 코드에서 로직을 구축, 유지 관리 및 복제해야 하는 부담을 덜 수 있습니다.
대신 기본 Kubernetes API를 사용하여 수신 계층에서 SSO 기술을 빠르게 활용할 수 있습니다.
1-4. 사용 사례(Use Case): Guardrails로 셀프 서비스 설정
솔루션(Solution): RBAC(역할 기반 액세스 제어) 구현
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): Kubernetes 종단 간 암호화 구현
솔루션(Solution): 트래픽 관리 도구 사용
종단 간 암호화(E2EE)는 민감한 개인 정보를 처리하는 조직에서 점점 더 일반적인 요구 사항이 되고 있습니다.
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가 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 모드인 경우에도 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.
Kubernetes 앱 보안에 대해 다양하고 자세한 방법을 알아보려면 NGINX STORE 블로그의 Kubernetes 카테고리를 참고하세요.
댓글을 달려면 로그인해야 합니다.