모범 사례로 Kubernetes 클러스터 보호 방법

현재 Kubernetes는 이미 소프트웨어 인프라 시설의 불가피한 일부분이 되었다.만약 기업이나 중형/대형 회사라면, 작업 부하를 위해 Kubernetes 그룹을 실행하고 있을 가능성이 높습니다.만약 당신이 DevOps 엔지니어라면, on-prem Kubernetes 그룹을 유지하고 있거나, 아마존 EKS, Microsoft AKS, GKE 같은PaaS를 유지하고 있을 가능성이 높습니다.그러나 Kubernetes 클러스터를 어떻게 실행하든 보안을 유지해야 합니다.
Kubernetes API 서버는 다중 보안 기능을 제공합니다.

Transport security: 모든 API 통신은 유효한 인증서를 사용하여 TLS(전송층 보안)를 통해 이루어집니다.

Authentication: 모든 API 요청은 Kubernetes가 지원하는 몇 가지 인증 메커니즘 중 하나로 인증됩니다.

Authorization: 모든 신분 검증을 거친 요청은 지원되는 권한 수여 모델을 사용하여 권한을 수여한다.

Admission control: 읽기/수령 요청을 제외한 모든 권한 수여 요청은 접근 제어 모듈에 의해 검증된다.

Kubernetes는 기존의 많은 안전 옵션을 제공하지만, 방탄 인프라를 위해 더 많은 안전 최선의 실천을 고려해야 합니다.오늘 우리는 Kubernetes의 몇 가지 중요한 안전 최선의 실천을 탐구할 것이다.

1. Kubernetes 역할 기반 액세스 제어(RBAC) 사용

Kubernetes는 API 서버에 대해 여러 가지 인증 모델을 지원합니다.이것들은 ABAC (Attributed-Based Access Control), RBAC (Role-Based Access Control), Node authorization과 Webhook mode이다.그 중에서 RBAC는 더욱 안전하고 광범위하게 응용되어 기업과 중대형 조직의 이상적인 선택이다.RBAC를 사용하면 조직의 비즈니스 규칙과 매우 유사한 역할 기반 액세스 제어를 정의할 수 있습니다.RBAC는 OIDC 인증과 함께 사용할 수도 있습니다.
기본적으로 대부분의 Kubernetes 릴리스에서는 RBAC가 활성화되어 있습니다.명령 kubectl cluster-info dump | grep authorization-mode을 실행하여 이 점을 검사할 수 있습니다. 이 명령의 출력에는 authorization-mode=RBAC이 있을 것입니다.없으면 클러스터를 만들거나 수정할 때 API 서버의 --authorization-mode 플래그를 사용하여 활성화할 수 있습니다.예를 들어, --authorization-mode=RBAC,Node을 설정하면 클러스터에서 RBAC와 노드 라이센스가 모두 활성화됩니다.
RBAC를 사용하면 역할(Role/ClusterRole)과 바인딩(RoleBinding/ClusterRoleBinding)을 생성하여 리소스에 대한 액세스를 제어할 수 있습니다.다음은pod와 서비스를 볼 수 있도록 캐릭터와 캐릭터가 연결된 예시입니다.

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

다음은 상술한 캐릭터를 특정한 사용자 그룹에 귀속시킨다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-services
  namespace: fancy-namespace
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-service-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io
subjects: # subject can be individual users or a group of users. Group is defined in the external authentication service, in this case, an OIDC server
  - kind: Group
    name: k8s-restricted-users

2. OpenID Connect를 사용하여 API 서버 보호

Kubernetes는 다양한 인증 메커니즘을 지원합니다.가장 흔히 볼 수 있는 것은 다음과 같다.

클라이언트 인증서

기본 인증

기호화폐(서비스 계정 기호화폐, 무기명 기호화폐 등)

OpenID Connect (OIDC)

에이전트

OIDC는 이러한 모든 인증 메커니즘에서 가장 안전하고 확장 가능한 솔루션입니다.그것은 모든 사용자에게 단일 로그인 솔루션을 제공하고, 차량과 비차량 사용자가 쉽게 로그인할 수 있도록 하기 때문에 대형 단체가 방문하는 집단에 매우 적합하다.그것 또한 다른 메커니즘보다 안전하다. 왜냐하면 사용자의 컴퓨터에 고객 기밀과 비밀번호 같은 민감한 정보를 저장할 필요가 없기 때문이다.OIDC 공급업체에서 지원하는 경우 MFA과 Yubikey 등의 기능을 사용할 수 있습니다.

점점 더 많은 사람들이 집단에 접근하기 시작하면서 OIDC와 RBAC의 결합은 매우 필요하다.그룹 및 역할을 만들고 특정 그룹에 대한 제한된 액세스를 제공하는 것이 중요합니다.너는 나의 이전 게시물 How to Secure Your Kubernetes Cluster with OpenID Connect and RBAC에서 더 많은 것을 알 수 있다.

3. 적절한 액세스 권한을 가진 모든 중요 데이터에 대한 기밀 사용

이거 하나는 머리 안 써도 될 것 같은데.Kubernetes는 Secret 자원을 가지고 있어 민감한 데이터를 저장하는 데 사용할 수 있다.이것은 암호, 키, 기타 민감한 데이터를 저장하는 좋은 방법이다.기밀은 문자열 데이터, docker 설정, 인증서, 영패, 파일 등을 저장하는 데 사용할 수 있습니다.기밀은 용기에 사용할 수 있도록 데이터 볼륨으로 불러올 수도 있고 환경 변수로 공개할 수도 있다.비밀은 순수한 텍스트나 인코딩일 수 있지만 순수한 텍스트의 비밀을 사용하는 사람이 되지 마세요.
비밀은 유연하고 쿠베르네트 고유의 것이기 때문에 사용하지 않을 이유가 없다.또한 모든 사용자가 기밀에 액세스할 수 없도록 적절한 RBAC를 구현해야 합니다.

4. Kubernetes 버전을 최신 버전으로 유지

다른 소프트웨어와 마찬가지로 Kubernetes에도 결함과 문제가 있다.때때로 심각한 정도가 높은 버그가 발생할 수 있는데 CVE이 필요하다.따라서 서버와 CLI 클라이언트에서 Kubernetes 버전의 최신을 유지하는 것이 좋습니다.Kubernetes 버전에 보안 결함이 있는지 확인하려면 Kubernetes security and disclosure information website을 보십시오.만약에 위탁 관리paaS를 사용한다면 업그레이드는 매우 쉬울 것입니다. prem 설치에 있어 kOps, kubeadm 등 도구가 있어 집단을 쉽게 업그레이드할 수 있습니다.

5. kubelet, API 및 SSH 액세스 제한

kubelet은 각 노드에서 실행되는 주요'노드 에이전트'입니다. 기본적으로 kubelet의 HTTP 노드는 보호되지 않습니다.이로 인해 예기치 않은 액세스가 발생하여 should be restricted이 될 수 있습니다.
누군가가 Kubernetes 클러스터에 액세스할 수 있을 때, 그들은 k8s API 서버에 액세스하여 SSH를 클러스터 노드 자체에 연결할 수 있다.노드 접근을 제한하기 위해서는 가능한 한 집단 접근을 제한해야 한다.비관리자 사용자에 대한 SSH 액세스를 비활성화합니다.앞에서 보듯이 OIDC와 RBAC를 사용하여 API 서버를 보호하면 인증된 역할이 충분한 사용자만 API에 액세스할 수 있습니다.

6. 컨테이너 이미지 보호

집단에서 실행되는 용기 이미지를 보호하는 것은 집단 자체를 보호하는 것과 마찬가지로 중요하다.클러스터에서 실행되는 악성 이미지는 심각한 손상을 초래할 수 있습니다.다음 용기 이미지 안전에 대한 최선의 실천을 따르십시오.

은 호스트에 무한히 접근할 수 있도록 루트 사용자로 용기를 실행하지 마십시오.항상 비 루트 사용자를 사용하여 용기를 실행합니다.

은 CI/CD 단계에서 컨테이너 이미지 스캔을 활성화하여 clair 또는 Anchore과 같은 도구를 사용하여 알려진 취약점을 포착합니다.

은 가장 적은 최신 공식 기본 이미지를 사용하고 이미지에서 필요하지 않은 의존항, 패키지, 디버깅 도구를 삭제합니다. 이것은 더욱 안전하고 경량하기 때문입니다.

은 용기에 필요하지 않은 내장 모듈을 불러오는 것을 방지한다.노드의 /etc/modprobe.d/kubernetes-blacklist.conf에 있는 규칙을 사용하거나 노드에서 필요하지 않은 모듈을 마운트 해제하여 이러한 기능을 제한할 수 있습니다.

은 official verified images을 유행 소프트웨어에 사용합니다.비공식 이미지에 신뢰할 수 있는 등록표를 사용하고 이미지 발표자

을 시종 검증합니다

Docker Bench for Security을 사용하여 컨테이너 이미지 검토

Pod security policies을 사용하여 컨테이너의 호스트 액세스를

으로 추가 제한
자세한 내용은 Container Security: A Developer Guide에서 확인할 수 있습니다.

7. POD와 클러스터 간의 트래픽 제어

통상적으로 같은 집단 중의pod는 서로 통신할 수 있으며, 만약 같은 네트워크에 여러 집단이 있다면 그들 사이에도 통신량이 존재할 수 있다.네트워크에 있는 다른 클러스터가 영향을 받을 경우 클러스터가 손상될 수 있으므로 이 모든 것을 열지 마십시오.Kubernetes network policies을 사용하여 POD와 클러스터 간의 트래픽을 제어하고 필요한 트래픽만 허용합니다.

8. 명칭 공간으로 작업 부하 격리

이름 공간에서 모든 작업 부하를 실행하지 마십시오.비즈니스 요구 사항에 따라 다양한 이름의 공간에서 워크로드를 격리하는 것이 더 안전하고 RBAC를 사용하면 관리가 더 쉽습니다.이러한 방법으로 RBAC를 더 미세하게 조정하여 사용자가 볼 내용만 액세스할 수 있습니다.만약 적용된다면, Kubernetes 네트워크 정책을 사용하여 이름 공간 간의 통신을 격리할 수도 있습니다.

9. 자원 사용 제한

API 및 클러스터 자체를 보호하는 것과 마찬가지로 이름 공간과 리소스에 사용되는 CPU, 메모리 및 영구 디스크 공간에 리소스 제한을 설정해야 합니다.이것은 특정 용기가 모든 자원을 소모할 때 그룹이 서비스 공격을 거부하지 않도록 보호할 수 있다.Resources quotas과 limit ranges은 네임스페이스 레벨에서 제한을 설정할 수 있고 Requests and limits은 컨테이너 레벨에서 자원 제한을 설정할 수 있습니다.

10. 모니터링 도구를 사용하여 모든 트래픽을 모니터링하고 감사 로깅 사용

마지막으로 감시와 심사 집단도 매우 중요하다.Enable audit logging for the cluster, 그리고 감시 도구를 사용하여 집단 사이, 집단 및 집단 내의 네트워크 데이터를 감시한다.모니터링은 Prometheus,Grafana, 또는 전용 도구를 사용하여 할 수 있습니다.

보너스

또한 Kubernetes 클러스터를 보호할 때 이러한 인프라 모범 사례를 기억해야 합니다.

은 모든 트래픽이 TLS를 통해 이루어지는지 확인합니다.

은 TLS, 방화벽 및 암호화로 etcd를 보호하고 강력한 자격 증명을 사용하여 액세스를 제한합니다.

은 PaaS와 같은 지원되는 환경에서 IAM 액세스 정책을 설정합니다.

Secure the Kubernetes Control Plane .

은 인프라 자격 증명을 번갈아 가며 사용합니다.

은 AWS, Azure 또는 GCP 등 PaaS에서 실행할 때 클라우드 데이터 API 접근을 제한한다.

쿠베르네트스와 안전에 대한 더 많은 정보

Kubernetes, OIDC에 대해 더 알고 싶거나, OIDC를 Kubernetes와 함께 사용하거나, 일반적인 안전성에 대해 알고 싶으면, 이 추가 자원을 보십시오.

How to Secure Your Kubernetes Cluster with OpenID Connect and RBAC

Securing a Cluster

OpenID Connect Tokens

RBAC vs. ABAC: Definitions & When to Use

OAuth 2.0 and OpenID Connect Overview

Secure Access to AWS EKS Clusters for Admins

Managing Multiple Okta Instances with Terraform Cloud

만약 네가 이 강좌를 좋아한다면, 너는 우리가 발표한 다른 강좌를 좋아할 것이다.우리가 새로운 개발자 강좌를 발표할 때, 주목하고 알림을 받으십시오.