쿠버네티스 보안 가이드

쿠버네티스 보안

쿠버네티스 보안 가이드 – 쿠버네티스 보안 가이드는 쿠버네티스 클러스터를 보호하기 위한 초기 가이드로 제공됩니다.





 

쿠버네티스 호스트 보안

쿠버네티스를 배포하는 여러 옵션이 있습니다: 베어 메탈(bare metal), 온프레미스(on-premise), 그리고 퍼블릭 클라우드(가상 머신 상에서 사용자 정의된 쿠버네티스 빌드 또는 관리형 서비스 사용). 쿠버네티스는 매우 이동성이 뛰어나게 설계되어 있으며 고객은 이러한 설치 옵션들 사이를 쉽게 전환하며 워크로드를 이주할 수 있습니다.

쿠버네티스의 이러한 다양한 맞춤 설정은 다양한 시나리오에 적합하게 설계될 수 있다는 장점을 갖고 있지만, 보안 측면에서 가장 큰 약점이기도 합니다. 쿠버네티스는 기본적으로 맞춤 설정이 가능하도록 설계되어 있으며 사용자는 클러스터를 보호하기 위해 특정 기능을 활성화해야 합니다. 따라서 쿠버네티스 플랫폼을 배포하는 엔지니어들은 잠재적인 공격 경로와 취약점에 대해 알고 있어야 합니다.

최신 버전의 운영 체제를 설치하고, 운영 체제를 강화하며, 필요한 패치 관리 및 구성 관리 시스템을 구현하고, 필수적인 방화벽 규칙을 구현하고, 데이터 센터 환경에 따라 특정 보안 조치를 취하는 것이 권장됩니다.

 

쿠버네티스 버전

잠재적인 공격 경로를 모두 추적하는 것은 불가능해졌습니다. 이 사실은 잠재적인 위협에 대해 인식하고 대처하는 것보다 더 중요한 것은 없습니다. 가장 좋은 방어 수단은 최신 사용 가능한 쿠버네티스 버전을 실행하는 것입니다. 쿠버네티스 프로젝트는 가장 최근의 세 가지 마이너 릴리스를 위한 릴리스 브랜치를 유지하며, 심각도와 실행 가능성에 따라 해당 수정 사항을 해당 세 개의 릴리스 브랜치에 역백포팅(적용)하여 보완 및 보안 수정을 수행합니다. 패치 릴리스는 정기적으로 이러한 브랜치에서 생성되며, 필요에 따라 추가적인 긴급 릴리스가 이루어집니다. 따라서 항상 쿠버네티스 클러스터를 최신 사용 가능한 안정 버전으로 업그레이드하는 것이 권장됩니다.

추가 정보를 얻기 위해 버전 스큐 정책을 참조하는 것이 권장됩니다. 자세한 내용은 다음 링크를 참고하시기 바랍니다: https://kubernetes.io/docs/setup/release/version-skew-policy/.

롤링 업데이트 및 노드 풀 이전과 같은 여러 기술을 사용하여 최소한의 중단과 다운타임으로 업데이트를 완료할 수 있습니다.





 

쿠버네티스 컴포넌트 보안

민감한 포트에 대한 네트워크 접근 제어

쿠버네티스 클러스터는 일반적으로 잘 정의된 범위와 독특한 포트에서 수신하므로 클러스터를 식별하고 공격하기 쉬워집니다. 따라서 클러스터 및 클러스터 노드에서 인증과 권한 부여를 구성하는 것이 매우 권장됩니다.

 

쿠버네티스 노드에 대한 직접적인 액세스 제한

쿠버네티스 노드에 대한 SSH 액세스를 제한하여, 호스트 자원에 대한 무단 액세스 위험을 줄여야 합니다. 대신 사용자들에게 호스트에 액세스할 수 없는 “kubectl exec”를 사용하도록 요청해야 합니다. 이는 컨테이너 환경에 직접 액세스를 제공하지만 호스트에 접근할 수 없도록 합니다.

쿠버네티스 인가 플러그인을 사용하여 사용자의 자원 액세스를 더욱 세밀하게 제어할 수 있습니다. 이를 통해 특정 네임스페이스, 컨테이너 및 작업에 대한 세부적인 액세스 제어 규칙을 정의할 수 있습니다.

 

쿠버네티스 API 액세스 제어

쿠버네티스 플랫폼은 API 요청을 통해 제어되며, 이는 공격자에 대한 첫 번째 방어선입니다. 누가 액세스할 수 있는지와 어떤 작업을 수행할 수 있는지를 제어하는 것이 주요 관심사입니다. 자세한 정보는 아래 문서를 참고하세요: https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/

 

전체 트랜스포트 계층 보안(TLS) 사용

서비스 간 클러스터 내 통신은 기본적으로 모든 트래픽을 암호화하는 TLS를 사용하여 처리해야 합니다. 그러나 종종 클러스터가 안전하다고 생각되어 클러스터 내 전송 중 암호화가 필요하지 않다는 생각으로 간과되곤 합니다.

서비스 메시와 같은 네트워크 기술의 발전으로 LinkerD 및 Istio와 같은 제품들이 탄생하였습니다. 이들은 서비스 간 트랜잭션에 대한 추가적인 텔레메트리 정보를 제공하면서 기본적으로 TLS를 활성화할 수 있습니다.

쿠버네티스는 클러스터 내 API 통신이 TLS로 기본적으로 암호화되어야 한다고 기대하며, 대부분의 설치 방법은 필요한 인증서를 생성하고 클러스터 구성 요소에 배포할 수 있게 해줍니다. 그러나 일부 구성 요소와 설치 방법은 로컬 포트를 HTTP로 활성화할 수 있으며, 관리자는 각 구성 요소의 설정을 파악하여 잠재적으로 보안되지 않은 트래픽을 식별해야 합니다.

쿠버네티스 클러스터에서 TLS 사용에 대해 자세히 알아보려면 아래 문서를 참고하세요: https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/#1-tls-everywhere.






API 인증

쿠버네티스는 API 서버 인증을 위한 여러 내장 기구를 제공하지만, 이러한 기구들은 아마도 비생산적이거나 작은 클러스터에만 적합할 것입니다.

정적 토큰 파일 인증은 API 서버 노드에 저장된 CSV 파일 내의 평문 토큰을 활용합니다. 이 파일에서 자격 증명을 수정하려면 API 서버를 다시 시작해야 적용됩니다.

  • X509 클라이언트 인증서도 사용 가능하지만, 이들은 생산 환경에 적합하지 않습니다. 쿠버네티스는 인증서 폐기를 지원하지 않기 때문에 사용자 자격 증명을 수정하거나 폐기할 수 없으며, 루트 인증 기관 키를 회전하고 모든 클러스터 인증서를 다시 발급하지 않는 한 변경할 수 없습니다.
  • 서비스 계정 토큰도 사용 가능합니다. 그들의 주된 사용 목적은 클러스터에서 실행되는 작업 부하가 API 서버에 인증하는 것이지만, 사용자 인증에도 사용될 수 있습니다.
    더 큰 규모나 생산 클러스터에 대해 권장되는 접근 방식은 외부 인증 방법을 사용하는 것입니다:
  • OpenID Connect (OIDC)는 인증 외부화, 단기간 토큰 사용 및 권한 위임을 위해 중앙 집중식 그룹을 활용합니다.
  • GKE, EKS 및 AKS와 같은 관리형 쿠버네티스 배포는 해당 IAM 제공자의 자격 증명을 사용하여 인증을 지원합니다.
  • Kubernetes 임펄슨(Impersonation)은 관리형 클라우드 클러스터와 온프레미스 클러스터 모두에 사용될 수 있어 API 서버 구성 매개변수에 액세스할 필요 없이 인증을 외부화할 수 있습니다.

 

적절한 인증 시스템을 선택하는 것 외에도, API 액세스는 특권이며 모든 사용자 액세스에 대해 다중 인증(MFA)을 사용해야 합니다.

자세한 정보는 쿠버네티스 인증 참조 문서를 참고하세요: https://kubernetes.io/docs/reference/access-authn-authz/authentication






API 권한 부여 – 롤 기반 액세스 제어 구현

쿠버네티스에서는 권한 부여(인가)되기 전에 인증(로그인)되어야 합니다. 쿠버네티스는 REST API 요청에 대해 일반적인 속성을 예상합니다. 이는 쿠버네티스 인가가 기존 조직 전체 또는 클라우드 제공업체 전체의 액세스 제어 시스템과 작동함을 의미하며, 쿠버네티스 API 외에도 다른 API를 다룰 수 있습니다.

쿠버네티스는 API 서버를 사용하여 API 요청을 승인합니다. 모든 요청 속성을 모든 정책과 비교하고 요청을 허용하거나 거부합니다. 요청의 모든 부분은 어떤 정책에 의해 허용되어야만 계속될 수 있습니다. 이는 기본적으로 권한이 거부되는 것을 의미합니다.

롤 기반 액세스 제어(RBAC)는 조직 내 개별 사용자의 역할에 기반하여 컴퓨터나 네트워크 리소스에 대한 액세스를 규제하는 방법입니다.

쿠버네티스는 통합된 롤 기반의 액세스 제어(RBAC) 구성 요소를 제공하며, 들어오는 사용자나 그룹을 역할로 묶은 권한 집합에 대응합니다. 이러한 권한은 동사(가져오기, 생성, 삭제)와 리소스(팟, 서비스, 노드)를 결합하고 네임스페이스 또는 클러스터 범위로 설정할 수 있습니다. 쿠버네티스 클라이언트가 수행하려는 동작에 따라 책임을 합리적으로 분리하는 기본적인 역할 집합이 제공됩니다. 노드 및 RBAC 권한 부여자를 NodeRestriction 입장 플러그인과 함께 사용하는 것이 권장됩니다.

RBAC 권한 부여는 rbac.authorization.k8s.io API 그룹을 사용하여 인가 결정을 하며, 쿠버네티스 API를 통해 정책을 동적으로 구성할 수 있게 합니다. RBAC를 활성화하려면 –authorization-mode 플래그를 RBAC를 포함한 쉼표로 구분된 목록으로 설정하여 API 서버를 시작하면 됩니다.

RBAC 활용에 대한 자세한 예제는 쿠버네티스 문서를 참고하세요: https://kubernetes.io/docs/reference/access-authn-authz/rbac






ETCD 접근 제한

etcd는 쿠버네티스의 중요한 구성 요소로서 상태와 비밀 정보를 저장합니다. 나머지 클러스터와는 다르게 etcd를 보호해야 합니다. API 서버의 etcd에 대한 쓰기 액세스는 전체 클러스터에 관리자 권한을 획들한 것과 동일하며, 읽기 액세스조차도 권한을 쉽게 상승시키는 데 사용될 수 있습니다.

쿠버네티스 스케줄러는 노드가 없는 파드 정의를 etcd에서 찾습니다. 그런 다음 해당 파드를 스케줄링하기 위해 이를 사용 가능한 kubelet으로 전송합니다. 제출된 파드에 대한 유효성 검사는 API 서버에서 etcd에 기록하기 전에 수행되므로, 악의적인 사용자가 직접 etcd에 쓰기 작업을 하면 PodSecurityPolicies와 같은 여러 보안 메커니즘을 우회할 수 있습니다.

관리자는 API 서버에서 etcd 서버로의 강력한 자격 증명을 사용해야 합니다. 예를 들어 TLS 클라이언트 인증을 통한 상호 인증을 사용하며, API 서버만 액세스할 수 있는 방화벽 뒤에 etcd 서버를 격리하는 것이 종종 권장됩니다.

주의:

클러스터 내의 다른 구성 요소가 마스터 etcd 인스턴스에 전체 키 공간에 대한 읽기 또는 쓰기 액세스 권한을 부여하는 것은 클러스터 관리자 권한을 부여하는 것과 같습니다. 비마스터 구성 요소를 위해 별도의 etcd 인스턴스를 사용하거나 etcd ACL을 사용하여 키 공간의 일부에 대한 읽기 및 쓰기 액세스를 제한하는 것이 강력히 권장됩니다.





답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다