OWASP Kubernetes Top Ten

 

OWASP Foundation 은 Kubernetes를 채택할 때 애플리케이션과 인프라에 위협이 될 수 있는 10개 위험을 소개하였다. 

 

1. K01:2022 안전하지 않은 워크로드 구성
2. K02:2022 공급망 취약성
3. K03:2022 지나치게 허용적인 RBAC 구성
4. K04:2022 중앙 집중식 정책 집행 부족
5. K05:2022 부적절한 로깅 및 모니터링
6. K06:2022 손상된 인증 메커니즘
7. K07:2022 누락된 네트워크 세분화 제어
8. K08:2022 비밀 관리 실패
9. K09:2022 잘못 구성된 클러스터 구성 요소
10. K10:2022 오래되고 취약한 Kubernetes 구성 요소

이 10가지에 대해 알아보자.

 

안전하지 않은 워크로드 구성

Kubernetes에서 워크로드의 보안 컨텍스트는 고도로 구성 가능하므로 조직의 워크로드 및 클러스터 전체에 심각한 보안 구성 오류가 전파될 수 있다. 이러한 구성의 몇 가지 예는 다음과 같다.

 

응용 프로그램 프로세스는 루트로 실행하면 안 된다.

apiVersion: v1  
kind: Pod  
metadata:  
  name: root-user
spec:  
  containers:  
	...
  securityContext:  
    #root user
    runAsUser: 0

권한이 있는 컨테이너는 허용되지 않아야 합니다 . 컨테이너를 Kubernetes 내로 설정하면 privileged컨테이너 자체가 호스트 자체의 추가 리소스 및 커널 기능에 액세스할 수 있다. 

apiVersion: v1  
kind: Pod  
metadata:  
  name: privileged-pod
spec:  
  containers:  
	...
  securityContext:  
    #priviliged 
    privileged: true

이러한 문제를 예방하려면

Open Policy Agent나 Kyverno와 같은 도구를 정책 엔진으로 사용하여 이러한 일반적인 구성 오류를 감지할 수 있다. 그리고 Kubernetes용 CIS 벤치마크 ( Kube-bench 등) 는 잘못된 구성을 발견하기 위한 출발점으로도 사용할 수 있다.

 

공급망 취약점

소프트웨어 공급망 취약성은 전체 개발자 생태계에 큰 위험이며 Kubenetes와 컨테이너도 예외는 아니다. 잠재적으로 수많은 타사 소스의 계층화된 이미지를 사용하면 각각 잠재적인 위험을 나타내는 수백 개의 타사 소프트웨어 종속성이 포함될 수 있다.

 

컨테이너화된 애플리케이션 내에서 이러한 위험을 줄이기 위한 여러 단계가 있다.

 

• SBOM (Software Bill of Materials) : SBOM은 지정된 소프트웨어 아티팩트가 포함하고 다른 보안 검사의 시작점으로 사용해야 하는 소프트웨어 패키지, 라이센스 및 라이브러리 목록을 제공한다.
• 이미지 구성 : 컨테이너 이미지는 최소한의 OS 패키지 및 종속성을 사용하여 생성되어 워크로드가 손상될 경우 공격 표면을 줄여야 한다. Distroless 또는 Scratch 와 같은 대체 기본 이미지를 활용하여 보안 태세를 개선할 뿐만 아니라 취약성 스캐너에서 생성되는 노이즈를 대폭 줄여야 한다.
• 이미지 서명 : 컨테이너 이미지 변조를 감지
• 이미지 취약성 검사 : Trivy 또는 Clair와 같은 오픈소스 등을 활용하여 CVE와 같은 알려진 취약점에 대해 컨테이너 이미지를 정적으로 분석
• 정책 적용 : 승인되지 않은 이미지를 거부할 수 있는 Open Policy Agent나 Kyverno 정책 엔진 사용

지나치게 허용적인 RBAC 구성

Kubernetes 배포에서 생성된 첫 번째 계정은 cluster-admin이다. (예 : /root/.kube/config). 이것은 사실상 슈퍼 사용자이며 클러스터의 모든 구성 요소에 대한 무제한 액세스 권한을 가진다. cluster-admin 사용을 제한하는 것은 공격 표면과 클러스터 무결성에 대한 위험을 줄이는 첫 번째 단계이다.

 

이를 예방하려면

 

• 가능한 경우 최종 사용자의 직접 클러스터 액세스를 줄여야 한다.
• 클러스터 외부에서 서비스 계정 토큰을 사용을 제한
• 기본 서비스 계정 토큰 자동 마운트 방지
• 설치된 타사 구성 요소에 포함된 감사 RBAC
• 위험한 RBAC 권한을 감지하고 차단하는 중앙 집중식 정책 배포
• RoleBindings특정 네임스페이스와 클러스터 전체 RBAC 정책에 대한 권한 범위를 제한하는 데 활용

중앙 집중식 정책 집행 부족

여러 클러스터, 클라우드 및 위험 허용 범위에 걸쳐 보안 정책을 배포하고 적용하는 것은 보안 팀이 빠르게 관리할 수 없게된다. 

 

예를들어, 특정 클러스터에서 악성 이미지가 실행되지 않도록 하려면 이미지 레지스트리를 명시적으로 허용하는 차단 허용 제어 정책을 배포하는 것이 좋다. 이러한 경우에는 Open Policy Agent나 Kyverno 정책 엔진 사용을 사용하여 예방을 할 수 있다.

 

부적절한 로깅 및 모니터링

Kubernetes 배포에 대한 로깅 및 모니터링이 부적절하거나 반대로 너무 많으면 클러스터의 다양한 구성 요소 수준에서 발생하는 상황이나 민감한 정보 노출에 대한 가시성이 부족할 수 있다.

• Kubernetes 감사 로그 : 로그인 시도를 포함하여 Kubernetes API에 대한 작업 로깅.
• Kubernetes 이벤트 : Kubernetes 이벤트는 리소스 할당량 초과 또는 보류 중인 포드와 같은 Kubernetes 리소스 상태 변경 및 오류와 정보 메시지
• 컨테이너 로그 : 애플리케이션 수준 로깅은 종종 민감한 정보를 노출할 수 있습니다. 안전한 로그 전달 방법 (예: EFK 구성 등) 을 사용하면 이러한 위험을 완화하는 데 도움이 될 수 있다.
• 운영 체제 로그 : Kubernetes 노드를 실행하는 OS에 따라 추가 로그를 처리할 수 있다.
• 네트워크 로그 : 여러 계층에서 Kubernetes 내에서 네트워크 로그를 캡처할 수 있다. 기존 프록시 또는 nginx 와 같은 인그레스 구성 요소로 작업하는 경우 표준 출력 stdout및 표준 오류 stderr패턴을 사용하여 추가 조사를 위해 이러한 로그를 캡처하고 전달해야 한다. eBPF 와 같은 프로젝트는 소비 가능한 네트워크 및 커널 로그를 제공하여 클러스터 내에서 보안 관찰 가능성을 향상시키는 것을 목표로 한다.

손상된 인증 메커니즘

Kubernetes에는 2가지 주요 인증 유형이 있다.

• 운영자 인증 : 로그인하고 API에 대해 수동 상호 작용을 수행하는 사용자
• 서비스 계정 인증 : API에 대한 자동화된 작업

일반적으로 사용자가 클러스터에서 처음 구성되면 클러스터 관리자가 되며 인증서 인증을 사용하여 설정된다. 하지만 쿠버네티스에는 인증서 해지 개념이 없기 때문에 인증서가 유출되면 클러스터 내 전체 인증서 체인을 재발급하지 않고는 접근을 쉽게 거부할 방법이 없다.

 

OIDC와 같은 잘 알려진 ID 표준을 사용하면 수명이 짧은 토큰을 사용하여 인증할 수 있고, MFA와 같은 추가 제어를 허용하여 위험을 줄일 수 있다.

 

누락된 네트워크 세분화 제어

여러 마이크로 서비스 및 테넌트로 Kubernetes를 운영할 때 주요 관심 영역은 네트워크 트래픽 제어에 관한 것이다. 

워크로드 및 클러스터 아키텍처의 유형에 따라 네트워크 세그먼트를 생성하는 여러 가지 방법이 있다.

 

• 다중 클러스터 :  Kubernetes 내에서 네트워크 격리를 진정으로 시행하는 한 가지 방법은 적절한 경우 별도의 클러스터를 활용하는 것이다. 이것은 밀접하게 결합된 마이크로 서비스로 작업할 때 복잡성을 추가하지만 위험에 따라 다른 테넌트를 분리할 때 실행 가능한 옵션이다.
• NetworkPolicies : 네트워크 정책은 Kubernetes 자체에 내장되어 있으며 방화벽 규칙처럼 작동한다. 네트워크 정책이 없으면 모든 포드가 다른 포드와 통신할 수 있다. 명시적으로 구성되지 않은 모든 것을 거부하면서 정의된 자산으로만 포드 통신을 제한하도록 네트워크 정책을 정의해야 한다. 또한, Project Calico 및 Cilium 과 같은 솔루션은 모두 Kubernetes 컨텍스트 내에서 네트워크 트래픽을 격리하기 위한 다양한 메커니즘을 제공한다.
• ServiceMesh : 서비스 메시는 서비스 검색, mTLS 및 세분화를 위한 보안 규칙과 같은 확장 가능한 기능을 허용하는 Kubernetes 네트워킹에 대한 오버레이이다.

비밀 관리 실패

Kubernetes에는 기본 시크릿 유형이 있어 세분화된 액세스 제어가 가능하고 적절한 시크릿에 대한 액세스가 필요한 엔터티만 수행하도록 한다. Kubernetes 비밀은 암호화 되지 않고 base64로 인코딩되어 저장된다. 즉, 특정 비밀을 읽을 수 있는 액세스 권한이 있는 사람은 누구나 암호를 해독하고 일반 텍스트로 볼 수 있다. 이것은 비밀이 비밀로 유지되도록 하기 위해 약간의 주의가 필요함을 의미한다.

 

비밀 관리를 위해 다음과 같은 기능을 검토해야 한다.

 

비밀 관리 암호화 : Kubernetes 비밀 암호화 기능을 사용하거나 전체 디스크 암호화 사용을 고려한다. ( https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ )

RBAC 구성 :  비밀 액세스와 관련하여 모든 서비스 계정 및 최종 사용자 액세스를 최소 권한으로 유지한다.

외부 KMS : Azure KeyVault 또는 Hashicorp Vault와 같은 KMS를 이용하여 비밀이 디스크에 저장되지 않도록 한다.

 

잘못 구성된 클러스터 구성 요소

Kubernetes 클러스터는 etcd 내의 키-값 저장소, kube-apiserver, kubelet 등 다양한 구성 요소로 인해 손상된다. 이러한 각 구성 요소에는 CIS(Center for Internet Security)에서 설정한 구성에 대한 모범 사례가 있다. 

 

오래되고 취약한 Kubernetes 구성 요소

모든 소프트웨어와 마찬가지로 Kubernetes 및 외부 통합 구성 요소는 취약성이 있다. 패치 관리는 Kubernetes 및 노드 호스트뿐만 아니라 인그레스 컨트롤러 및 서비스 메시와 같은 기타 추가 구성 요소에도 중요하며 비즈니스 내에서 사용되는 다른 패치 관리 절차 내에서 관리되어야 한다.

 

다음과 같은 CVE 데이터베이스를 참고한다.

Istio 보안 게시판: https://istio.io/latest/news/security/

CVE 데이터베이스 키워드 "Kubernetes": https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=kubernetes

Kubernetes 보안 및 공개 정보: https://kubernetes.io/docs/reference/issues-security/security/

 

참고

https://owasp.org/www-project-kubernetes-top-ten/