해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 14 - An introduction to API Security in Kubernetes
1. 쿠버네티스 API 서버 보안
쿠버네티스 API 서버는 쿠버네티스 클러스터의 '두뇌'이자 모든 관리 작업의 관문으로, API 서버를 보호하는 것은 쿠버네티스 보안의 가장 기본적이고, 중요한 첫걸음이다.
1-1. 전송 보안 (Transport Security)
모든 클러스터 컴포넌트 간 통신은 암호화 되어야한다.
kubeadm과 같은 표준 도구를 사용하면 TLS 인증서 설정이 자동으로 처리된다.
하지만 해당 과정을 깊이 이해하고 싶다면, "Kubernetes the Hard Way" 가이드를 통해 직접 인증서를 생성하고 컴포넌트를 연결해보는 것이 좋다.
1-2. 인증 (Authentication)
"누가 집 안으로 들어올 수 있는가?"를 결정하는 과정이다.
쿠버네티스는 자체적인 사용자 계정 시스템이 없으므로, 보통 'OpenID Connect (OIDC)' 와 같은 제 3자 인증 시스템과 연동하여 사용자를 식별하고 클러스터 접근을 허용한다.
1-3. 인가 (Authorization)
"집안의 어느 방에 들어갈 수 있는가?"를 결정하는 과정이다.
즉, 인증된 사용자가 클러스터 내에서 무엇을 할 수 있는지 권한을 부여하는 단계이다.
이를 위해 RBAC (Role-Based Access Control, 역할 기반 접근 제어) 를 사용하는 것이 필수적이다. 보통, RBAC을 통해 사용자나 어플리케이션별로 필요한 최소한의 권한만 부여하여 보안을 강화할 수 있다.
1-4. etcd 보안
etcd는 쿠버네티스 클러스터의 모든 상태 정보 (어떤 Pod가 실행 중인지, 어떤 설정이 적용되었는지 등) 를 저장하는 핵심 데이터베이스 이다.
만약 공격자가 etcd에 직접 접근할 수 있다면, 클러스터의 모든 것을 조작하거나 파괴할 수 있으므로, etcd에 대한 접근을 엄격히 통제하고, 필요하다면 저장된 데이터를 암호화하는 조치를 취해야 한다.
1-5. 최신 버전 유지
보안 취약점은 계속해서 발견되고 패치된다.
너무 최신 버전을 사용하는 것은 안정성 문제가 있을 수 있지만, 너무 오래된 버전을 사용하는 것은 알려진 보안 위협에 그대로 노출되는 것을 의미하므로, 보안 패치와 개선 사항이 적용된 비교적 최신 버전의 쿠버네티스를 유지하는 것이 중요하다.
2. 쿠버네티스 어플리케이션 보안
(왜 WAF가 필요한가)
API 서버 모안이 클러스터 자체를 보호하는 것이라면, 어플리케이션 보안은 클러스터 위에서 실행되는 실제 서비스들을 보호하는 것에 중점을 둔다.
해당 강의에서는 실제 서비스를 보호하는 부분에 더 많은 관심이 필요하다고 강조하며, 그 해결책으로 '웹 어플리케이션 방화벽 (WAF, Web Application Firewall)'을 제시한다.
2-1. 취약점으로부터 보호
WAF를 사용해야 하는 가장 명백한 이유로, 새로운 보안 취약점 (Exploit)이 발견되고 나서 개발자들이 해당 어플리케이션의 패치를 내놓기까지는 시간적 공백이 발생한다.
WAF는 이 시간 동안 알려진 공격 패턴을 기반으로 악의적인 트래픽을 차단하여, 패치가 적용되기 전에도 어플리케이션을 보호해주는 역할을 한다.
2-2. 규정 준수 및 데이터 보안 (Compliance)
많은 산업 분야에서는 엄격한 보안 규정을 따라야 한다.
WAF를 도입하는 것은 데이터를 보호하기 위한 적극적인 노력을 증명하는 것이며, 이는 규정 준수 요건을 충족하는 데 큰 도움이 된다.
2-3. 모니터링 및 로깅 강화
WAF는 애플리케이션으로 들어오는 모든 트래픽을 검사하므로, 어떤 종류의 공격 시도가 있었는지에 대한 상세한 로그를 제공한다.
이는 보안 위협을 모니터링하고 사고 발생 시 원인을 분석하는 데 매우 유용한 추가 데이터를 제공하게 된다.
2-3. 모니터링 및 로깅 강화
WAF는 애플리케이션으로 들어오는 모든 트래픽을 검사하므로, 어떤 종류의 공격 시도가 있었는지에 대한 상세한 로그를 제공한다.
이는 보안 위협을 모니터링하고 사고 발생 시 원인을 분석하는 데 매우 유용한 추가 데이터를 제공하게 된다.
2-4. 머신러닝을 통한 적응형 보안
최신 WAF는 단순히 알려진 공격 패턴만 차단하는 것을 넘어, 머신러닝(Machine Learning) 기술을 활용한다.
정상적인 트래픽 패턴을 학습한 뒤, 비정상적이거나 의심스러운 요청이 들어오면 아직 알려지지 않은 새로운 유형의 공격(Zero-day Attack)이라도 차단할 수 있는 적응형 보안 능력을 갖추어져 있다.
2-5. API 보안 및 쿠버네티스 네이티브 통합
WAF는 쿠버네티스 환경에 자연스럽게 통합될 수 있어야 한다.
예시 -> AWS 환경에서는 AWS WAF를, 베어메탈 환경에서는 OpenAppsec 같은 솔루션을 사용하는 것이 좋다.
또한, CI/CD 파이프라인에 통합하여 개발 초기 단계부터 보안을 자동화하는 것이 좋다.
3. 취약점과 관련 기술
WAF가 막아야할 대표적인 위협들의 예들이 존재한다.
3-1. 대표적인 취약점 사례
- Log4Shell : 2021년 말에 발생한 Java 로깅 라이브러리 (Log4j)의 치명적인 취약점이다. 공격자가 원격으로 서버에서 임의의 코드를 실행할 수 있게 했다.
- Spring4Shell : Log4Shell과 유사하게, Java의 Spring 프레임워크에서 발견된 취약점으로, 역시 원격 코드 실행이 가능했다.
3-2. 주요 공격 기술
-
SQL 인젝션 (SQL Injection) : 웹사이트의 입력 필드에 악의적인 SQL 쿼리를 주입하여 데이터베이스를 비정상적으로 조작하거나 정보를 탈취하는 공격
-
크로스 사이트 스크립팅 (Cross-Site Scripting, XSS) : 공격자가 웹사이트에 악성 스크립트를 삽입하여 다른 사용자의 브라우저에서 실행되게 만드는 공격
-
크로스 사이트 요청 위조 (Cross-Site Request Forgery, CSRF) : 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위 (글쓰기, 정보 수정 등)를 특정 웹사이트에 요청하게 만드는 공격
-
세션 고정 (Session Fixation) : 공격자가 사용자의 Session ID를 미리 알아내고, 해당 세션으로 사용자가 로그인하도록 유도하여 세션을 가로채는 공격
4. OpenAppsec Demo 시연
해당 강의에서는 OpenAppsec 플랫폼 플레이그라운드를 통하여 웹 어플리케이션 방화벽이 어떻게 우리의 API를 보호하는지 기본적으로 확인할 수 있다.
OpenAppsec Playground 관련 링크
https://www.openappsec.io/playground
데모 1단계: 공격 대상 확인 및 공격 준비
먼저 쿠버네티스 클러스터에서 보안에 취약한 'Acme Audit' 웹 애플리케이션이 실행 중임을 확인한다. 터미널에 kubectl get pods -A 명령어를 입력하여 webapp 네임스페이스에 acmeaudit 파드가 정상적으로 실행되고 있는 것을 확인할 수 있다.
이 단계의 목표는 인증 메커니즘을 우회하는 SQL 인젝션 공격을 수행하는 것입니다. 화면 좌측의 지시사항에는 로그인 시 사용할 악의적인 SQL 구문(' or 1=1--)이 명시되어 있다.
데모 2단계: SQL 인젝션 공격 수행
'Acme Audit' 애플리케이션의 로그인 페이지에 접속하여, 지시사항에 따라 사용자 이름(Username) 필드에 SQL 인젝션 구문(' or 1=1--)을 입력하고, 비밀번호(Password)는 아무렇게나 입력한다.
해당 구문은 데이터베이스 쿼리 조건을 항상 참(True)으로 만들어, 비밀번호가 무엇이든 인증을 통과시키도록 설계되어있다.
데모 3단계: 공격 성공 및 기밀 정보 탈취
로그인 버튼을 클릭하자, SQL 인젝션 공격이 성공하여 인증 과정이 완전히 우회되었음을 알 수 있다. 사용자는 정상적으로 로그인한 것처럼 애플리케이션 내부에 접근할 수 있게 된 것이다.
화면에는 원래 감사 및 재무 담당자에게만 허용되어야 할 회사의 기밀 정보인 '통합 손익 계산서'가 표시됨을 알 수 있으며, 이를 통해 애플리케이션이 외부 공격에 매우 취약하다는 사실이 증명되었다.
데모 4단계: 방어 솔루션(WAF) 설치 및 정책 설정
공격에 성공함을 확인후, 이를 방어하기 위해 웹 애플리케이션 방화벽(WAF)인 OpenAppsec을 설치한다.
설치 과정에서 다음과 같은 주요 설정을 진행한다.
-
Ingress 선택: 기존에 애플리케이션이 사용하던 Ingress를 복제하여 보호하도록 설정
-
정책(Policy) 설정: WAF의 작동 방식을 정의한다. 기본 정책으로 Mode가 prevent-learn(방어 및 학습)으로, 공격 감지 시 Web Response가 403-forbidden(접근 거부)으로 설정된 것을 확인하고 저장한다.
데모 5단계: WAF 설치 완료
설정 저장을 완료하면 OpenAppsec WAF가 Helm을 통해 쿠버네티스 클러스터에 성공적으로 배포된다.
터미널 화면에는 "Installation completed!" 메시지가 표시되며, WAF가 이제 애플리케이션으로 들어오는 트래픽을 감시하고 보호할 준비가 되었음을 의미한다.
데모 6단계: WAF 방어 테스트 (공격 재시도)
WAF가 설치된 상태에서, 앞서 성공했던 것과 완전히 동일한 SQL 인젝션 공격을 다시 시도한다.
이번에는 악의적인 요청이 애플리케이션에 도달하기 전에 WAF가 먼저 이를 탐지하고 차단한다.
그 결과, 사용자는 기밀 정보 대신 "액세스가 거부됨"이라는 메시지와 함께 "HTTP ERROR 403" 페이지를 보게 된다. 이는 4단계에서 설정한 방어 정책이 성공적으로 작동했음을 보여줍니다.
데모 7단계: 로그를 통한 공격 차단 증거 확인
마지막으로, WAF가 공격을 제대로 탐지하고 차단했는지 증거를 확인하기 위해 로그를 살펴본다.
로그는 JSON 형식으로 기록되어 있으며, 다음과 같은 핵심 정보를 통해 공격 차단 사실을 알 수 있게 된다.
- "securityAction": "Prevent" : 보안 조치가 방어였음을 의미한다.
- "waapIncidentType": "SQL Injection" : 탐지된 공격 유형이 'SQL 인젝션'임을 알려준다.
- "matchedSample": "' or 1=1--" : 공격에 사용된 악성 코드 기록
해당 로그들은 WAF가 의도한 대로 정확하게 작동하여 애플리케이션을 성공적으로 보호했음을 증명한다.
5. 결론: WAF를 통한 애플리케이션 보호의 중요성
데모를 통해 알 수 있듯, 애플리케이션 자체에 취약점이 존재하더라도 웹 애플리케이션 방화벽(WAF)은 외부 공격을 효과적으로 막아내는 필수적인 보안 계층 역할을 한다.
다수의 어플리케이션과 클러스터를 운영하는 환경에서는 개별 로그들을 일일이 확인 하기 어렵다. OpenAppsec과 같은 솔루션이 제공하는 중앙 관리 콘솔을 활용하면 모든 보안 이벤트를 통합하여 효율적으로 모니터링하고 관리할 수 있다.
또한, 어떤 WAF를 선택하는지는 중요하지만, 더 중요한 것은 반드시 사용해야 한다는 사실이다.
AWS 환경에서는 네이티브 AWS WAF를, 베어메탈(Bare-metal) 환경에서는 OpenAppsec과 같은 솔루션을 사용하는 등 자신의 환경에 가장 적합한 도구를 선택하는 것이 좋습니다.
가장 중요한 점은 쿠버네티스 환경에서 애플리케이션 API를 절대로 보호되지 않은 상태로 두어서는 안 된다는 것이다.
