k8s :: k8s Security - 10 Best Practices

 

아래 Youtube 영상을 보고 개인적으로 정리한 내용입니다.

 

https://youtu.be/oBf5lrmquYI?si=Ltcd7YUFGa0nYNY1

• kubernetes의 워크로드를 올리는 관점 외, Cluster의 Security 관점에서 아래와 같이 10가지 주제를 간단히 소개하고 있습니다.

Intro (Cloud 와 Security)

 

 

대부분의 워크로드들이 "Cloud"로 이동하는 트렌드 속에서, 빈번하게 발생하는 오해 중 하나가 "기본적으로 Cloud는 안전하다고 생각하는 점"이다. 이는 "오해"이며, 워크로드가 비록 "Cloud"위 에 있다고 해도 Security 는 기존의 On-Premise와 동일한 수준으로 유지해야 한다.

Security는 Multiple Protection Mechansim x On Multi Levels 의 조합으로 애초에 한두가지 기술로 해결할 수 없는 분야이다.
예를 들어, kubernetes 환경 위에서 Application Workload를 실행 한다고 하면 (1) Underyling Infrastrucutre, (2) Kubernetes Level, (3) Application Level 으로 나눌 수 있으며, 모든 (1)~(3) 레벨에서 보안을 신경써야 한다. 또한 개발 영역에서는 코드의 '반복'을 좋지 않은 것으로 여기지만, 반대로 보안의 분야에서는 반복이 필수이다.
마지막으로 Security 분야의 또 다른 특 중 하나로 공격자(해커)가 매우 유리할 수 밖에 없다. 공격자는 딱 '1개'의 Security Weak Link만 찾아도 되기 때문이다.

Kubernetes Security 10 Best Practices

이제 kubernetes Cluster 관점 에서 Security와 관련된 10가지 Best Practices를 알아보자.

1. 안전한 Container Image 사용과 Image Scanning 도입하자

만약 취약점이 있는 Image 를 사용하고 해당 Image로 실행된 Container를 공격자에게 탈취될 경우, Container 뿐만 아니라 Host의 Volume, File System, Kubelet Config 등을 공격까지 당할 위험이 도사리고 있다.

따라서 아래와 같은 규칙을 통해 "안전한" Image를 제작하자.

Image 제작 시 지켜야 할 사항

• Image 를 제작할 때 "신뢰 할 수 없는"레지스트리에서 코드를 가져오지 말자.
• 또한 "취약점이 있는" OS Tools 이나 Library를 사용중인 것은 아닌지 확인하자.
• 워크로드를 실행하기 위해 "반드시 필요하지 않은" 의존성(Dependencies)들은 모두 제거하자.
• (예를 들어, Base Image로 apline linux를 사용)

Image Scanning

• 취약점이 있는 이미지를 식별하기 위해서 "Image Scanning"을 수행하자.
• Image Scanning 을 수행하는 시점은, CI/CD 파이프라인 과정 내 이미지를 Build 하는 시점에 함께 수행한다.
• 단, 이미지를 빌드 한 이후에도 새로운 취약점이 발견 및 식별 될 수 있으므로 (이미 빌드되어) Registry 내에 존재하는 Image들도 정기적으로 스캐닝을 수행하자.
• 관련해서 Trivy와 같은 이미지 스캐닝 Tools이 있으니 알아보자.

2 - 컨테이너 실행 시 root 로 실행하지 않기

만약 root(UID 0) 로 Continaer를 실행하게 되면, 해당 Container 를 탈취한 공격자가 Privilege Escalation을 통해, Container 외부의 Host를 공격 및 탈취 할 수도 있다.
따라서 이미지를 빌드 할 때 USER myapp 과 같이 명시하여, 반드시 실행 시에는 non-root 유저로 실행하도록 변경해야 한다.

단, 이미지 빌드 시점에서는 비록 위와 같이 non-root 유저를 사용하도록 지정하였어도, 해당 이미지가 실제 실행되는 시점인 kubernetes 레벨에서 "mis-configuration"을 통해 overwrite 를 해버릴 수가 있다.

• ex. allowPrivilegeEscalation: true

따라서 이미지 빌드 시점 뿐만 아니라, 실제 "Pod 생성 시점"에도 위와 같은 옵션들을 반드시 false 처리하고, runAsUser:1000 처럼 non-root로 실행 되도록 반드시 명시할 필요가 있다.

3 - RBAC을 통한 User와 Permission을 관리하자

RBAC을 통해서 User와 Permission을 관리하되, 가장 중요한 사항은 Privilieges는 최대한 "Restricitve" 하게 제공하는 것이다. 즉, 정말 필요한 권한만 부여하고 이외의 권한은 주지 않는 것이다.

kubernetes's User

• Kubernetes에서는 "User"라는 리소스를 별도를 관리하지 않는다.
• Cluster Admin은 "User"라는 리소스에 대해 여러가지 Authentication 에 대한 전략을 고를 수 있다.
• (ex. Statick Token, Certificate, 3rd Identify Service)

kubernetes's Service Account

• kubernetes의 Application user를 나타내며 kubernetes에서 직접 관리하는 리소스이다.
• Service Account의 경우 Token 기반으로 API Server와 Authentication을 진행한다.

4 - NetworkPolicy를 통한 Pod 간 통신을 제어하자

기본(default)적으로 Cluster 내 모든 Pod 간에는 통신이 자유롭게 가능한 상태이고, 이는 보안상 위험할 수 밖에 없다.
따라서 먼저 Pod들의 모든 Communication을 식별하고, 이후 이들을 제어하기 위해 Cluster 내에 적절한 NetworkPolicy를 구성 및 반영해야 한다.

• NetworkPolicy를 구성하기 전에, 가장 중요한 것은 Pod 간에 발생하는 Commuication의 Rules들을 명확히 '식별'하는 것이다.
• 식별 이후 NetworkPolicy를 통해서 트래픽을 제어할 때는, 적용 단위로 IP Address 혹은 Port Level로 제어가 가능하다.
• 또한 Network Policy를 구성 할 때는 (마치 RBAC과 동일하게), 대상 Pod에서 "필요한 Communication"만 Allowed 처리 해준다.
• 그리고 NetworkPolicy의 실제 구현은, 해당 Cluster에 설치된 CNI Plugin에 의해 '구현'된다.
• 만약 NetworkPolicy가 구현되지 않은 CNI를 사용중이라면, (당연하게도) NetworkPolicy를 선언해도 아무런 효과가 없다.
• 만약 "Pod" 레벨에서의 통신 제어가 아닌, 한단계 더 상위인 "Service" 레벨에서의 통신을 제어하려면 Istio 와 같은 Service Mesh의 도입을 검토하자.

5 - Communication을 암호화하자

기본적으로 Pod 간 통신은 암호화 되지 않은 채로 통신한다. 따라서 공격자에 의해 특정 Pod 등을 탈취 당하게 되면, 공격자가 Pod 간의 통신 내용을 Plain Text 구조 읽을 수 있게 된다.

따라서 관련된 Best Practive로 Pod 간 통신을 mTLS 기반으로 암호화 하는 것이다.

• 이를 위해, istio와 같은 Service Mesh 구성을 통해 Pod 통신 간 mTLS를 구현 할 수 있다.

6 - Secret Data를 안전하게 저장하자

주로 Secret은 아래와 같이 Sensitive 한 데이터를 보관(store)하는데 사용한다.

• ex. credentials, Secret Tokens, Private Keys, ...

하지만 Secret을 기본설정으로 사용하게 되면 base64 기반의 인코딩만 이루어지기 때문에 안전하지 않다. 예를 들어 공격자가 Secret 리소스 자체에 대해 조회가 가능하면, 안에 보관되어 있는 단순히 인코딩 된 데이터도 조회가 가능하다.

따라서 Secret 내 Data를 안전하게 보관하기 위한 방법 중 하나로는 kubernetes 자체의 고유한 솔루션을 사용하는 것이다.

• EncryptConfiguration 라는 고유한 리소스를 통해서 암호화 활성화를 하는 것이다.
• 단, 이는 암호화 키를 별도로 관리 해야하는 단점이 있다.
• 이를 위해 AWS KMS 와 같은 3rd Party의 Key manager 도입이 필요 할 수도 있다.

두번째 방법으로는 3rd Party의 Secret Management solution 을 사용하는 것이다.

• 대표적인 예로 vault 와 같은 3rd-party secret management tool 을 사용해서, Secret 리소스 내 데이터를 보다 안전하게 저장할 수 있다.

7 - ETCD를 안전하게 보호하자

kubernetes의 클러스터 데이터는 모두 ETCD에 저장된다. 따라서 공격자가 ETCD 접근이 가능하게 되면, API Server 를 우회하는 등을 통해 리소스 강제 업데이트 등의 공격이 가능하다. 사실상 클러스터에 무제한 접근 권한이 탈취되는 것이나 마찬가지 이다.

따라서 ETCD를 안전하게 보호하기 위해, 아래와 같은 여러가지 보안적 조치를 취해야 한다.

• ETCD는 Cluster 내부에서 실행하지 않고, Cluster 외부에서 실행한다. (External-ETCD)
• ETCD의 네트워크에 Firewall 을 세우고, 오직 API Server 만 접근하도록 보호한다.
• ETCD 내 데이터를 암호화 한다 등.

8 - 백업과 복구를 자동화하자

ETCD에는 Clutser와 관련된 Manifest 등이 저장되지만, Application들의 Data들은 다른 데이터베이스에 저장된다.
그리고 해당 데이터베이스에는 (애플리케이션에 따라) 신용카드 정보, 의료기록 등 민감한 정보가 있을 수 있기 때문에, 공격자가 읽거나 조작하지 못하도록 이러한 데이터베이스를 안전하게 지켜야만 한다.

이를 위해 Best Practice 중 하나로, 자동화된 백업과 복구를 사용하는 것이다.

• 정기적으로 데이터를 백업하고, 백업을 안전하게 저장한다.
• 그리고 Cluster에 해당 데이터 복구를 쉽게 만든다.
• 특히 중요한 점은, 백업 데이터 역시 높은 보안수준을 통해서 공격자가 접근 할 수 없도록 해야 한다.

9 - Security Policies를 구성하자

Security와 관련된 Best Practices를 숙지하고 항상 Cluster 에 적용해야 하지만, 결국 사람에 의한 misconfiguration은 보안 취약점의 가장 큰 이슈이다.

이를 개선하기 위한 Best Practice 중 하나로 Policy as Code 방식을 통해서 항상 의도된 Policy 들이 반영되는 것을 보장할 수 있도록 하자. (예를 들면, Pod를 root 권한으로 실행하지 않도록 막기 등)

• 관련해서는 Third Party 도구들로 Kyverno, Open Policy Agent 등이 있다.
• 이러한 도구를 사용하게 되면, Cluster 내 "Admission Controller" 영역에 도입되면서 구성한 Security Policy 관점에서 Validation을 수행하게 된다.
• 이와 같은 Automated Validation을 통해서 Security Polices를 의도대로 항상 유지할 수 있게 된다.

10 - Disaster Recovery를 도입하자

아무리 잘 막는다고 해도 모든 것을 100% 보호를 보장할 수는 없다. 특히 보안 특성상 공격자의 경우 정말 단 '하나의 길'만 찾으면 되니깐 절대적으로 유리할 수 밖에 없다.

따라서 "잘 막는다" 라는 관점 이외에도, 공격자에 의해 Cluster가 파괴 되었을 때 등을 고려해 "Disatser Recovery" 관점에서도 적절한 전략이 있어야 한다.

• 예시로 백업 데이터로 숏타임 내에 복구를 해야 하고 유저 경험에 최소한의 영향을 주어야 한다.
• 이를 위해 Automated 되고, 잘 테스트 된 Recovery Plan을 세운다.