Kubernetes hardening guidance

Executive summary

Kubernetes®는 컨테이너에서 실행되는 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 시스템이며 종종 클라우드 환경에서 호스팅됩니다. 이러한 유형의 가상화된 인프라를 사용하면 기존의 모놀리식 소프트웨어 플랫폼에 비해 여러 가지 유연성과 보안 이점을 제공할 수 있습니다. 그러나 마이크로서비스에서 기본 인프라에 이르기까지 모든 것을 안전하게 관리하면 다른 복잡성이 발생합니다.

이 보고서는 조직이 Kubernetes 관련 위험을 처리하고 이 기술을 사용하여 이점을 누릴 수 있도록 설계되었습니다.

Kubernetes의 세 가지 일반적인 손상 소스는 공급망 위험, 악의적인 위협 행위자 및 내부 위협입니다.

공급망 위험은 완화하기 어려운 경우가 많으며 컨테이너 구축 주기 또는 인프라 인수에서 발생할 수 있습니다.

악의적인 위협 행위자는 control plane, Worker nodes 또는 컨테이너화된 애플리케이션과 같은 Kubernetes 아키텍처 구성 요소의 취약성과 잘못된 구성을 악용할 수 있습니다.

내부 위협은 관리자, 사용자 또는 클라우드 서비스 공급자일 수 있습니다.

조직의 Kubernetes 인프라에 대한 특별한 액세스 권한이 있는 내부자는 이러한 권한을 남용할 수 있습니다.

이 가이드에서는 Kubernetes 클러스터 설정 및 보안과 관련된 보안 문제에 대해 설명합니다.

여기에는 National Security Systems의 시스템 관리자 및 개발자를 위한 전략이 포함되어 있어 일반적인 구성 오류를 방지하고 Kubernetes를 배포할 때 권장되는 강화 조치 및 완화를 구현할 수 있습니다.

이 가이드에서는 다음 완화 사항에 대해 자세히 설명합니다.

• 취약성 또는 잘못된 구성에 대해 컨테이너 및 Pod를 스캔합니다.

• 가능한 최소한의 권한으로 컨테이너와 파드를 실행합니다.

• 네트워크 분리를 사용하여 손상이 발생할 수 있는 피해량 제어

• 방화벽을 사용하여 불필요한 네트워크 연결을 제한하고 암호화를 사용하여 기밀을 보호합니다.

• 강력한 인증 및 권한 부여를 사용하여 사용자 및 관리자 제한 접근하고 공격 지점을 제한합니다.

• 관리자가 악의적인 활동의 잠재적인 상황에 대해 경고할 수 있도록 감사 로그를 캡처하고 모니터링한다.

• 정기적으로 모든 Kubernetes 설정을 검토하고 취약점 스캔을 사용하여 위험이 적절하게 고려되고 보안 패치가 적용됩니다.

추가 보안 강화 지침은 Center for Internet Security Kubernetes 벤치마크, Docker 및 Kubernetes 보안 기술 구현 가이드, CISA(Cybersecurity and Infrastructure Security Agency) 분석 보고서, Kubernetes 문서 [1], [2], [3]를 참조하십시오., [6].

Introduction

K와 S 사이에 8자가 있기 때문에 종종 "K8s"로 약칭되는 Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 데 사용되는 open-source container-orchestration system 입니다.

다음 그림과 같이 애플리케이션의 각 마이크로 서비스에서 전체 클러스터에 이르기까지 클러스터를 구성하는 모든 요소를 관리합니다.

컨테이너화된 애플리케이션을 마이크로서비스로 사용하면 모놀리식 소프트웨어 플랫폼에 비해 더 많은 유연성과 보안 이점을 제공하지만 다른 복잡성을 유발할 수도 있습니다.

이 가이드는 보안 문제에 중점을 두고 국가 안보 시스템 및 중요 인프라 관리자를 위한 강화 전략을 제안합니다.

이 가이드는 국가 안보 시스템 및 주요 기반 시설 조직에 맞게 제작되었지만 NSA 및 CISA는 연방 및 주, 지방, 부족 및 테리토리(SLTT) 정부 네트워크의 관리자가 이 가이드의 권장 사항을 구현하도록 권장합니다.

Kubernetes 클러스터는 보안이 복잡할 수 있습니다.그리고 종종 잘못된 구성을 악용하는 절충안이 남용됩니다.

이 가이드는 보다 안전한 Kubernetes 클러스터를 구축하는 데 도움이 될 수 있는 특정 보안 구성을 제공합니다.

Recommendations

각 섹션의 주요 권장 사항을 요약하면 다음과 같습니다.

• Kubernetes Pod security (쿠버네티스 포드 보안)

  • 루트가 아닌 사용자로 애플리케이션을 실행하도록 구축된 컨테이너를 사용합니다.

  • 가능한 경우 변경할 수 없는 파일 시스템으로 컨테이너를 실행합니다.

  • 가능한 취약성 또는 잘못된 구성에 대해 컨테이너 이미지를 스캔합니다.

  • 다음을 포함하여 최소한의 보안 수준을 적용하기 위해 기술 제어를 사용합니다.

    • 권한 있는 컨테이너는 금지합니다.

    • hostPID, hostIPC, hostNetwork allowedHostPath와 같이 자주 악용되는 컨테이너 기능을 거부합니다.

    • 루트 사용자로 실행하거나 루트 권한 상승을 허용하는 컨테이너를 거부합니다.

    • SELinux®, AppArmor® 및 보안 컴퓨팅 모드(seccomp)와 같은 보안 서비스를 사용하여 악용에 대해 애플리케이션을 강화합니다.

• 네트워크 분리 및 강화

  • 방화벽 및 RBAC를 사용하여 control plane 노드에 대한 액세스를 잠급니다.control plane 구성 요소 및 노드에 대해 별도의 네트워크를 사용합니다.

  • Kubernetes etcd 서버에 대한 액세스를 추가로 제한합니다.

  • 인증, 암호화를 사용하도록 control plane 구성 요소 구성, TLS(전송 계층 보안) 인증서를 사용한 통신.

  • 저장된 etcd를 암호화하고 별도의 TLS 인증서를 사용하여 통신합니다.

  • 네트워크 정책을 설정하여 리소스를 격리합니다.다른 네임스페이스에 있는 Pod와 서비스는 추가 분리가 적용되지 않는 한 여전히 서로 통신할 수 있습니다.

  • 명시적 deny network policy을 만듭니다.

  • 구성 파일이 아닌 Kubernetes Secrets에 암호화된 모든 자격 증명 및 민감한 정보를 배치합니다.강력한 암호화 방법을 사용하여 비밀을 암호화합니다.비밀은 기본적으로 암호화되지 않습니다.

• 인증 및 권한 부여

  • 익명 로그인을 비활성화합니다(기본적으로 활성화됨)

  • 강력한 사용자 인증을 사용하십시오.

  • 사용자, 관리자, 개발자, 서비스 계정 및 인프라 팀에 대해 고유한 역할을 가진 RBAC 정책을 생성합니다.

• 감사 로깅 및 위협 탐지

  • 감사 로깅을 활성화합니다(기본적으로 비활성화되어 있음).

  • 노드, 포드 또는 컨테이너 수준 오류의 경우 가용성을 보장하기 위해 로그를 유지합니다.

  • 환경 전반에 걸쳐 로깅을 구성합니다(예: 클러스터 API(애플리케이션 프로그램 인터페이스) 감사 이벤트 로그, 클러스터 메트릭 로그, 애플리케이션 로그, Pod seccomp 로그, 리포지토리 감사 로그 등)

  • 클러스터 외부의 로그를 집계합니다.

  • 조직의 클러스터에 맞는 로그 모니터링 및 경고 시스템을 구현합니다.

• 업그레이드 및 애플리케이션 보안 관행

  • 보안 패치 및 업데이트를 즉시 적용합니다.

  • 주기적으로 취약점 스캔 및 침투 테스트를 수행합니다.

  • 사용하지 않는 구성 요소를 환경에서 제거하고 삭제합니다.

Architectural overview (아키텍쳐 개요)

control plane은 클러스터에 대한 결정을 내립니다.

여기에는 실행할 컨테이너 예약, 실패 감지/대응, 배포 파일에 나열된 복제본 수가 충족되지 않을 때 그리고 새 파드 시작이 포함됩니다.

다음 논리적 구성 요소는 모두 control plane의 일부입니다.

• Controller manager – Kubernetes 클러스터를 모니터링하여 Pod를 서비스에 연결하고, 올바른 수의 Pod를 유지 관리하고, 노드 손실에 대응하는 등 Kubernetes 환경의 여러 측면을 감지 및 유지 관리합니다.

• Cloud Controller manager – 클라우드 기반 배포에 사용되는 선택적 구성 요소입니다.클라우드 컨트롤러는 Cloud Service Provider(클라우드 서비스 공급자)와 인터페이스하여 클러스터에 대한 로드 밸런서 및 가상 네트워킹을 관리합니다.

• Kubernetes application programming interface (API) server – 관리자가 Kubernetes를 지시하는 인터페이스입니다.따라서 API 서버는 일반적으로 Control Plane 외부에 노출됩니다.확장하도록 설계되었으며 여러 Control Plane 노드에 존재할 수 있습니다.

• Etcd – 클러스터 상태에 관한 모든 정보가 보관되는 영구 백업 저장소.Etcd는 직접 조작하는 것이 아니라 API 서버를 통해 관리해야 합니다.

• Scheduler – Worker nodes의 상태를 추적하고 파드를 실행할 위치를 결정합니다.Kube-scheduler는 Control Plane 내에서만 액세스할 수 있습니다.

Kubernetes Worker nodes는 클러스터에 대해 컨테이너화된 애플리케이션을 실행하는 전용 물리적 또는 가상 머신입니다.컨테이너 엔진을 실행하는 것 외에도 Worker nodes는 Control Plane에서 오케스트레이션을 허용하는 다음 두 서비스를 호스팅합니다.

• Kubelet – 각 Worker nodes에서 실행하여 Pod 실행을 오케스트레이션하고 확인합니다.

• Kube-proxy – 호스트의 패킷 필터링 기능을 사용하여 Kubernetes 클러스터에서 올바른 패킷 라우팅을 보장하는 네트워크 프록시입니다.

클러스터는 일반적으로 Cloud Service Provider Kubernetes 서비스 또는 온프레미스 Kubernetes 서비스를 사용하여 호스팅됩니다.Cloud Service Provider는 종종 추가 기능을 제공합니다.관리되는 Kubernetes 서비스의 대부분의 측면을 관리합니다.그러나 기본 Cloud Service Provider 구성은 일반적으로 안전하지 않기 때문에 조직은 인증 및 권한 부여와 같은 일부 Kubernetes 서비스 측면을 처리해야 할 수 있습니다.Kubernetes 환경을 설계할 때 조직은 클러스터를 안전하게 유지 관리하는 책임을 이해해야 합니다.

Threat model(위협 모델)

Kubernetes는 데이터 또는 컴퓨팅 전력 절도의 중요한 대상이 될 수 있습니다. 전통적으로 데이터 도용이 주요 목표지만 컴퓨팅 능력(종종 암호화폐 채굴용)을 추구하는 경우도 있습니다. 리소스 절도 외에도 사이버 공격자는 Kubernetes를 대상으로 DDos를 유발할 수 있습니다. 다음 위협은 Kubernetes 클러스터에 대한 가장 가능성이 높은 경우입니다.

• Supply Chain - 공급망에 대한 공격 방식은 다양하고 완화하기 어렵습니다.위험은 적이 시스템을 구성하는 모든 요소를 전복시킬 수 있다는 것입니다.여기에는 최종 제품을 공급하는 데 도움이 되는 제품 구성 요소, 서비스 또는 직원이 포함됩니다.추가적인 공급망 위험에는 Kubernetes 클러스터를 생성하고 관리하는 데 사용되는 타사 소프트웨어 및 공급업체가 포함될 수 있습니다.공급망 손상은 다음을 비롯한 여러 수준에서 Kubernetes에 영향을 줄 수 있습니다.

  • 컨테이너/애플리케이션 수준 – Kubernetes에서 실행되는 애플리케이션 및 타사 종속성의 보안은 개발자의 신뢰성과 개발 인프라의 방어에 의존합니다.제3자의 악성 컨테이너 또는 애플리케이션은 사이버 범죄자에게 클러스터에 공격 기회를 제공할 수 있습니다.

  • 컨테이너 런타임 – 각 노드에는 저장소에서 컨테이너 이미지를 로드하기 위해 설치된 컨테이너 런타임이 있습니다.로컬 시스템 리소스를 모니터링하고, 각 컨테이너에 대한 시스템 리소스를 격리하고, 컨테이너 수명 주기를 관리합니다.컨테이너 런타임의 취약점으로 인해 컨테이너 간 분리가 불충분할 수 있습니다.

  • 인프라 – Kubernetes를 호스팅하는 기본 시스템에는 자체 소프트웨어 및 하드웨어 종속성이 있습니다.Worker nodes 또는 Control Plane의 일부로 사용되는 시스템이 손상되면 사이버 행위자가 클러스터에 공격 기회를 제공할 수 있습니다.

• Malicious Threat Actor (악의적인 위협 행위자) – 악의적인 행위자는 종종 취약성을 악용하거나 소셜 엔지니어링의 자격 증명을 훔쳐 원격 위치에서 액세스 권한을 얻습니다.Kubernetes 아키텍처는 사이버 범죄자가 원격 악용에 잠재적으로 활용할 수 있는 여러 API를 노출합니다.

  • Control Plane – Kubernetes Control Plane에는 클러스터를 추적하고 관리하기 위해 통신하는 많은 구성 요소가 있습니다.사이버 범죄자는 적절한 액세스 제어가 없는 노출된 Control Plane 구성 요소를 자주 이용합니다.

  • Worker nodes – 컨테이너 엔진을 실행하는 것 외에도 Worker nodes는 사이버 행위자가 잠재적으로 악용할 수 있는 kubelet 및 kube-proxy 서비스를 호스팅합니다.또한 Worker nodes는 잠긴 Control Plane 외부에 존재하며 사이버 범죄자가 더 쉽게 액세스할 수 있습니다.

  • 컨테이너화된 애플리케이션 – 클러스터 내에서 실행되는 애플리케이션은 공통 대상입니다.클러스터 외부에서 자주 액세스할 수 있으므로 원격 사이버 공격자가 액세스할 수 있습니다.그런 다음 액터는 이미 손상된 포드에서 피벗하거나 노출된 애플리케이션의 내부적으로 액세스 가능한 리소스를 사용하여 클러스터 내에서 권한을 에스컬레이션할 수 있습니다.

• 내부자 위협 – 위협 행위자는 조직 내에서 작업하는 동안 취약점을 악용하거나 개인에게 부여된 권한을 사용할 수 있습니다.조직 내 개인에게는 Kubernetes 클러스터에 대해 사용할 수 있는 특별한 지식과 권한이 있습니다.

  • 관리자 – Kubernetes 관리자는 컨테이너화된 환경 내에서 임의의 명령 실행을 포함하여 컨테이너 실행을 제어할 수 있습니다.Kubernetes 시행 RBAC 권한 부여는 민감한 기능에 대한 액세스를 제한하여 위험을 줄일 수 있습니다.그러나 Kubernetes에는 2인 무결성 제어가 없기 때문에 하나 이상의 관리 계정이 클러스터를 제어할 수 있어야 합니다.관리자는 종종 시스템이나 하이퍼바이저에 물리적으로 액세스할 수 있으며 이는 Kubernetes 환경을 손상시키는 데 사용될 수도 있습니다.

  • 사용자 – 컨테이너화된 애플리케이션 사용자는 Kubernetes 클러스터의 컨테이너화된 서비스에 액세스할 수 있는 자격 증명을 알고 있을 수 있습니다.이 수준의 액세스는 응용 프로그램 자체 또는 다른 클러스터 구성 요소를 활용하기에 충분한 수단을 제공할 수 있습니다.

  • 클라우드 서비스 또는 인프라 제공자 – Kubernetes 노드를 관리하는 물리적 시스템 또는 하이퍼바이저에 대한 액세스는 Kubernetes 환경을 손상시키는 데 사용될 수 있습니다.Cloud Service Provider에는 종종 권한 있는 관리자로부터 시스템을 보호하기 위한 기술 및 관리 제어 계층이 있습니다.

Kubernetes Pod security (쿠버네티스 포드 보안)

Pod는 배포 가능한 가장 작은 Kubernetes 단위이며 하나 이상의 컨테이너로 구성됩니다.

Pod는 컨테이너를 악용할 때 사이버 범죄자의 초기 실행 환경인 경우가 많습니다.이러한 이유로 Pod는 악용을 더 어렵게 만들고 성공적인 타협의 영향을 제한하기 위해 강화되어야 합니다.

다음 그림은 Pod의 구성 요소와 가능한 공격 지점을 보여줍니다.

"Non-root" containers and "rootless" container engines

기본적으로 많은 컨테이너 서비스는 권한 있는 루트 사용자로 실행되고 애플리케이션은 권한 있는 실행이 필요하지 않음에도 불구하고 컨테이너 내부에서 루트로 실행됩니다.루트가 아닌 컨테이너 또는 루트가 없는 컨테이너 엔진을 사용하여 루트 실행을 방지하면 컨테이너 손상의 영향이 제한됩니다.두 방법 모두 런타임 환경에 상당한 영향을 미치므로 호환성을 확인하기 위해 응용 프로그램을 철저히 테스트해야 합니다.

• Non-root containers – 컨테이너 엔진을 사용하면 컨테이너가 루트가 아닌 그룹 구성원 자격을 가진 루트가 아닌 사용자로 애플리케이션을 실행할 수 있습니다.일반적으로 이 기본값이 아닌 설정은 컨테이너 이미지가 빌드될 때 구성됩니다.루트가 아닌 사용자로 애플리케이션을 실행하는 Dockerfile의 예는 부록 A: 루트가 아닌 애플리케이션을 위한 Dockerfile의 예를 참조하십시오.또는 Kubernetes는 0이 아닌 사용자를 지정하는 SecurityContext:runAsUser를 사용하여 Pod에 컨테이너를 로드할 수 있습니다.runAsUser 지시문은 배포 시 루트가 아닌 실행을 강제합니다.그러나 NSA 및 CISA는 개발자가 루트가 아닌 사용자로 실행할 컨테이너 응용 프로그램을 빌드하도록 권장합니다.빌드 시 루트가 아닌 실행을 통합하면 루트 권한 없이 애플리케이션이 올바르게 작동할 것이라는 더 나은 확신을 얻을 수 있습니다.

• Rootless container engines – 일부 컨테이너 엔진은 루트로 실행되는 데몬을 사용하는 대신 권한이 없는 컨텍스트에서 실행할 수 있습니다.이 시나리오에서 실행은 컨테이너화된 애플리케이션의 관점에서 루트 사용자를 사용하는 것처럼 보이지만 실행은 호스트에서 엔진의 사용자 컨텍스트에 다시 매핑됩니다.루트가 없는 컨테이너 엔진은 효과적인 보안 계층을 추가하지만 많은 엔진이 현재 실험용으로 출시되어 프로덕션 환경에서 사용해서는 안 됩니다.관리자는 벤더가 Kubernetes와 호환되는 안정적인 버전을 출시할 때 이 새로운 기술을 인식하고 루트 없는 컨테이너 엔진을 채택해야 합니다.

Immutable container file systems

기본적으로 컨테이너는 자체 컨텍스트 내에서 대부분 무제한 실행이 허용됩니다. 컨테이너에서 실행을 얻은 사이버 액터는 파일을 생성하고 스크립트를 다운로드하고 컨테이너 내에서 애플리케이션을 수정할 수 있습니다. Kubernetes는 컨테이너의 파일 시스템을 잠글 수 있으므로 많은 악용 후 활동을 방지할 수 있습니다. 그러나 이러한 제한 사항은 합법적인 컨테이너 응용 프로그램에도 영향을 미치며 잠재적으로 충돌이나 비정상적인 동작을 초래할 수 있습니다. 적법한 애플리케이션이 손상되는 것을 방지하기 위해 Kubernetes 관리자는 애플리케이션에 쓰기 액세스가 필요한 특정 디렉토리에 대해 보조 읽기/쓰기 파일 시스템을 탑재할 수 있습니다. 쓰기 가능한 디렉터리가 있는 불변 컨테이너의 예는 부록 B: 읽기 전용 파일 시스템을 위한 배포 템플릿 예를 참조하세요.

Building secure container images

컨테이너 이미지는 일반적으로 컨테이너를 처음부터 빌드하거나 저장소에서 가져온 기존 이미지 위에 빌드하여 생성됩니다. 개발자 환경 내의 저장소 제어를 사용하여 개발자가 신뢰할 수 있는 저장소만 사용하도록 제한할 수 있습니다. 특정 제어는 환경에 따라 다르지만 승인 제어와 같은 플랫폼 수준 제한과 네트워크 수준 제한이 모두 포함될 수 있습니다. Kubernetes admission controllers, 타사 도구 및 일부 Cloud Service Provider 기본 솔루션은 디지털 서명된 이미지만 클러스터에서 실행할 수 있도록 항목을 제한할 수 있습니다. 신뢰할 수 있는 리포지토리를 사용하여 컨테이너를 구축하는 것 외에도 이미지 스캔은 배포된 컨테이너의 보안을 보장하는 핵심입니다. 컨테이너 빌드 워크플로 전체에서 이미지를 스캔하여 오래된 라이브러리, 알려진 취약점 또는 안전하지 않은 포트나 권한과 같은 잘못된 구성을 식별해야 합니다. 스캐닝은 또한 지식이 있는 경우 취약성 감지에 대한 오탐지를 무시할 수 있는 유연성을 제공해야 합니다. 사이버 보안 전문가들은 경고가 정확하지 않다고 간주했습니다. 다음 그림에서 볼 수 있듯이 이미지 스캐닝을 구현하는 한 가지 접근 방식은 admission controller를 사용하는 것입니다. admission controller는 개체가 지속되기 전에 요청이 인증되고 권한이 부여된 후에 Kubernetes API에 대한 요청을 가로채서 처리할 수 있는 Kubernetes 기본 기능입니다. 사용자 지정 또는 독점 웹훅을 구현하여 이미지를 클러스터에 배포하기 전에 스캔할 수 있습니다. 이 admission controller는 이미지가 웹훅 구성[4]에 정의된 조직의 보안 정책을 준수하지 않는 경우 배포를 차단할 수 있습니다.

11 Ways (Not) to Get Hacked https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/

Pod security enforcement

Pod에 보안 요구 사항을 적용하는 것은 기본적으로 두 가지 메커니즘을 통해 Kubernetes에서 수행할 수 있습니다.

1.Pod 보안 승인이라고 하는 베타1 릴리스 기능 – 프로덕션 Kubernetes 관리자는 이 기능이 Kubernetes 버전 1.23에서 기본적으로 활성화되어 있으므로 Pod 보안 승인을 채택해야 합니다.포드 보안 승인은 포드를 특권, 기준 및 제한으로 분류하는 것을 기반으로 하며 PSP보다 더 간단한 구현을 제공합니다.Pod 보안 승인에 대한 자세한 내용은 온라인 설명서2에서 확인할 수 있습니다.

2.포드 보안 정책(PSP)이라고 하는 더 이상 사용되지 않는 기능 - 포드 보안 승인으로 전환하는 동안 PSP를 사용하는 관리자는 부록 C: 포드 보안 정책의 정보를 사용하여 PSP를 강화할 수 있습니다.

기본 Kubernetes 솔루션 외에도 Kubernetes admission controllers로 자주 구현되는 타사 솔루션은 추가로 세분화된 정책 제어를 제공할 수 있습니다.이러한 솔루션은 이 문서의 범위를 벗어나지만 관리자는 자신의 환경에 사용할 수 있는 제품을 탐색하여 요구 사항에 가장 적합한 솔루션을 결정할 수 있습니다.

Protecting Pod service account tokens (Pod 서비스 계정 토큰 보호)

기본적으로 Kubernetes는 포드를 생성할 때 서비스 계정을 자동으로 프로비저닝하고 런타임 시 포드 내에 계정의 비밀 토큰을 탑재합니다. Kubernetes 오케스트레이션이 백그라운드에서 투명하게 발생하므로 많은 컨테이너화된 애플리케이션은 서비스 계정에 직접 액세스할 필요가 없습니다. 애플리케이션이 손상되면 사이버 범죄자가 Pod의 계정 토큰을 수집하여 클러스터를 추가로 손상시키는 데 사용할 수 있습니다. 애플리케이션이 서비스 계정에 직접 액세스할 필요가 없는 경우 Kubernetes 관리자는 Pod 사양이 탑재되는 비밀 토큰을 비활성화하도록 해야 합니다. 이것은 Pod의 YAML 사양에서 "automountServiceAccountToken: false" 지시문을 사용하여 수행할 수 있습니다.

경우에 따라 컨테이너화된 애플리케이션은 프로비저닝된 서비스 계정 토큰을 사용하여 클라우드 플랫폼과 같은 외부 서비스에 인증합니다. 이러한 경우에는 계정 토큰을 비활성화 할 수 없습니다. 대신 클러스터 관리자는 클러스터 내에서 pod 권한을 제한하기 위해 rbac 구현되었는지 확인해야합니다. Rbac에 대한 자새한 내용은 인증 및 권한 부여 섹션을 참조하세요

Hardening container environments

일부 플랫폼 및 컨테이너 엔진은 컨테이너화된 환경을 강화하기 위한 추가 옵션 또는 도구를 제공합니다.예를 들어:

• 하이퍼바이저 기반 컨테이너화 – 하이퍼바이저는 운영 체제가 아닌 하드웨어에 의존하여 가상화 경계를 적용합니다.하이퍼바이저 격리는 기존 컨테이너 격리보다 더 안전합니다.Windows® 운영 체제에서 실행되는 컨테이너 엔진은 기본 제공 Windows 하이퍼바이저인 Hyper-V®를 사용하여 보안을 강화하도록 구성할 수 있습니다.또한 일부 보안 중심 컨테이너 엔진은 심층 방어를 위해 경량 하이퍼바이저 내에 기본적으로 각 컨테이너를 배포합니다.하이퍼바이저 지원 컨테이너는 컨테이너 브레이크아웃을 완화합니다.

• 커널 기반 솔루션 – 기본적으로 비활성화되어 있는 seccomp 도구를 사용하여 컨테이너의 시스템 호출 기능을 제한함으로써 커널의 공격 지점을 낮출 수 있습니다.Seccomp는 이전에 설명한 Pod 정책을 통해 시행할 수 있습니다.Seccomp에 대한 자세한 내용은 감사 로깅 및 위협 탐지를 참조하십시오.

• 응용 프로그램 샌드박스 – 일부 컨테이너 엔진 솔루션은 컨테이너화된 응용 프로그램과 호스트 커널 사이에 격리 계층을 추가하는 옵션을 제공합니다.이 격리 경계는 응용 프로그램이 가상 샌드박스 내에서 작동하도록 하여 악의적이거나 파괴적인 작업으로부터 호스트 운영 체제를 보호합니다.

Network separation and hardening (네트워크 분리 및 강화)

클러스터 네트워킹은 Kubernetes의 중심 개념입니다. 컨테이너, Pod, 서비스 및 외부 서비스 간의 통신을 고려해야 합니다. 기본적으로 Kubernetes 리소스는 격리되지 않으며 클러스터가 손상된 경우 측면 이동 또는 에스컬레이션을 방지하지 않습니다. 리소스 분리 및 암호화는 클러스터 내에서 사이버 행위자의 이동 및 확대를 제한하는 효과적인 방법이 될 수 있습니다.

Key points
* network policies과 방화벽을 사용하여 리소스를 분리하고 격리합니다.
* Secure the control plane.
* 트래픽 및 민감한 데이터(예: Secret)를 암호화합니다.

Namespaces

Kubernetes 네임스페이스는 동일한 클러스터 내의 여러 개인, 팀 또는 애플리케이션 간에 클러스터 리소스를 분할하는 한 가지 방법입니다. 기본적으로 네임스페이스는 자동으로 격리되지 않습니다. 그러나 네임스페이스는 RBAC 및 네트워킹 정책을 통해 권한 부여 규칙을 지정하는 데 사용할 수 있는 범위에 레이블을 할당합니다. 네임스페이스별로 리소스에 대한 액세스를 제한하는 정책 외에도 리소스 정책은 스토리지 및 컴퓨팅 리소스를 제한하여 네임스페이스 수준에서 Pod를 더 잘 제어할 수 있습니다.

기본적으로 세 개의 네임스페이스가 있으며 삭제할 수 없습니다.

• kube-system

• kube-public

• default

사용자 포드는 클러스터 서비스용으로 예약되어 있으므로 kube-system 또는 kube-public에 배치하면 안 됩니다.부록 E: 네임스페이스 예에 표시된 YAML 파일을 사용하여 새 네임스페이스를 만들 수 있습니다. 다른 네임스페이스에 있는 Pod와 서비스는 추가 분리가 적용되지 않는 한 여전히 서로 통신할 수 있습니다.

Network policies

모든 포드는 자체 클러스터 전용 IP 주소를 가지며 포트 할당, 이름 지정, 서비스 검색 및 로드 밸런싱과 관련하여 가상 머신(VM) 또는 물리적 호스트와 유사하게 처리될 수 있습니다. Kubernetes는 Pod를 다른 노드로 이동하고 죽은 배포에서 Pod를 다시 생성할 수 있습니다. 이 경우 Pod IP 주소가 변경될 수 있습니다.즉, 애플리케이션이 고정된 Pod IP에 의존해서는 안 됩니다. Kubernetes 서비스는 IP 주소 변경 문제를 해결하는 데 사용됩니다. 서비스는 파드 구성의 레이블을 사용하여 선택한 논리적 파드 세트에 고유한 IP 주소를 할당하는 추상적인 방법입니다. 주소는 서비스 수명과 연결되어 있으며 서비스가 살아있는 동안에는 변경되지 않습니다. 서비스에 대한 통신은 서비스의 구성원인 파드 간에 자동으로 로드 밸런싱됩니다.

서비스는 NodePort 또는 LoadBalancer를 사용하여 외부적으로 그리고 내부적으로 노출될 수 있습니다. 서비스를 외부에 노출하려면 TLS 인증서를 사용하여 트래픽을 암호화하도록 서비스를 구성하십시오. TLS가 구성되면 Kubernetes는 서비스를 인터넷에 노출하는 두 가지 방법인 NodePort 및 LoadBalancer를 지원합니다.

NodePort를 서비스 사양 파일에 추가하면 클러스터의 공용 IP 주소를 사용하여 인터넷에 노출될 임의의 포트가 할당됩니다. 원하는 경우 NodePort를 수동으로 할당할 수도 있습니다. LoadBalancer로 유형을 변경하면 외부 로드 밸런서와 함께 사용할 수 있습니다. 수신 및 송신 트래픽은 네트워크 정책으로 제어할 수 있습니다. 네트워크 정책에서 이름으로 서비스를 선택할 수는 없지만 서비스에 대한 포드를 선택하기 위해 구성에서 사용되는 레이블을 사용하여 포드를 선택할 수 있습니다.

네트워크 정책은 Pod, 네임스페이스 및 외부 IP 주소 간의 트래픽 흐름을 제어합니다. 기본적으로 포드 또는 네임스페이스에는 네트워크 정책이 적용되지 않으므로 포드 네트워크 내에서 무제한 수신 및 송신 트래픽이 발생합니다. 포드는 포드 또는 포드의 네임스페이스에 적용되는 네트워크 정책을 통해 격리됩니다. 네트워크 정책에서 Pod가 선택되면 해당 정책 개체에서 특별히 허용하지 않는 모든 연결을 거부합니다.

네트워크 정책을 생성하기 위해서는 NetworkPolicy API를 지원하는 CNI(Container Network Interface) 플러그인이 필요합니다. pod를 선택후 podSelector 및/또는 namespaceSelector 옵션을 사용합니다.네트워크 정책의 예는 부록 F: 네트워크 정책의 예를 참조하십시오.

Network Policies Checklist

- NetworkPolicy API를 지원하는 CNI 플러그인 사용
- podSelector 및/또는 namespaceSelector를 사용하여 Pod를 선택하는 정책 생성
- 기본 정책을 사용하여 모든 수신 및 송신 트래픽을 거부합니다.선택되지 않은 Pod가 kube-system을 제외한 모든 네임스페이스에 격리되도록 합니다.
- LimitRange 및 ResourceQuota 정책을 사용하여 네임스페이스 또는 Pod 수준에서 리소스 제한

네트워크 정책 형식은 클러스터에 사용되는 CNI 플러그인에 따라 다를 수 있습니다. 관리자는 모든 Pod를 선택하는 기본 정책을 사용하여 모든 수신 및 송신 트래픽을 거부하고 선택되지 않은 Pod가 격리되도록 해야 합니다. 추가 정책은 허용 가능한 연결에 대한 이러한 제한을 완화할 수 있습니다.

외부 IP 주소는 ipBlock을 사용하여 수신 및 송신 정책에서 사용할 수 있지만 다른 CNI 플러그인, 클라우드 제공자 또는 서비스 구현은 NetworkPolicy 처리 순서 및 클러스터 내 주소 재작성에 영향을 미칠 수 있습니다.

네트워크 정책은 방화벽 및 기타 외부 도구와 함께 사용하여 네트워크 세분화를 생성할 수도 있습니다. 네트워크를 별도의 하위 네트워크 또는 보안 영역으로 분할하면 공개 애플리케이션을 민감한 내부 리소스로부터 격리하는 데 도움이 됩니다. 네트워크 세분화의 주요 이점 중 하나는 공격 지점과 다른 공격 지점으로 이동을 제한하는 것입니다. Kubernetes에서 네트워크 세분화를 사용하여 애플리케이션 또는 리소스 유형을 분리하여 공격 지점을 제한할 수 있습니다.

Resource policies (리소스 정책)

LimitRanges, ResourceQuotas 및 Process ID Limits는 네임스페이스, 노드 또는 파드에 대한 리소스 사용을 제한합니다.이러한 정책은 리소스에 대한 컴퓨팅 및 스토리지 공간을 예약하고 리소스 고갈을 방지하는 데 중요합니다.

LimitRange 정책은 예를 들어 최대 컴퓨팅 및 스토리지 리소스를 적용하여 특정 네임스페이스 내의 컨테이너 또는 파드당 개별 리소스를 제한합니다.네임스페이스당 하나의 LimitRange 제약 조건만 만들 수 있습니다.예제 YAML 파일은 부록 G: 예제 LimitRange를 참조하십시오.

각 포드 또는 컨테이너에 개별적으로 적용되는 LimitRange 정책과 달리 ResourceQuotas는 전체 CPU 및 메모리 사용량에 대한 제한과 같이 전체 네임스페이스에 대한 총 리소스 사용량에 대한 제한입니다. ResourceQuota 정책의 예는 부록 H: ResourceQuota 예를 참조하십시오. 사용자가 LimitRange 또는 ResourceQuota 정책을 위반하는 포드를 생성하려고 하면 포드 생성이 실패합니다.

Process ID(PID)는 노드의 기본 리소스이며 다른 리소스 제한을 위반하지 않고 소진될 수 있습니다. PID 소진은 호스트 데몬(예: kubelet 및 kube-proxy)이 실행되는 것을 방지합니다. 관리자는 노드 PID 제한을 사용하여 시스템 사용 및 Kubernetes 시스템 데몬에 대해 지정된 수의 PID를 예약할 수 있습니다. Pod PID 제한은 각 Pod에서 실행되는 프로세스 수를 제한하는 데 사용됩니다. 축출 정책(Eviction policies)을 사용하여 오작동하고 비정상적인 리소스를 소비하는 Pod를 종료할 수 있습니다. 그러나 eviction policies은 주기적으로 계산 및 시행됩니다.그러나 limit를 강제하지는 않습니다.

Control plane hardening(강화)

Control plane은 Kubernetes의 핵심이며 사용자가 컨테이너를 보고, 새 Pod를 예약하고, Secrets를 읽고, 클러스터에서 명령을 실행할 수 있도록 합니다. 이러한 민감한 기능 때문에 control plane은 고도로 보호되어야 합니다. TLS 암호화, RBAC 및 강력한 인증 방법과 같은 보안 구성 외에도 네트워크 분리를 통해 권한이 없는 사용자가 control plane에 액세스하는 것을 방지할 수 있습니다. Kubernetes API 서버는 예상 트래픽만 허용하도록 방화벽으로 보호되어야 하는 포트 6443에서 실행됩니다. Kubernetes API 서버는 인터넷이나 신뢰할 수 없는 네트워크에 노출되어서는 안 됩니다. kube-system 네임스페이스에 네트워크 정책을 적용하여 kube-system에 대한 인터넷 액세스를 제한할 수 있습니다. 모든 네임스페이스에 default deny policy가 구현된 경우 kube-system 네임스페이스는 여전히 다른 Control plane 세그먼트 및 Worker nodes와 통신할 수 있어야 합니다.

control plane을 보호하는 단계
1.TLS 암호화 설정
2.강력한 인증 방법 설정
3.인터넷 및 불필요하거나 신뢰할 수 없는 네트워크에 대한 액세스를 비활성화합니다.
4.RBAC 정책을 사용하여 액세스 제한
5.인증 및 RBAC 정책으로 etcd 데이터 저장소 보호
6.무단 수정으로부터 kubeconfig 파일 보호

다음 표에는 control plane 포트 및 서비스가 나와 있습니다.

Table I: Control plane ports TCP Inbound TCP Inbound TCP Inbound 6443 10250 10257 Kubernetes API server kubelet API kube-controller-manager

Table I: Control plane ports

Protocol	Direction	Port Range	Purpose
TCP	Inbound	6443	Kubernetes API server
TCP	Inbound	2379-2380	etcd server client API
TCP	Inbound	10250	kubelet API
TCP	Inbound	10259	kube-scheduler
TCP	Inbound	10257	kube-controller-manager

Etcd

etcd 백엔드 데이터베이스는 중요한 control plane 구성 요소이며 control plane 내에서 보안을 유지하는 데 가장 중요한 부분입니다.

etcd 백엔드 데이터베이스는 상태 정보와 클러스터 비밀을 저장합니다. 이는 중요한 control plane 구성 요소이며 etcd에 대한 쓰기 액세스 권한을 얻으면 사이버 액터가 전체 클러스터에 대한 루트 액세스 권한을 얻을 수 있습니다. etcd 서버는 API 서버에 할당된 인증서만 신뢰하도록 구성해야 합니다. Etcd는 별도의 control plane 노드에서 실행할 수 있으므로 방화벽이 API 서버에만 액세스를 제한할 수 있습니다. 이는 API 서버가 보호될 때 공격 지점을 제한합니다. 클러스터의 인증 방식과 RBAC 정책으로 사용자를 제한합니다. 관리자는 etcd 서버와 API 서버 간에 HTTPS(Hypertext Transfer Protocol Secure) 통신을 적용하도록 TLS 인증서를 설정해야 합니다. etcd에 대해 별도의 인증 기관(CA)을 사용하는 것도 기본적으로 루트 CA에서 발급한 모든 인증서를 신뢰하므로 유익할 수 있습니다.

Kubeconfig Files

kubeconfig 파일에는 클러스터, 사용자, 네임스페이스 및 인증 메커니즘에 대한 민감한 정보가 포함되어 있습니다. Kubectl은 Worker nodes 및 control plane 로컬 시스템의 $HOME/.kube 디렉토리에 저장된 구성 파일을 사용합니다. 사이버 범죄자는 이 구성 디렉터리에 대한 액세스를 악용하여 액세스 권한을 얻고 구성 또는 자격 증명을 수정하여 클러스터를 추가로 손상시킬 수 있습니다. 구성 파일은 의도하지 않은 변경으로부터 보호되어야 하며 인증되지 않은 루트가 아닌 사용자는 파일에 액세스하지 못하도록 차단되어야 합니다.

Worker node segmentation

Worker nodes는 클러스터의 구현에 따라 가상 또는 물리적 머신이 될 수 있습니다. 노드는 마이크로서비스를 실행하고 클러스터용 웹 애플리케이션을 호스팅하기 때문에 종종 악용의 대상이 됩니다. 노드가 손상되면 관리자는 Worker nodes 또는 Kubernetes 서비스와 통신할 필요가 없는 다른 네트워크 세그먼트에서 Worker nodes를 분리하여 공격 지점을 사전에 제한해야 합니다.

네트워크에 따라 방화벽을 사용하여 외부를 향한 Worker nodes 또는 전체 Kubernetes 서비스에서 내부 네트워크 세그먼트를 분리할 수 있습니다. Worker nodes의 가능한 공격 지점과 분리해야 할 수 있는 서비스의 예로는 인터넷에 액세스할 필요가 없는 기밀 데이터베이스 또는 내부 서비스가 있습니다.

다음 표에는 Worker nodes 포트 및 서비스가 나열되어 있습니다.

Protocol	Direction	Port Range	Purpose
TCP	Inbound	10250	Kubelet API
TCP	Inbound	30000-32767	Worker nodes

Encryption(암호화)

관리자는 TLS 1.2 또는 1.3 암호화를 사용하도록 구성 요소, 노드 및 control plane 사이를 포함하여 Kubernetes 클러스터의 모든 트래픽을 구성해야 합니다. 설치 중 또는 이후에 Kubernetes 설명서에 자세히 설명된 TLS 부트스트래핑을 사용하여 암호화를 설정하여 인증서를 생성하고 노드에 배포할 수 있습니다. 모든 방법에 대해 인증서를 노드 간에 배포하여 안전하게 통신해야 합니다.

Secrets

Kubernetes 시크릿은 비밀번호, OAuth 토큰, SSH(Secure Shell) 키와 같은 민감한 정보를 유지 관리합니다. Secrets에 민감한 정보를 저장하면 YAML 파일, 컨테이너 이미지 또는 환경 변수에 암호나 토큰을 저장하는 것보다 더 강력한 액세스 제어가 제공됩니다. 기본적으로 Kubernetes는 API 액세스 권한이 있는 모든 사용자가 검색할 수 있는 암호화되지 않은 base64로 인코딩된 문자열로 Secret을 저장합니다. 비밀 리소스에 RBAC 정책을 적용하여 액세스를 제한할 수 있습니다.

기본적으로 비밀은 암호화되지 않은 base64로 인코딩된 문자열로 저장되며 API 액세스 권한이 있는 모든 사용자가 검색할 수 있습니다.

API 서버에서 미사용 데이터 암호화를 구성하거나 클라우드 공급자를 통해 사용할 수 있는 외부 KMS(키 관리 서비스)를 사용하여 비밀을 암호화할 수 있습니다. API 서버를 사용하여 Secret data-at-rest 암호화를 활성화하려면 관리자가 --encryption-provider-config 인수를 사용하여 실행하도록 kube-apiserver 매니페스트 파일을 변경해야 합니다.

encryption-provider-config 파일의 예는 부록 I: 암호화 예를 참조하십시오. KMS 공급자를 사용하면 원시 암호화 키가 로컬 디스크에 저장되지 않습니다. KMS 공급자를 사용하여 비밀을 암호화하려면 encryption-Provider-config 파일에 KMS 공급자를 지정해야 합니다. 예는 부록 J: KMS 구성 예를 참조하십시오.

encryption-provider-config 파일을 적용한 후 관리자는 다음 명령을 실행하여 모든 비밀을 읽고 암호화해야 합니다.

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Protecting sensitive cloud infrastructure

Kubernetes는 종종 클라우드 환경의 VM에 배포됩니다.따라서 관리자는 Kubernetes Worker nodes가 실행 중인 VM의 공격 지점을 신중하게 고려해야 합니다.대부분의 경우 이러한 VM에서 실행되는 Pod는 라우팅할 수 없는 주소의 민감한 클라우드 메타데이터 서비스에 액세스할 수 있습니다. 이러한 메타데이터 서비스는 사이버 행위자에게 클라우드 인프라에 대한 정보와 클라우드 리소스에 대한 단기 자격 증명을 제공합니다.

사이버 범죄자는 권한 상승을 위해 이러한 메타데이터 서비스를 남용합니다[5]. Kubernetes 관리자는 네트워크 정책을 사용하거나 클라우드 구성 정책을 통해 Pod가 클라우드 메타데이터 서비스에 액세스하지 못하도록 해야 합니다. 이러한 서비스는 클라우드 제공업체에 따라 다르므로 관리자는 공급업체 지침에 따라 이러한 액세스 벡터를 강화해야 합니다.

Authentication and authorization (인증 및 권한 부여)

인증 및 권한 부여는 클러스터 리소스에 대한 액세스를 제한하는 기본 메커니즘입니다. 사이버 범죄자는 잘 알려진 Kubernetes 포트를 검색하고 클러스터의 데이터베이스에 액세스하거나 클러스터가 잘못 구성된 경우 인증 없이 API를 호출할 수 있습니다. 여러 사용자 인증 메커니즘이 지원되지만 기본적으로 활성화되어 있지는 않습니다.

Authentication

Kubernetes clusters의 두가지 타입의 어카운트:

• Service accounts

• Normal user accounts

서비스 계정은 Pod를 대신하여 API 요청을 처리합니다. 인증은 일반적으로 전달자 토큰을 사용하여 ServiceAccount 승인 컨트롤러를 통해 Kubernetes에서 자동으로 관리됩니다. 승인 컨트롤러가 활성화되면 Pod에 연결된 서비스 계정이 있는지 확인합니다. Pod 정의가 서비스 계정을 지정하지 않으면 승인 컨트롤러가 네임스페이스에 대한 기본 서비스 계정을 연결합니다. Pod 정의가 automaticServiceAccountToken 또는 automaticServiceAccounttoken을 false로 설정하여 서비스 토큰 추가를 금지하는 경우 승인 컨트롤러는 기본 서비스 계정을 연결하지 않습니다. 서비스 계정을 개별적으로 생성하여 특정 권한을 부여할 수도 있습니다. Kubernetes는 서비스 계정을 생성할 때 서비스 계정 Secret을 생성하고 Secret을 사용하도록 Pod를 자동으로 수정합니다. 서비스 계정 토큰 Secret에는 API에 액세스하기 위한 자격 증명이 포함되어 있습니다. 보안되지 않거나 암호화되지 않은 상태로 두면 공격자가 클러스터 외부에서 서비스 계정 토큰을 사용할 수 있습니다. 이러한 위험 때문에 Kubernetes RBAC를 사용하여 Pod Secret에 대한 액세스를 볼 필요가 있는 사람으로 제한해야 합니다.

일반 사용자 및 관리자 계정의 경우 자동 인증 방법이 없습니다. 관리자는 인증 방법을 구현하거나 인증을 타사 서비스에 위임해야 합니다. Kubernetes는 클러스터 독립 서비스가 사용자 인증을 관리한다고 가정합니다. Kubernetes 문서에는 X509 클라이언트 인증서, 부트스트랩 토큰 및 OpenID 토큰을 포함하여 사용자 인증을 구현하는 여러 방법이 나열되어 있습니다. 하나 이상의 사용자 인증 방법을 구현해야 합니다. 여러 인증 방법이 구현된 경우 요청을 성공적으로 인증하는 첫 번째 모듈은 평가를 마무리시킵니다. 관리자는 정적 암호 파일과 같은 약한 방법을 사용해서는 안 됩니다. 약한 방법을 사용하면 사이버 범죄자가 합법적인 사용자로 인증할 수 있기 때문입니다.

Kubernetes는 클러스터 독립 서비스가 사용자 인증을 관리한다고 가정합니다.

익명 요청은 구성된 다른 인증 방법에 의해 거부되지 않고 개별 사용자나 파드에 연결되지 않은 요청입니다. 익명 요청이 활성화된 토큰 인증을 위한 서버 설정에서 토큰이 없는 요청은 익명 요청으로 수행됩니다. Kubernetes 1.6 이상에서는 기본적으로 익명 요청이 활성화됩니다. RBAC가 활성화된 경우 익명 요청에는 system:anonymous 사용자 또는 system:unauthenticated 그룹의 명시적 권한 부여가 필요합니다.--anonymous-auth=false 옵션을 API 서버에 전달하여 익명 요청을 비활성화해야 합니다. 익명 요청을 활성화하면 사이버 범죄자가 인증 없이 클러스터 리소스에 액세스할 수 있습니다.

Role-based Access Control

기본적으로 활성화된 RBAC는 조직 내 개인의 역할에 따라 클러스터 리소스에 대한 액세스를 제어하는 한 가지 방법입니다. RBAC를 사용하여 사용자 계정 및 서비스 계정에 대한 액세스를 제한할 수 있습니다. kubectl을 사용하여 클러스터에서 RBAC가 활성화되었는지 확인하려면 kubectl api-version을 실행하십시오. RBAC가 활성화된 경우 .rbac.authorization.k8s.io/v1용 API 버전이 나열되어야 합니다. Cloud Kubernetes 서비스에는 클러스터에 대해 RBAC가 활성화되었는지 여부를 확인하는 다른 방법이 있을 수 있습니다. RBAC가 활성화되지 않은 경우 다음 명령에서 --authorization- 모드 플래그를 사용하여 API 서버를 시작합니다.

kube-apiserver --authorization-mode=RBAC

AlwaysAllow와 같은 권한 부여 모드 플래그를 그대로 두면 모든 권한 부여 요청이 허용되어 모든 권한 부여가 효과적으로 비활성화되고 액세스에 대한 최소 권한을 적용하는 기능이 제한됩니다.

두 가지 유형의 권한을 설정할 수 있습니다.

• Roles – 특정 네임스페이스에 대한 권한 설정

• ClusterRoles – 네임스페이스에 관계없이 모든 클러스터 리소스에 대한 권한 설정

역할과 ClusterRoles는 모두 권한을 추가하는 데만 사용할 수 있습니다. 거부 규칙이 없습니다. 클러스터가 RBAC를 사용하도록 구성되고 익명 액세스가 비활성화된 경우 Kubernetes API 서버는 명시적으로 허용되지 않은 권한을 거부합니다. RBAC 역할의 예는 부록 K: pod-reader RBAC 역할의 예를 참조하십시오.

Role 또는 ClusterRole은 권한을 정의하지만 권한을 사용자에게 연결하지 않습니다. 다음 그림과 같이 RoleBindings 및 ClusterRoleBindings는 Role 또는 ClusterRole을 사용자, 그룹 또는 서비스 계정에 연결하는 데 사용됩니다. RoleBindings는 정의된 네임스페이스의 사용자, 그룹 또는 서비스 계정에 역할 또는 ClusterRoles의 권한을 부여합니다. ClusterRoles는 네임스페이스와 독립적으로 생성되며 RoleBinding과 함께 여러 번 사용하여 네임스페이스 범위를 제한할 수 있습니다. 이는 사용자, 그룹 또는 서비스 계정이 여러 네임스페이스에서 유사한 권한을 요구할 때 유용합니다. 하나의 ClusterRole을 다른 RoleBindings와 함께 여러 번 사용하여 범위를 다른 개별 사용자, 그룹 또는 서비스 계정으로 제한할 수 있습니다. ClusterRoleBindings는 모든 클러스터 리소스에 걸쳐 사용자, 그룹 또는 서비스 계정에 ClusterRole을 부여합니다. RBAC RoleBinding 및 ClusterRoleBinding의 예는 부록 L: RBAC RoleBinding 및 ClusterRoleBinding의 예를 참조하십시오.

역할 및 ClusterRoles를 생성 또는 업데이트하려면 사용자에게 동일한 범위의 새 역할에 포함된 권한이 있거나 rbac.authorization.k8s.io API 그룹의 역할 또는 ClusterRoles 리소스에 대해 에스컬레이션 동사를 수행할 수 있는 명시적 권한이 있어야 합니다. 바인딩이 생성된 후에는 Role 또는 ClusterRole을 변경할 수 없습니다. 역할을 변경하려면 바인딩을 삭제해야 합니다. 사용자, 그룹 및 서비스 계정에 할당된 권한은 최소 권한 원칙을 따라야 하며 작업을 완료하는 데 필요한 권한만 허용해야 합니다. 사용자 그룹을 사용하면 역할을 더 쉽게 관리할 수 있습니다. 사용자, 관리자, 개발자 및 인프라 팀과 같은 다양한 그룹에 대해 고유한 권한이 필요합니다. 각 그룹은 다른 리소스에 액세스해야 하며 다른 그룹의 리소스를 편집하거나 볼 수 있는 권한이 없어야 합니다. 사용자, 사용자 그룹 및 서비스 계정은 필요한 리소스가 있는 특정 네임스페이스와 상호 작용하고 볼 수 있도록 제한되어야 합니다. Kubernetes API에 대한 액세스는 적절한 API 요청 동사 및 작업을 적용할 수 있는 원하는 리소스로 RBAC 역할 또는 ClusterRole을 생성하여 제한됩니다. 연결된 할당된 역할 및 ClusterRoles를 사용하여 사용자, 그룹 및 서비스 계정을 인쇄하여 RBAC 정책을 감사하는 데 도움이 되는 도구가 있습니다.

Audit Logging and Threat Detection

감사 로그는 클러스터에서 발생한 활동을 캡처합니다. 서비스가 의도한 대로 운영되고 구성되는지 확인하는 것뿐만 아니라 시스템의 보안을 보장하기 위해서는 효과적인 로깅 솔루션과 로그 검토가 필요합니다. 체계적인 보안 감사 요구 사항은 보안 설정에 대한 일관되고 철저한 검사를 요구하여 침해를 식별하는 데 도움이 됩니다. Kubernetes는 속성 클러스터 작업을 추적하고 기본 CPU 및 메모리 사용량 정보를 모니터링하기 위한 감사 로그를 캡처할 수 있습니다. 그러나 기본적으로 완전한 기능을 갖춘 모니터링 또는 경고 서비스를 제공하지는 않습니다.

Key points
- 비정상적인 활동 식별을 활성화하기 위해 생성 시 포드 기준을 설정합니다.
- 환경의 모든 수준에서 로깅을 수행합니다.
- 통합 스캔, 모니터링, 경고 및 분석을 위해 기존 네트워크 보안 도구를 통합합니다.
- 장애 발생 시 로그 손실을 방지하기 위해 내결함성 정책을 설정합니다.

Logging

Kubernetes 내에서 애플리케이션을 실행하는 시스템 관리자는 환경에 대한 효과적인 로깅 및 모니터링 시스템을 구축해야 합니다. Kubernetes 이벤트를 로깅하는 것만으로는 시스템에서 발생하는 작업의 전체 그림을 제공하기에 충분하지 않습니다. 호스트, 애플리케이션, 컨테이너, 컨테이너 엔진, 이미지 레지스트리, API 서버 및 클라우드를 포함하여 환경의 모든 수준에서 로깅을 수행해야 합니다(해당되는 경우). 캡처한 후에는 이러한 로그를 모두 단일 서비스로 집계하여 보안 감사자, 네트워크 방어자 및 사고 대응자에게 환경 전체에서 취한 조치에 대한 전체 보기를 제공해야 합니다.

Kubernetes 환경 내에서 관리자가 모니터링/로그해야 하는 일부 이벤트에는 다음이 포함됩니다.

• API request history

• Performance metrics

• Deployments

• Resource consumption

• Operating system calls

• Protocols, permission changes

• Network traffic

• Pod scaling

• Volume mount actions

• Image and container modification

• Privilege changes

• Scheduled job (cronjob) creations and modifications

관리자가 포드를 생성하거나 업데이트할 때 네트워크 통신, 응답 시간, 요청, 리소스 소비 및 기타 관련 지표에 대한 자세한 로그를 캡처하여 기준을 설정해야 합니다. RBAC 정책 구성도 주기적으로 그리고 조직의 시스템 관리자에게 인사 변경이 발생할 때마다 검토되어야 합니다. 이렇게 하면 액세스 제어가 이 가이드의 RBAC 섹션에 설명된 RBAC 정책 강화 지침을 준수하도록 유지됩니다. 일상적인 시스템 보안 감사에는 현재 로그를 정상 활동의 기준 측정치와 비교하여 기록된 메트릭 및 이벤트에서 중요한 변경 사항을 식별하는 작업이 포함되어야 합니다. 시스템 관리자는 근본 원인을 확인하기 위해 중요한 변경 사항을 조사해야 합니다.예를 들어 리소스 소비가 크게 증가하면 애플리케이션 사용이 변경되거나 크립토마이너와 같은 악성 프로세스가 설치되었음을 나타낼 수 있습니다. 연결에 대한 모든 의도된 보안 제약 조건이 올바르게 구성되고 의도한 대로 작동하는지 확인하기 위해 내부 및 외부 트래픽 로그에 대한 감사를 수행해야 합니다. 관리자는 외부 액세스가 제한될 수 있는 위치를 평가하기 위해 시스템이 발전함에 따라 이러한 감사를 사용할 수도 있습니다. 외부 로깅 서비스로 로그를 스트리밍하면 클러스터 외부의 보안 전문가에게 가용성을 보장하여 가능한 한 실시간에 가깝게 이상을 식별할 수 있습니다. 이 방법을 사용하는 경우 TLS 1.2 또는 1.3으로 전송하는 동안 로그를 암호화하여 사이버 범죄자가 전송 중인 로그에 액세스하고 환경에 대한 중요한 정보를 얻을 수 없도록 해야 합니다.

외부 로그 서버를 사용할 때 취해야 할 또 다른 예방 조치는 외부 저장소에 대한 추가 전용 액세스 권한으로 Kubernetes 내에서 로그 전달자를 구성하는 것입니다. 이렇게 하면 외부에 저장된 로그가 클러스터 내에서 삭제되거나 덮어쓰여지는 것을 방지할 수 있습니다.

Kubernetes 기본 감사 로깅 구성

Kubernetes audit logging capabilities are disabled by default

kube-apiserver는 Kubernetes control plane에 상주하며 클러스터에 대한 내부 및 외부 요청을 처리하는 프런트 엔드 역할을 합니다. 사용자, 애플리케이션 또는 control plane에 의해 생성된 각 요청은 실행의 각 단계에서 감사 이벤트를 생성합니다. 감사 이벤트가 등록되면 kube-apiserver는 감사 정책 파일과 해당 규칙을 확인합니다. 이러한 규칙이 있는 경우 서버는 첫 번째 일치 규칙에 의해 정의된 수준에서 이벤트를 기록합니다. Kubernetes의 내장 감사 로깅 기능은 기본적으로 로깅을 수행하지 않습니다. 클러스터 관리자는 감사 정책 YAML 파일을 작성하여 규칙을 설정하고 각 감사 이벤트 유형을 기록할 원하는 감사 수준을 지정해야 합니다. 그런 다음 이 감사 정책 파일은 적절한 플래그와 함께 kube-apiserver로 전달됩니다. 규칙이 유효한 것으로 간주되려면 다음 네 가지 감사 수준 중 하나를 지정해야 합니다.

• None

• Metadata

• Request

• RequestResponse

RequestResponse 수준에서 모든 이벤트를 기록하면 위반이 발생할 경우 사고 대응자가 사용할 수 있는 최대 정보량을 관리자에게 제공합니다. 그러나 이로 인해 로그에서 base64로 인코딩된 비밀이 캡처될 수 있습니다. NSA 및 CISA는 로그에서 Secrets 캡처를 방지하기 위해 Secrets와 관련된 요청의 로깅 수준을 메타데이터 수준으로 줄일 것을 권장합니다. 또한 최고 수준에서 다른 모든 이벤트를 기록하면 특히 프로덕션 클러스터에서 많은 양의 로그가 생성됩니다. 조직의 제약 조건에 따라 필요한 경우 감사 정책을 환경에 맞게 조정하여 중요하지 않은 일상적인 이벤트의 로깅 수준을 줄일 수 있습니다. 이러한 감사 정책에 필요한 특정 규칙은 배포에 따라 다릅니다. 조직의 특정 클러스터 구성 및 위협 모델에 세심한 주의를 기울이면서 모든 보안에 중요한 이벤트를 기록하는 것이 중요합니다. 감사 정책을 개선하는 목표는 중복성을 제거하는 동시에 클러스터에서 발생하는 이벤트에 대한 명확한 그림과 원인을 제공하는 것입니다.

일반적인 중요 및 중요하지 않은 감사 이벤트 유형 및 단계의 몇 가지 예와 메타데이터 수준의 Secrets 및 RequestResponse 수준의 기타 모든 이벤트를 기록하는 감사 정책 파일의 예는 부록 M: 감사 정책을 참조하십시오.

kube-apiserver 구성 파일이 있는 위치의 예와 감사 정책 파일을 kube-apiserver에 전달할 수 있는 플래그의 예는 부록 N: 감사 로깅을 활성화하는 플래그의 예를 참조하십시오.필요한 경우 볼륨을 마운트하고 호스트 경로를 구성하는 방법에 대한 지침은 부록 N: 감사 로깅을 활성화하는 플래그의 예를 참조하십시오.

kube-apiserver에는 감사 로깅을 위한 구성 가능한 로깅 및 웹훅 백엔드가 포함되어 있습니다. 로깅 백엔드는 지정된 감사 이벤트를 로그 파일에 기록하고 웹훅 백엔드는 파일을 외부 HTTP API로 보내도록 구성할 수 있습니다. 부록 N: 감사 로깅을 활성화하는 예시 플래그의 예에 설정된 --audit-log-path 및 --audit-log-maxage 플래그는 로깅 백엔드를 구성하는 데 사용할 수 있는 플래그의 두 가지 예입니다. 감사 이벤트를 파일에 씁니다. log-path 플래그는 로깅을 활성화하는 데 필요한 최소 구성이며 로깅 백엔드에 필요한 유일한 구성입니다. 이러한 로그 파일의 기본 형식은 JSON(Java Script Object Notation)이지만 필요한 경우 변경할 수도 있습니다. 로깅 백엔드에 대한 추가 구성 옵션은 Kubernetes 문서에서 찾을 수 있습니다. Kubernetes는 또한 관리자가 kubeapiserver에 제출된 YAML 파일을 통해 수동으로 구성하여 외부 백엔드에 로그를 푸시할 수 있는 웹훅 백엔드 옵션을 제공합니다. webhook 백엔드에 대한 kube-apiserver에서 설정할 수 있는 구성 옵션의 전체 목록은 Kubernetes 문서에서 찾을 수 있습니다. Webhook 백엔드 작동 방식 및 설정 방법에 대한 자세한 내용은 Kubernetes 설명서에서도 확인할 수 있습니다. 또한 로그 집계를 수행하는 데 사용할 수 있는 많은 외부 도구가 있으며 그 중 일부는 다음 섹션에서 간략하게 설명합니다.

Worker node and container logging

Kubernetes 아키텍처 내에서 로깅 기능을 구성하는 방법에는 여러 가지가 있습니다. 내장된 로그 관리 방법에서 각 노드의 kubelet은 로그 관리를 담당합니다. 개별 파일 길이, 저장 기간 및 저장 용량에 대한 정책을 기반으로 로그 파일을 로컬로 저장하고 회전합니다. 이러한 로그는 kubelet에 의해 제어되며 명령줄에서 액세스할 수 있습니다.다음 명령은 Pod 내 컨테이너의 로그를 인쇄합니다.

kubectl logs [-f] [-p] POD [-c CONTAINER]

-f 플래그는 로그가 스트리밍되어야 하는 경우 사용될 수 있고, -p 플래그는 컨테이너의 이전 인스턴스로부터의 로그가 존재하고 필요한 경우 사용될 수 있으며, -c 플래그는 있는 경우 컨테이너를 지정하는 데 사용될 수 있습니다. Pod에 둘 이상 있습니다. 컨테이너, 파드 또는 노드를 종료시키는 오류가 발생하면 Kubernetes의 기본 로깅 솔루션은 실패한 개체에 저장된 로그를 보존하는 방법을 제공하지 않습니다. NSA 및 CISA는 노드가 실패할 경우 로그를 보존하도록 원격 로깅 솔루션을 구성할 것을 권장합니다. 원격 로깅 옵션은 다음과 같습니다.

Worker nodes에서 에이전트 로깅의 연속성을 보장하기 위해 DaemonSet으로 실행하는 것이 일반적입니다. 이 방법에 대해 DaemonSet을 구성하면 항상 모든 노드에 로깅 에이전트의 복사본이 있고 로깅 에이전트에 대한 변경 사항이 클러스터 전체에서 일관되도록 합니다.

자체 Kubernetes 클러스터를 실행하는 여러 팀이 있는 대규모 조직은 로깅 요구 사항과 표준 아키텍처를 설정하여 모든 팀이 효과적인 솔루션을 갖추도록 해야 합니다.

Seccomp: 감사 모드

앞에서 설명한 노드 및 컨테이너 로깅 외에도 시스템 호출을 기록하는 것이 매우 유용할 수 있습니다. Kubernetes에서 컨테이너 시스템 호출을 감사하는 한 가지 방법은 seccomp 도구를 사용하는 것입니다. 이 도구는 기본적으로 비활성화되어 있지만 컨테이너의 시스템 호출 기능을 제한하여 커널의 공격 지점을 낮추는 데 사용할 수 있습니다. Seccomp는 감사 프로필을 사용하여 어떤 호출이 발생했는지 기록할 수도 있습니다. 사용자 지정 seccomp 프로필은 허용, 거부 또는 기록되는 시스템 호출과 지정되지 않은 호출에 대한 기본 작업을 정의합니다. 포드 내에서 사용자 지정 seccomp 프로필을 활성화하기 위해 Kubernetes 관리자는 seccomp 프로필 JSON 파일을 /var/lib/kubelet/seccomp/ 디렉터리에 작성하고 seccompProfile을 포드의 securityContext에 추가할 수 있습니다. 사용자 지정 seccompProfile에는 유형: Localhost 및 localhostProfile: myseccomppolicy.json의 두 필드도 포함되어야 합니다. 모든 시스템 호출을 기록하면 관리자가 시스템 기능을 잃지 않고 seccomp 프로필을 추가로 제한할 수 있도록 하는 표준 작업에 필요한 시스템 호출을 알 수 있습니다. 또한 관리자가 Pod의 표준 작동 패턴에 대한 기준선을 설정하는 데 도움이 될 수 있으므로 이 패턴에서 악의적인 활동을 나타낼 수 있는 주요 이탈을 식별할 수 있습니다.

syslog

Kubernetes는 기본적으로 서비스를 사용할 수 있는 경우 kubelet 로그 및 컨테이너 런타임 로그를 journald에 씁니다. 조직에서 syslog 유틸리티를 활용하거나 클러스터 전체에서 로그를 수집하여 syslog 서버 또는 기타 로그 스토리지 및 집계 플랫폼으로 전달하려는 경우 해당 기능을 수동으로 구성할 수 있습니다.Syslog 프로토콜은 로그 메시지 형식 표준을 정의합니다. Syslog 메시지에는 헤더와 일반 텍스트로 작성된 메시지가 포함됩니다. syslog-ng® 및 rsyslog와 같은 Syslog 데몬은 시스템 전체에서 통합 형식으로 로그를 수집하고 집계할 수 있습니다. 많은 Linux 운영 체제는 기본적으로 rsyslog 또는 journald를 사용합니다. 이는 journalctl을 통해 syslog 형식의 로그 저장 및 출력 로그를 최적화하는 이벤트 로깅 데몬입니다. syslog 유틸리티는 기본적으로 호스트 수준에서 특정 Linux 배포판을 실행하는 노드에서 이벤트를 기록합니다. 이러한 Linux 배포판을 실행하는 컨테이너는 기본적으로 syslog를 사용하여 로그도 수집합니다. Syslog 유틸리티는 로그 집계 플랫폼이 로그를 수집하도록 구성되어 있지 않는 한 각 해당 노드 또는 컨테이너의 로컬 파일 시스템에 로그를 저장합니다. syslog 데몬 또는 이와 같은 다른 도구는 클러스터 전체에서 수집되는 이러한 로그와 다른 모든 로그를 집계하고 저장 및 모니터링을 위해 외부 백엔드로 전달하도록 구성해야 합니다.

SIEM platforms

SIEM(보안 정보 및 이벤트 관리) 소프트웨어는 조직의 네트워크 전체에서 로그를 수집합니다. 방화벽 로그, 애플리케이션 로그 등을 함께 가져와 분석가가 시스템 보안을 모니터링할 수 있는 중앙 집중식 플랫폼을 제공합니다. SIEM 도구에는 다양한 기능이 있습니다.일반적으로 이러한 플랫폼은 로그 수집, 집계, 위협 탐지 및 경고 기능을 제공합니다. 일부는 시스템 동작을 더 잘 예측하고 잘못된 경고를 줄이는 데 도움이 될 수 있는 기계 학습 기능을 포함합니다. 환경에서 이러한 플랫폼을 사용하는 조직은 클러스터를 더 잘 모니터링하고 보호하기 위해 이를 Kubernetes와 통합해야 합니다. Kubernetes 환경에서 로그를 관리하기 위한 오픈 소스 플랫폼은 SIEM 플랫폼의 대안으로 존재합니다. 컨테이너화된 환경은 노드, 포드, 컨테이너 및 서비스 간에 많은 상호 종속성을 가지고 있습니다. 이러한 환경에서 Pod와 컨테이너는 지속적으로 삭제되고 다른 노드에 재배포됩니다. 이러한 유형의 환경은 일반적으로 IP 주소를 사용하여 로그를 상호 연관시키는 기존 SIEM에 추가 과제를 제시합니다. 차세대 SIEM 플랫폼도 복잡한 Kubernetes 환경에 항상 적합하지 않을 수 있습니다. 그러나 Kubernetes가 가장 널리 사용되는 컨테이너 오케스트레이션 플랫폼으로 부상함에 따라 SIEM 도구를 개발하는 많은 조직이 Kubernetes 환경과 함께 작동하도록 특별히 설계된 다양한 제품을 개발하여 이러한 컨테이너화된 환경에 대한 전체 모니터링 솔루션을 제공했습니다. 관리자는 플랫폼의 기능을 알고 있어야 하며 향후 사고 대응을 지원하기 위해 환경을 충분히 캡처하는 로깅을 확인해야 합니다.

Service meshes

서비스 메시는 이러한 통신의 논리를 각 마이크로 서비스 내에서가 아니라 서비스 메시로 코딩할 수 있도록 하여 애플리케이션 내에서 마이크로 서비스 통신을 간소화하는 플랫폼입니다. 이 통신 논리를 개별 마이크로 서비스로 코딩하는 것은 확장하기 어렵고 오류 발생 시 디버그하기 어렵고 보안을 유지하기 어렵습니다. 서비스 메시를 사용하면 개발자를 위해 이 코딩을 단순화할 수 있습니다. 이 수준의 로그 수집은 클러스터 관리자에게 클러스터 전체의 표준 서비스 간 통신 흐름에 대한 통찰력을 제공할 수도 있습니다. 메쉬는 다음을 수행할 수 있습니다.

• 서비스가 다운될 때 트래픽 리디렉션,

• 커뮤니케이션 최적화를 위한 성능 메트릭 수집,

• 서비스 간 통신 암호화 관리 허용,

• 서비스 간 통신을 위한 로그 수집,

• 각 서비스에서 로그를 수집하고,

• 개발자가 마이크로 서비스 또는 통신 메커니즘의 문제 및 장애를 진단할 수 있도록 지원

• 서비스를 하이브리드 또는 다중 클라우드 환경으로 마이그레이션하는 데 도움이 됩니다.

서비스 메시는 필요하지 않지만 Kubernetes 환경에 매우 적합한 옵션입니다. 로깅 기능은 서비스 간 통신을 매핑하는 데도 유용할 수 있으므로 관리자는 표준 클러스터 작업이 어떻게 보이는지 확인하고 이상 징후를 더 쉽게 식별할 수 있습니다. 관리형 Kubernetes 서비스에는 종종 자체 서비스 메시가 포함됩니다. 그러나 여러 다른 플랫폼도 사용할 수 있으며 원하는 경우 고도로 사용자 정의할 수 있습니다. 최신 서비스 메시의 또 다른 주요 이점은 서비스 간 통신의 암호화입니다. 많은 서비스 메시가 키를 관리하고 인증서를 생성 및 순환하므로 개발자가 각 개별 서비스에 대해 이를 설정하고 스스로 관리할 필요 없이 서비스 간에 안전한 TLS 인증이 가능합니다. 일부 서비스 메시는 기본적으로 이 서비스 간 암호화를 수행하기도 합니다. 관리자가 Kubernetes 클러스터 내에서 서비스 메시를 배포하는 경우 다음 그림과 같이 서비스 메시에 대한 업데이트 및 보안 경고를 유지하는 것이 중요합니다.

Fault tolerance (결함 허용)

조직은 fault tolerance policies을 시행해야 합니다. 이러한 정책은 특정 Kubernetes 사용 사례에 따라 다를 수 있습니다. 그러한 정책 중 하나는 저장 용량이 초과된 경우 절대적으로 필요한 경우 새 로그가 가장 오래된 로그 파일을 덮어쓰도록 허용하는 것입니다. 로그가 외부 서비스로 전송되는 경우 사용할 수 있는 또 다른 정책은 통신 끊김 또는 외부 서비스 장애 발생 시 로컬에 로그를 저장할 장소를 설정하는 것입니다. 외부 서비스와의 통신이 복원되면 로컬에 저장된 로그가 외부 서버로 푸시되는 정책이 있어야 합니다.

Threat Detection

효과적인 로깅 솔루션은 필요한 모든 데이터를 수집한 다음 수집된 데이터에서 위험 신호를 최대한 실시간으로 모니터링하는 두 가지 중요한 구성 요소로 구성됩니다. 데이터가 검사되지 않으면 세계 최고의 로깅 솔루션은 쓸모가 없습니다. 로그 검사 프로세스의 대부분은 자동화할 수 있습니다. 그러나 로그 구문 분석 정책을 작성하거나 로그를 수동으로 검사할 때 무엇을 찾아야 하는지 아는 것이 중요합니다. 공격자가 클러스터를 악용하려고 하면 로그에 행동의 흔적을 남깁니다. 다음 표에는 공격자가 클러스터를 악용할 수 있는 몇 가지 방법과 로그에 나타날 수 있는 방법이 나와 있습니다.

**주의 사항:**
이 표에는 몇 가지 알려진 의심스러운 지표가 나열되어 있습니다.또한 관리자는 자신의 환경에서 특정 문제와 새로운 위협을 인식하고 경고해야 합니다.
가장 효과적인 경고는 특정 클러스터의 비정상적인 활동을 식별하도록 조정됩니다.

attacker Action	Log Detection
공격자는 자신의 악성 소프트웨어를 실행하거나 공격의 스테이징 그라운드/피벗 포인트로 사용하기 위해 Pod 또는 컨테이너를 배포하려고 할 수 있습니다.
공격자는 이름과 명명 규칙을 복사하여 배포를 합법적인 이미지로 가장할 수 있습니다.
권한을 상승시키기 위해 루트 권한으로 컨테이너를 시작하려고 할 수도 있습니다.	비정형 Pod 및 컨테이너 배포를 살펴보십시오.
유효한 이미지와 의심되는 이미지 배포를 비교하려면 이미지 ID와 레이어 해시를 사용하십시오.
루트 권한으로 시작되는 Pod 또는 애플리케이션 컨테이너를 관찰하십시오.
공격자는 배포를 위해 이미지에 대한 액세스 권한을 부여하거나 합법적인 당사자가 합법적인 이미지 대신 악성 이미지를 배포하도록 속이기 위해 악성 이미지를 피해자 조직의 레지스트리로 가져오려고 할 수 있습니다.	이것은 컨테이너 엔진 또는 이미지 저장소 로그.네트워크 방어자는 표준 배포 프로세스의 모든 변형을 조사해야 합니다.
특정 경우에 따라 이는 새 이미지 버전을 사용하여 재배포된 후 컨테이너의 동작 변경을 통해 감지할 수도 있습니다.
공격자가 컨테이너에서 명령 실행 기능을 획득하는 지점까지 애플리케이션을 악용하는 경우 파드의 구성에 따라 파드 내에서 API 요청을 할 수 있으며 잠재적으로 권한을 확대하고 내에서 측면으로 이동할 수 있습니다.
클러스터 또는 호스트에 침입.	Pod 내부에서 발생하는 비정상적인 API 요청(Kubernetes 감사 로그에서) 또는 비정상적인 시스템 호출(seccomp 로그에서).
이것은 또한 포드 IP 주소를 소스 IP로 등록하는 포드 생성 요청으로 표시될 수 있습니다.
Kubernetes 클러스터에 대한 초기 액세스 권한을 얻은 공격자는 kube-apiserver와 상호 작용해야 하는 클러스터에 더 깊이 침투하려고 시도하기 시작할 것입니다.	그들이 어떤 초기 단계를 결정하기 위해 노력하는 동안 권한이 있으면 API 서버에 여러 번 실패한 요청을 할 수 있습니다.
반복적으로 실패한 API 요청 및 특정 계정에 대해 비정상인 요청 패턴은 위험 신호입니다.
공격자는 피해자의 리소스를 사용하여 자체 크립토마이너를 실행하기 위해 클러스터를 손상시키려고 시도할 수 있습니다(즉, 크립토재킹 공격).	공격자가 크립토재킹 공격을 성공적으로 시작하면 로그에 리소스 소비가 갑자기 급증하는 것으로 표시될 수 있습니다.
공격자는 클러스터에서 활동의 귀속을 피하기 위해 익명 계정을 사용하려고 시도할 수 있습니다.	클러스터에서 모든 익명 작업을 관찰합니다.
공격자는 호스트에 액세스하기 위해 손상되었거나 생성 중인 컨테이너에 볼륨 마운트를 추가하려고 할 수 있습니다.	볼륨 마운트 작업은 이상이 있는지 면밀히 모니터링해야 합니다.
예약된 작업(Kubernetes CronJobs라고도 함)을 생성할 수 있는 공격자는 이를 사용하여 Kubernetes가 클러스터에서 맬웨어를 자동으로 반복적으로 실행하도록 할 수 있습니다[8].	예약된 작업 생성 및 수정을 면밀히 모니터링해야 합니다.

Alerting

Kubernetes는 기본적으로 경고를 지원하지 않습니다. 그러나 알림 기능이 있는 여러 모니터링 도구는 Kubernetes와 호환됩니다. Kubernetes 관리자가 Kubernetes 환경 내에서 작동하도록 알림 도구를 구성하도록 선택하는 경우 관리자는 여러 메트릭을 사용하여 알림을 모니터링하고 구성할 수 있습니다.

경고를 유발할 수 있는 실행 가능한 이벤트의 예에는 다음이 포함되지만 이에 국한되지는 않습니다.

• 환경에 있는 모든 시스템의 디스크 공간 부족,

• 부족한 로깅 볼륨의 사용 가능한 저장 공간,

• 외부 로깅 서비스가 오프라인으로 전환되고,

• 루트 권한으로 실행되는 포드 또는 애플리케이션,

• 권한이 없는 리소스에 대한 계정의 요청을 위한,

• API 서버에 제출되는 익명 요청,

• 포드 생성의 소스 ID로 나열되는 포드 또는 Worker nodes IP 주소 요구,

• 비정상적인 시스템 호출 또는 실패한 API 호출,

• 비정상적인 사용자/관리자 행동(즉, 비정상적인 시간에 또는 비정상적인 위치) 및

• 표준 운영 메트릭 기준선과의 상당한 편차.

2021년 Kubernetes 블로그 게시물에서 Kubernetes 프로젝트 기여자는 이 목록에 다음 세 가지를 추가했습니다[7].

• 파드의 securityContext 변경,

• 승인 컨트롤러 구성 업데이트 및

• 특정 민감한 파일/URL 액세스.

가능한 경우 관리자가 경고에 응답하는 동안 침해를 완화하기 위한 조치를 취하도록 시스템을 구성해야 합니다. Pod IP가 Pod 생성 요청의 소스 ID로 나열되는 경우 Pod를 자동으로 축출하는 것은 애플리케이션을 계속 사용 가능하게 유지하면서 클러스터의 손상을 일시적으로 중지하기 위해 구현할 수 있는 완화 방법 중 하나입니다. 이렇게 하면 Pod의 깨끗한 버전을 노드 중 하나로 다시 예약할 수 있습니다. 수사관은 로그를 조사하여 침해가 발생했는지, 그렇다면 침해가 발생한 경우 악의적인 행위자가 패치를 배포할 수 있도록 침해를 실행한 방법을 확인할 수 있습니다. 이러한 응답을 자동화하면 중요한 이벤트에 대한 보안 전문가의 응답 시간을 개선하는 데 도움이 될 수 있습니다.

tools

Kubernetes에는 기본적으로 광범위한 감사 기능이 포함되어 있지 않습니다. 그러나 시스템은 확장 가능하도록 구축되어 사용자가 자신만의 맞춤형 솔루션을 개발하거나 필요에 맞는 기존 추가 기능을 자유롭게 선택할 수 있습니다. Kubernetes 클러스터 관리자는 일반적으로 추가 백엔드 서비스를 클러스터에 연결하여 확장 검색 매개변수, 데이터 매핑 기능 및 경고 기능과 같은 사용자를 위한 추가 기능을 수행합니다. 이미 SIEM 플랫폼을 사용하는 조직은 Kubernetes를 이러한 기존 기능과 통합할 수 있습니다. Cloud Native Computing Foundation의 Prometheus®, Grafana Labs의 Grafana® 및 Elasticsearch의 Elastic Stack(ELK)®과 같은 오픈 소스 모니터링 도구도 사용할 수 있습니다. 이 도구는 이벤트 모니터링을 수행하고, 위협 분석을 실행하고, 경고를 관리하고, 실행 중인 컨테이너에 대한 리소스 격리 매개변수, 과거 사용량 및 네트워크 통계를 수집할 수 있습니다. RBAC에서 위험한 권한 구성을 식별하기 위해 액세스 제어 및 권한 구성을 감사할 때 스캐닝 도구를 사용할 수 있습니다.

NSA와 CISA는 기존 환경에서 IDS(침입 탐지 시스템)를 활용하는 조직이 해당 서비스를 Kubernetes 환경에 통합하는 것을 고려하도록 권장합니다. 이 통합을 통해 조직은 비정상적인 동작을 모니터링하고 잠재적으로 컨테이너를 종료할 수 있으므로 컨테이너를 초기 깨끗한 이미지에서 다시 시작할 수 있습니다. 많은 Cloud Service Provider는 더 관리되고 확장 가능한 솔루션을 원하는 사람들을 위해 컨테이너 모니터링 서비스도 제공합니다.

업그레이드 및 애플리케이션 보안 사례

이 문서에 요약된 강화 지침을 따르면 Kubernetes 오케스트레이션 컨테이너에서 실행되는 애플리케이션의 보안을 보장하기 위한 단계입니다. 그러나 보안은 지속적인 프로세스이며 패치, 업데이트 및 업그레이드를 따라가는 것이 중요합니다. 특정 소프트웨어 구성 요소는 개별 구성에 따라 다르지만 전체 시스템의 각 부분은 가능한 한 안전하게 유지되어야 합니다. 여기에는 Kubernetes, 하이퍼바이저, 가상화 소프트웨어, 플러그인, 환경이 실행되는 운영 체제, 서버에서 실행되는 애플리케이션, 조직의 CI/CD(지속적 통합/지속적 전달) 파이프라인의 모든 요소 및 에서 호스팅되는 기타 소프트웨어 업데이트가 포함됩니다. 환경.서비스를 위해 연중무휴 가동 시간을 유지해야 하는 회사는 고가용성 클러스터 사용을 고려할 수 있습니다. 이렇게 하면 서비스가 물리적 시스템에서 한 번에 하나씩 오프로드되어 펌웨어, 커널 및 운영 체제 업데이트가 배포될 수 있습니다. 서비스 가용성을 유지하면서 적시에.

CIS(Center for Internet Security)는 소프트웨어 보안을 위한 벤치마크를 게시합니다. 관리자는 Kubernetes 및 기타 관련 시스템 구성 요소에 대한 CIS 벤치마크를 준수해야 합니다. 관리자는 시스템 보안이 최신 사이버 보안 모범 사례를 준수하는지 주기적으로 확인해야 합니다. 다양한 시스템 구성 요소에 대해 정기적인 취약점 스캔 및 침투 테스트를 수행하여 안전하지 않은 구성과 제로 데이 취약점을 사전에 찾아야 합니다. 모든 발견은 잠재적인 사이버 범죄자가 발견하고 악용하기 전에 즉시 수정되어야 합니다.

관리자는 업데이트를 배포할 때 환경 및 배포 파이프라인에서 사용하지 않는 오래된 구성 요소를 제거하는 작업도 따라야 합니다. 이 방법은 공격 지점과 시스템에 남아 있는 사용하지 않는 도구의 위험과 구식이 될 위험을 줄이는 데 도움이 됩니다. 관리형 Kubernetes 서비스를 사용하면 Kubernetes, 운영 체제 및 네트워킹 프로토콜에 대한 업그레이드 및 패치를 자동화하는 데 도움이 될 수 있습니다. 그러나 관리자는 여전히 배포가 최신 상태인지 확인하고 개발자가 오래된 이미지의 우발적인 배포를 방지하기 위해 새 이미지에 적절하게 태그를 지정해야 합니다.

Works cited

[1] Center for Internet Security, "CIS Benchmarks Securing Kubernetes," 2021.[Online].Available: https://cisecurity.org/benchmark/kubernetes/.

[2] DISA, "Kubernetes STIG," 2021.[Online].Available: https://public.cyber.mil/stigs/downloads/.

[3] The Linux Foundation, "Kubernetes Documnetation," 2021.[Online].Available: https://kubernetes.io/docs/ .[Accessed 02 2021].

[4] The Linux Foundation, "11 Ways (Not) to Get Hacked," 18 07 2018.[Online].Available: https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/#10-scan-images-and-run- ids.[Accessed 03 2021].

[5] MITRE, "MITRE ATT&CK," 2021.[Online].Available: https://attack.mitre.org/techniques/T1552/005/.[Accessed 7 May 2021].

[6] CISA, "Analysis Report (AR21-013A)," 14 January 2021.[Online].Available: https://www.cisa.gov/uscert/ncas/analysis-reports/ar21-013a.[Accessed 26 May 2021].

[7] Kubernetes, "A Closer Look at NSA/CISA Kubernetes Hardening Guidance," 5 October 2021.[Online].Available: https://www.kubernetes.io/blog/2021/10/05/nsa-cisa-kubernetes- hardening-guidance/ 2021.

[8] MITRE ATT&CK, "Scheduled Task/Job: Container Orchestration Job," 27 7 2021.[Online].Available: https://attack.mitre.org/techniques/T1053/007/.[Accessed 9 11 2021].

[9] The Kubernetes Authors, "Pod Security Admission," [Online].Available: https://kubernetes.io/docs/concepts/security/pod-security-admission/.

Appendix

Appendix A: Example Dockerfile for non-root application

다음 예는 비그룹 멤버십이 있는 비루트 사용자로 애플리케이션을 실행하는 Dockerfile입니다. 아래에서 빨간색으로 강조 표시된 줄은 루트가 아닌 사용과 관련된 부분입니다.

Appendix B: Example deployment template for read-only file system (읽기 전용 파일 시스템용 배포 템플릿 예)

다음 예는 읽기 전용 루트 파일 시스템을 사용하는 Kubernetes 배포 템플릿입니다. 아래 빨간색으로 강조 표시된 줄은 컨테이너의 파일 시스템을 읽기 전용으로 만드는 부분입니다. 파란색으로 강조 표시된 선은 이 기능이 필요한 응용 프로그램에 대해 쓰기 가능한 볼륨을 만드는 방법을 보여주는 부분입니다.

Appendix C: Pod Security Policies (deprecated) (포드 보안 정책(더 이상 사용되지 않음))

Appendix D: Example Pod Security Policy

다음 예는 클러스터에서 실행되는 컨테이너에 대한 강력한 보안 요구 사항을 적용하는 Kubernetes Pod 보안 정책입니다. 이 예는 공식 Kubernetes 문서(https://kubernetes.io/docs/concepts/policy/pod-security-policy/)를 기반으로 합니다. 관리자는 조직의 요구 사항에 맞게 정책을 조정하는 것이 좋습니다.

Appendix E: Example namespace

다음 예는 각 팀 또는 사용자 그룹에 대한 것으로 kubectl 명령 또는 YAML 파일을 사용하여 Kubernetes 네임스페이스를 생성할 수 있습니다. 접두사가 kube-인 이름은 Kubernetes 시스템 예약 네임스페이스와 충돌할 수 있으므로 피해야 합니다.

Kubectl command to create a namespace:

kubectl create namespace <insert-namespace-name-here>

YAML 파일을 사용하여 네임스페이스를 생성하려면 다음 내용으로 my-namespace.yaml이라는 새 파일을 생성합니다.

apiVersion: v1
kind: Namespace
metadata:
  name: <insert-namespace-name-here>

Apply the namespace using:

kubectl create –f ./my-namespace.yaml

To create new Pods in an existing namespace, switch to the desired namespace using:

kubectl config use-context <insert-namespace-here>

Apply new deployment using:

kubectl apply -f deployment.yaml

Alternatively, the namespace can be added to the kubectl command using:

kubectl apply -f deployment.yaml --namespace=<insert-namespace-here>

or specify namespace: <insert-namespace-here> under metadata in the YAML declaration.

또는 YAML 선언의 메타데이터 아래에 namespace: <insert-namespace-here>를 지정합니다.

리소스는 일단 생성되면 네임스페이스 간에 이동할 수 없습니다.리소스를 삭제한 다음 새 네임스페이스에서 생성해야 합니다.

Appendix F: Example network policy

네트워크 정책은 사용하는 네트워크 플러그인에 따라 다릅니다. 다음 예제는 Kubernetes 문서를 사용하여 레이블 액세스 권한이 있는 Pod로 nginx 서비스에 대한 액세스를 제한하는 네트워크 정책입니다. https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/

apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
   name: example-access-nginx
namespace: prod #this can any namespace or be left out if no namespace is used
spec:
      podSelector:
          matchLabels:
              app: nginx
      ingress:
      -from:
          -podSelector:
              matchLabels:
                  access: "true"

The new NetworkPolicy can be applied using:

kubectl apply -f policy.yaml

A default deny all ingress policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-ingress
spec:
podSelector: {}
policyType: - Ingress

A default deny all egress policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-egress
spec:
podSelector: {}
policyType: - Egress

Appendix G: Example LimitRange

LimitRange support is enabled by default in Kubernetes 1.10 and newer. The following YAML file specifies a LimitRange with a default request and limit, as well as a min and max request, for each container.

  apiVersion: v1
  kind: LimitRange
  metadata:
     name: cpu-min-max-demo-lr
  spec:
     limits
     -  default:
           cpu: 1
        defaultRequest:
          cpu: 0.5
        max:
          cpu: 2
        min:
           cpu 0.5
        type: Container

A LimitRange can be applied to a namespace with:

kubectl apply -f <example-LimitRange>.yaml --namespace=<Enter-Namespace>

이 예제 LimitRange 구성이 적용된 후에는 네임스페이스에서 생성된 모든 컨테이너에 기본 CPU 요청이 할당되고 지정되지 않은 경우 제한이 할당됩니다. 네임스페이스의 모든 컨테이너에는 최소값보다 크거나 같고 최소값보다 작거나 같은 CPU 요청이 있어야 합니다. 최대 CPU 값 또는 컨테이너는 인스턴스화되지 않습니다.

Appendix H: Example ResourceQuota

네임스페이스 내에서 집계 리소스 사용을 제한하는 ResourceQuota 개체는 YAML 파일을 네임스페이스에 적용하거나 Pod의 구성 파일에서 요구 사항을 지정하여 생성됩니다.다음 예제는 공식 Kubernetes 문서를 기반으로 합니다. https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/

Configuration file for a namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: example-cpu-mem-resourcequota
spec:
  hard:
    requests.cpu: '1'
    requests.memory: 1Gi
    limits.cpu: '2'
    limits.memory: 2Gi

This ResourceQuota can be applied with:

kubectl apply -f example-cpu-mem-resourcequota.yaml -- namespace=<insert-namespace-here>

This ResourceQuota places the following constraints on the chosen namespace:

• Every container must have a memory request, memory limit, CPU request, and CPU limit,(모든 컨테이너에는 메모리 요청, 메모리 제한, CPU 요청 및 CPU 제한이 있어야 합니다.)

• Aggregate memory request for all containers should not exceed 1 GiB,(모든 컨테이너에 대한 총 메모리 요청은 1GiB를 초과하지 않아야 합니다.)

• Total memory limit for all containers should not exceed 2 GiB,(모든 컨테이너의 총 메모리 제한은 2GiB를 초과하지 않아야 합니다.)

• Aggregate CPU request for all containers should not exceed 1 CPU, and (모든 컨테이너에 대한 총 CPU 요청은 1 CPU를 초과하지 않아야 하며,)

• Total CPU limit for all containers should not exceed 2 CPUs.(모든 컨테이너의 총 CPU 제한은 2개의 CPU를 초과할 수 없습니다.)

Appendix I: Example encryption

유휴 상태의 Secret 데이터를 암호화하기 위해 다음 암호화 구성 파일은 원하는 암호화 유형과 암호화 키를 지정하는 예를 제공합니다. 암호화 파일에 암호화 키를 저장하면 보안이 약간 향상됩니다. 비밀은 암호화되지만 키는 EncryptionConfiguration 파일에서 액세스할 수 있습니다. 이 예는 공식 Kubernetes 문서(https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)를 기반으로 합니다.

apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources:
-  resources:
  -  secrets
  providers:
  -  aescbc:
        keys:
        -  name: key1
            secret: <base 64 encoded secret>
  -  identity: {}

이 암호화 파일로 저장 시 암호화를 활성화하려면 구성 파일의 위치와 함께 -- encryption-provider-config 플래그를 설정하여 API 서버를 다시 시작합니다.

Appendix J: Example KMS configuration

KMS(키 관리 서비스) 공급자 플러그인으로 Secrets를 암호화하려면 다음 예제 암호화 구성 YAML 파일을 사용하여 공급자의 속성을 설정할 수 있습니다.이 예는 공식 Kubernetes 문서(https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/)를 기반으로 합니다.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - kms:
          name: myKMSPlugin
          endpoint: unix://tmp/socketfile.sock
          cachesize: 100
          timeout: 3s
      - identity: {}

KMS 공급자를 사용하도록 API 서버를 구성하려면 구성 파일의 위치로 --encryption- provider-config 플래그를 설정하고 API 서버를 다시 시작합니다. 로컬 암호화 공급자에서 KMS로 전환하려면 아래와 같이 현재 암호화 방법 위에 EncryptionConfiguration 파일의 KMS 공급자 섹션을 추가합니다.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - kms:
          name: myKMSPlugin
          endpoint: unix://tmp/socketfile.sock
          cachesize: 100
          timeout: 3s
      - aescbc:
          keys:
            - name: key1
              secret: <base64 encoded secret>

API 서버를 다시 시작하고 아래 명령을 실행하여 KMS 공급자를 사용하여 모든 비밀을 다시 암호화합니다.

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Appendix K: Example pod-reader RBAC Role

예제 pod-reader 역할을 생성하려면 다음 콘텐츠가 포함된 YAML 파일을 생성합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: your-namespace-name
  name: pod-reader
rules:
  - apiGroups: [''] # "" indicates the core API group
    resources: ['pods']
    verbs: ['get', 'watch', 'list']

Apply the Role using:

kubectl apply --f role.yaml

To create the example global-pod-reader ClusterRole:

예제 global-pod-reader ClusterRole을 생성하려면:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: default
# "namespace" omitted since ClusterRoles are not bound to a namespace
   name: global-pod-reader
  rules:
  -  apiGroups: [""] # "" indicates the core API group
     resources: ["pods"]
     verbs: ["get", "watch", "list"]

Apply the Role using: kubectl apply --f clusterrole.yaml

Appendix L: Example RBAC RoleBinding and ClusterRoleBinding(RBAC RoleBinding 및 ClusterRoleBinding의 예)

RoleBinding을 만들려면 다음 내용으로 YAML 파일을 만듭니다.

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read Pods in the "your- namespace-name"
# namespace.
# You need to already have a Role names "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: your-namespace-name
subjects:
# You can specify more than one "subject"
-  kind: User
    name: jane # "name" is case sensitive
    apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role/ClusterRole # kind: Role # this must be a Role or ClusterRole
# this must match the name of the Role or ClusterRole you wish to bind to
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

To create a ClusterRoleBinding, create a YAML file with the following contents:

ClusterRoleBinding을 생성하려면 다음 내용으로 YAML 파일을 생성합니다.

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binging allows anyone in the "manager" group to read
# Pod information in any namespace.
kind: ClusterRoleBinding
metadata:
      name: global-pod-reader
subjects:
# You can specify more than one "subject"
-  kind: Group
    name: manager # Name is case sensitive
    apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role/ClusterRole kind: ClusterRole # this must be a Role or ClusterRole
  name: global-pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

Apply the RoleBinding using:

kubectl apply --f clusterrolebinding.yaml

Appendix M: Audit Policy

다음 예는 메타데이터 수준에서 Kubernetes 비밀과 관련된 요청을 기록하고 가장 높은 수준에서 다른 모든 감사 이벤트를 기록하는 감사 정책입니다.

apiVersion: audit.k8s.io/v1
  kind: Policy
  rules:
     -  level: Metadata
         resources:
- group:"" #this refers to the core API group resources: ["secrets"]
     -  level: RequestResponse
# This audit policy logs events involving secrets at the metadata level, and all other audit events at the RequestResponse level

조직에 많은 수의 로그를 저장, 구문 분석 및 검사하는 데 사용할 수 있는 리소스가 있는 경우 최고 수준에서 Secrets와 관련된 이벤트를 제외한 모든 이벤트를 로깅하는 것은 위반이 발생했을 때 필요한 모든 이벤트를 확인하는 좋은 방법입니다. 컨텍스트 정보가 로그에 있습니다. 리소스 소비 및 가용성이 우려되는 경우 시스템에 대한 감사 로깅 요구 사항이 충족되는 한 중요하지 않은 구성 요소 및 권한이 없는 일상적인 작업의 로깅 수준을 낮추기 위해 더 많은 로깅 규칙을 설정할 수 있습니다. Kubernetes API 이벤트는 여러 단계로 구성되므로 로깅 규칙은 요청의 단계를 지정하여 로그에서 생략할 수도 있습니다. 기본적으로 Kubernetes는 요청의 모든 단계에서 감사 이벤트를 캡처합니다.Kubernetes API 요청의 4가지 가능한 단계는 다음과 같습니다.

• RequestReceived

• ResponseStarted

• ResponseComplete

• Panic

조직의 클러스터는 증가하는 요구 사항을 충족하도록 확장되므로 감사 정책이 로깅 요구 사항을 계속 충족할 수 있는지 확인하는 것이 중요합니다. 환경 요소가 간과되지 않도록 감사 정책은 이전 규칙이 기록하지 않은 이벤트를 기록하는 포괄 규칙으로 끝나야 합니다. Kubernetes는 지정된 이벤트에 적용되는 감사 정책의 첫 번째 규칙을 기반으로 감사 이벤트를 기록합니다. 따라서 잠재적으로 겹치는 규칙이 작성되는 순서를 아는 것이 중요합니다.비밀에 관한 규칙은 보장하기 위해 정책 파일의 맨 위에 있어야 합니다. 이렇게 하면 메타데이터 수준보다 높은 수준의 로깅으로 인해 겹치는 규칙이 실수로 비밀을 캡처하지 않습니다. 마찬가지로 포괄 규칙은 다른 모든 규칙이 먼저 일치하도록 하는 정책의 마지막 규칙이어야 합니다.

다음은 Request 또는 RequestResponse 수준에서 기록해야 하는 중요한 이벤트 유형의 몇 가지 예입니다. 또한 로그의 중복성을 줄이고 가능한 한 실시간에 가깝게 로그를 효과적으로 검토할 수 있는 조직의 능력을 높이기 위해 필요한 경우 더 낮은 수준에서 기록할 수 있는 덜 중요한 이벤트 유형 및 단계의 예입니다.

Critical:

• 포드 배포 및 변경

• 인증 요청

• RBAC 리소스 수정(clusterrolebindings, clusterroles 등)

• 예약된 작업 생성

• 포드 보안 승인 또는 포드 보안 정책에 대한 편집

Noncritical:

• RequestReceived 단계

• 중요하지 않고 일상적으로 액세스되는 리소스에 대한 인증된 요청

이러한 규칙을 설정하는 방법의 예는 공식 Kubernetes 문서를 참조하십시오: https://kubernetes.io/docs/tasks/debug-application-cluster/audit/.

Appendix N: Example Flags to Enable Audit Logging

control plane의 텍스트 편집기에서 kube-apiserver.yaml 파일을 엽니다.kube-apiserver 구성을 편집하려면 관리자 권한이 필요합니다.

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

Add the following text to the kube-apiserver.yaml file:

kube-apiserver.yaml 파일에 다음 텍스트를 추가합니다.

--audit-policy-file=/etc/kubernetes/policy/audit-policy.yaml
--audit-log-path=/var/log/audit.log
--audit-log-maxage=1825

audit-policy-file 플래그는 감사 정책에 대한 경로로 설정되어야 하고, audit-log-path 플래그는 감사 로그가 기록될 원하는 보안 위치로 설정되어야 합니다.로그를 보관해야 하는 최대 일수를 지정하는 여기에 표시된 audit-log-maxage 플래그와 보관할 감사 로그 파일의 최대 수, 최대 로그 파일 크기(MB)를 지정하는 플래그와 같은 기타 추가 플래그가 있습니다.등.로깅을 활성화하는 데 필요한 유일한 플래그는 audit-policy-file 및 audit-log-path 플래그입니다.다른 플래그를 사용하여 조직의 정책과 일치하도록 로깅을 구성할 수 있습니다.

사용자의 kube-apiserver가 Pod로 실행되는 경우 볼륨을 마운트하고 감사 레코드를 보관할 정책 및 로그 파일 위치의 hostPath를 구성해야 합니다.이것은 Kubernetes 문서에 명시된 대로 kube-apiserver.yaml 파일에 다음 섹션을 추가하여 수행할 수 있습니다. https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/audit.log
    name: audit-log
    readOnly: false

volumes:
  - hostPath:
      path: /etc/kubernetes/audit-policy.yaml
      type: File
    name: audit
  - hostPath:
      path: /var/log/audit.log
      type: FileOrCreate
    name: audit-log