쿠버네티스 보안

계정 인증

인증 (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 동작

저작자표시 비영리 변경금지