[Basic] 쿠버네티스 보안

쿠버네티스 보안

계정 인증

인증 (Authentication)

• 쿠버네티스는 계정 체제를 관리함에 있어서 사람이 사용하는 사용자 계정과 시스템이 사용하는 서비스 계정 두 가지 개념을 제공한다.

일반적인 사용자

• 일반적인 사용자는 우리가 일반적으로 생각하는 사용자 아이디의 개념이다.
• 쿠버네티스는 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템이 없다.
• 반드시 별도의 외부 계정 시스템을 사용해야 하며 계정 시스템 연동을 위해서 OAuth나 구글 계정(Google Account)이나 오픈스택의 키스톤(keystone)과 같은 계정 연동 방식을 지원한다.

서비스 계정

• 쿠버네티스가 직접 관리하는 사용자 계정이다.
• 클라이언트가 쿠버네티스 API를 호출하거나 콘솔이나 기타 클라이언트가 쿠버네티스 API를 접근하고자 할때 이는 실제 사용자가 아니라 시스템 계정이다.

인증 (Authentication) 방법

• Basic HTTP Auth: HTTP 요청에 사용자 아이디와 비밀번호를 실어 보내서 인증하는 방식이다.
• Access token via HTTP Header: 일반적인 REST API 인증에 많이 사용되는 방식이다.
• Client cert: 클라이언트의 식별을 인증서(Certification)를 이용해서 인증하는 방식이다.
• Custom made: 운영자가 필요에 따라 직접 인증 방식을 구현하는 방식이다.

권한 관리 (Authorization)

• 쿠버네티스의 권한 처리 체계는 기본적으로 역할 기반의 권한 인가 체계를 가지고 있다.
• ABAC(Attribute-based access control)와 RBAC(Role-based access control) 2가지 방법이 제공된다.

ABAC (Attribute-based access control)

• 단어의 의미 그대로 속성(Attribute) 기반의 권한 관리다.
• 사용가능한 속성으로는 일반적으로 사용자(user), 그룹(group), 요청 경로(request path), 요청 동사(request verb)등 외에도 네임 스페이스, 자원 등으로 설정한다.

RBAC (Role-based access control)

• 역할(Role) 기반으로 권한을 관리한다.
• 사용자와 역할을 별개로 선언한 다음에 그 두가지를 바인딩하여 사용자에게 권한을 부여한다.
• 서버에 접근할 필요없이 kubectl이나 API를 이용해서 관리하는 것이 가능하다.

---

네트워크 정책

네트워크 정책 개념

• 파드 그룹에 대해 서로간 또는 외부 네트워크 엔드포인트와의 통신 여부를 결정하는 정책이다.
• 네트워크 정책으로 파드간 통신, 네임스페이스간 통신, 포트 번호 지정 등을 서술적으로 설정할 수 있다.
• NetworkPolicy 리소스들은 파드들을 선택하고 선택된 파드들에 허용되는 트래픽을 특정하는 규칙을 정의하기 위해 레이블을 사용한다.
• 네트워크 정책들은 네트워크 프로바이더가 제공하는 네트워크 플러그인을 통해 실현된다.

Ingress 트래픽 컨트롤 정의

• ipBlock: CIDR IP 대역으로 특정 IP 대역에서만 트래픽이 들어오도록 지정할 수 있다.
• podSelector: label을 이용하여 특정 label을 가지고 있는 파드들에서 들어오는 트래픽만 수신 가능하도록 지정할 수 있다.
• namespaceSelector: 특정 namespace로부터 들어오는 트래픽만 수신 가능하도록 지정할 수 있다.
• Protocol & Port: 받을 수 있는 프로토콜과 허용되는 포트를 정의한다.

Egress 트래픽 컨트롤 정의

• Egress 트래픽 컨토를은 ipBlock과 Protocol & Port 두 가지만 지원한다.
• ipBlock: 트래픽이 나갈 수 있는 IP 대역을 정의한다.
• Protocol & Port: 트래픽을 내보낼 수 있는 프로토콜과 포트를 정의한다.

Using Cilium - Controlling Ingress/Egress from Namespaces

• 네트워크 폴리시(NetworkPolicy)로 실리움(Cilium)을 사용한다.

• 더 자세한 내용은 실리움 공식문서를 참고한다.

네트워킹 애드온

• 쿠버네티스는 클러스터 내부에 가상 네트워크를 구성해서 사용하는데 이때 kube-proxy 이외에 네트워킹 관련한 애드온을 사용한다.
• AWS, Azure, Google 클라우드와 같은 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 사용하지 않더라도 각 클라우드 벤더에서 구현되어 있다.
• 쿠버네티스를 직접 보유 중인 서버들에 설치해서 구성을 하려면 네트워킹 관련 애드온을 설치해서 사용해야 한다.
• 네트워킹 애드온의 종류는 ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Flannel, Multus, NSX-T, Nuage, Romana, WeaveNet 등이 있고, OCI의 CNI(Container Network, Interface)를 구현하고 있다면 다른 애드온들도 사용이 가능하다.

---

Security Context

보안 컨텍스트 개념

• 쿠버네티스의 파드나 컨테이너에 대한 접근 제어 설정 (Access Control Setting)이나 특수 권한 (Privilege)를 설정하는 기능을 제공한다.
• 파드 또는 컨테이너의 권한 부여, 환경 설정 접근을 정의하는 securityContext 필드를 사용한다.
• 파드 또는 컨테이너 내의 securityContext 필드는 컨테이너 프로세스들이 사용하는 사용자(runAsUser)와 그룹(fsGroup), 가용량, 권한 설정, 보안 정책(SELinux/AppArmor/Seccomp)을 설정하기 위해 사용된다.
• 런타임 UID, GID를 포함한다.

보안 컨텍스트 스펙

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000
  volumes:
    - name: sec-ctx-vol
      emptyDir: {}
  containers:
    - name: sec-ctx-demo
      image: gcr.io/google-samples/node-hello:1.0
      volumeMounts:
        - name: sec-ctx-vol
          mountPath: /data/demo
      securityContext:
        allowPrivilegeEscalation: false

---

Pod Security Policy

Pod Security Policy 개념

• SecurityContext는 컨테이너나 파드의 보안 기능을 정의한다.
• Pod Security Policy는 보안 기능에 대한 정책을 정의한다.
• 파드 생성 및 업데이트에 관한 세밀한 권한 인증을 제공한다.
• 파드 스펙에 대한 보안적 측면을 통제하는 클러스터-수준 리소스다.
• PodSecurityPolicy 객체는 관련 필드들에 대한 기본값들을 포함하여 파드가 시스템 내로 받아들여지기 위해 구동될 때의 조건들 집합을 정의한다.
• 파드 보안 정책 통제는 선택적인 입장 승인 컨트롤러로서 구현된다.

Pod Security Policy 스펙

kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false # Don't allow privileged pods!
  # The rest fills in some required fileds.
  seLinux:
    rule: RunASAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
    - '*'

Pod Security Policy 동작