주요 내용
- 노드의 default Linux namespace 사용하기
- 컨테이너/Pod 단위로 권한 및 네트워크를 제어하여 보안 수준 높이기
컨테이너는 독립적인 환경을 제공한다고 하긴 했지만, 공격자가 API server 에 접근하게 되면 컨테이너에 무엇이든 집어넣고 악의적인 코드를 실행할 수 있고, 이는 실행 중인 다른 컨테이너에 영향을 줄 수도 있다!
13.1 Using the host node's namespaces in a pod
컨테이너는 별도의 linux namespace 에서 실행된다고 했었다.
13.1.1 Using the node's network namespace in a pod
시스템과 관련된 작업 (노드 레벨의 자원을 확인/수정하는 등) 을 하는 pod 의 경우 노드의 default namespace 에서 실행되어야 한다.
예를 들어, 별도의 네트워크 namespace 를 갖지 않고 (가상 네트워크 어댑터를 사용하지 않고), 호스트의 네트워크 어댑터를 사용하고 싶다면 hostNetwork
의 값을 true
로 해서 pod 를 실행하면 된다.
그러면 pod 는 노드의 네트워크 인터페이스에 접근할 수 있게 되고, pod 에는 별도의 IP 주소가 부여되지 않게 된다. Pod 내부에서 특정 포트에 bind 된 프로세스가 있다면, pod 의 포트가 곧 노드의 포트이므로 노트의 포트에 bind 되게 된다.
참고로 Kubernetes Control Plane 에 있는 컴포넌트들은 hostNetwork
옵션을 사용하여 pod 를 실행한다.
13.1.2 Binding to a host port without using the host's network namespace
위 경우에서는 노드의 네트워크 어댑터에 붙었지만, hostPort
값을 설정하면 노드의 특정 포트에 bind 하면서도 자신만의 네트워크 namespace 를 가질 수 있게 된다.
이렇게 했을 때 NodePort service 와의 차이점은, hostPort 의 경우 노드로 들어오는 요청을 직접 포워딩 해주는 반면, NodePort service 는 요청을 받아서 endpoint 중 임의의 (같은 노드가 아닐 수 있음) pod 로 포워딩 해준다는 점이다. 또 hostPort 의 경우 해당 노드에서만 포워딩이 일어나지만, NodePort service 의 경우 모든 노드에서 포워딩이 일어난다.
여러 프로세스가 하나의 포트에 bind 될 수 없기 때문에, Scheduler 도 이를 반영하여 scheduling 을 해준다. 만약 모든 노드의 포트가 사용 중이어서 bind 가 불가능하면 한 pod 는 pending 상태로 남아있게 된다.
apiVersion: v1
kind: Pod
metadata:
name: kubia-hostport
spec:
containers:
- image: luksa/kubia
name: kubia
ports:
- containerPort: 8080 # 컨테이너의 8080 포트를
hostPort: 9000 # 노드의 9000번 포트와 bind
protocol: TCP
이 기능은 주로 시스템과 관련된 pod 를 expose 할 때 사용한다. (DaemonSet)
13.1.3 Using the node's PID and IPC namespaces
호스트의 네트워크 namespace 를 사용할 수 있었던 것처럼 hostPID
, hostIPC
값을 true
로 설정해 주면 노드의 PID 와 IPC namespace 를 사용하게 된다. spec
아래에 넣어주면 된다.
13.2 Configuring the container's security context
securityContext
property 를 이용하면 보안과 관련된 기능들을 pod 과 내부 컨테이너에 설정할 수 있다.
Security Context
Security context 를 설정하면 다양한 것들이 가능하다.
- 컨테이너 안의 프로세스가 어떤 user 로 실행할지 명시하기
- 컨테이너가 root 로 실행되는 것을 막기
- 컨테이너가 privileged mode 로 실행되도록 하기 (노드의 커널에 접근 가능)
- 권한을 상세하게 조정하기
- 프로세스가 컨테이너의 파일시스템에 write 하는 것을 막기
Running a pod without specifying a security context
Security context 를 기본값으로 하고 pod 를 실행해본다.
$ kubectl run pod-with-defaults --image alpine --restart Never -- /bin/sleep 999999
이제 컨테이너가 실행 중인 user 와 group 을 살펴보면,
$ kubectl exec pod-with-defaults -- id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
모두 root 로 실행 중인 것을 확인할 수 있다.
13.2.1 Running a container as a specific user
다른 user 로 pod 를 실행하려면, securityContext.runAsUser
property 값을 설정하면 된다.
apiVersion: v1
kind: Pod
metadata:
name: pod-as-user-guest
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
runAsUser: 405 # guest
Pod 를 생성한 뒤 id
명령을 실행해 보면 guest
user 로 실행된 것을 확인할 수 있다.
$ kubectl exec pod-as-user-guest -- id
uid=405(guest) gid=100(users)
13.2.2 Preventing a container from running as root
root 가 아닌 임의의 사용자로 실행되더라도 무관하다면, root 로 실행하지 못하게 막을 수 있다.
Scheduler 가 새롭게 pod 를 띄울 때는 registry 에서 image 를 pull 받을 것이다. 만약 공격자가 image registry 에 접근 권한을 얻어서 같은 tag 를 가졌지만 root 로 실행하는 image 를 push 하게 되면 악의적인 목적을 가진 컨테이너가 그대로 실행될 위험이 있다.
컨테이너는 물론 호스트의 시스템과 분리되어 있지만, 프로세스를 root 권한으로 실행하는 것은 권장되지 않는다. 대표적으로 폴더를 mount 하는 경우, root 로 실행하게 되면 모든 권한을 다 갖게 된다.
root 로 실행을 막기 위해서는 securityContext.runAsNonRoot
를 true
로 설정하면 된다.
13.2.3 Running pods in privileged mode
어떤 경우에는 pod 가 모든 권한을 부여받아야 할 때도 있다. 예를 들어 kube-proxy pod 의 경우 노드의 iptables
를 변경해야 service 를 동작시킬 수 있게 된다.
이 경우 securityContext.privileged
의 값을 true
로 설정하면 된다. 그러면 노드의 커널에 모든 접근 권한을 갖게 된다.
13.2.4 Adding individual kernel capabilities to a container
당연히, 모든 권한을 주는 것 보다는 필요한 권한만 주는 것이 훨씬 안전할 것이다. Linux 에서는 kernel capability 로 권한을 관리한다.
예를 들어, 컨테이너에서는 보통 시간을 설정할 수 없다.
$ kubectl exec -it pod-with-defaults -- date +%T -s "12:00:00"
date: can't set date: Operation not permitted
만약 이 권한을 주고 싶다면 SYS_TIME
을 설정해 주면 된다. securityContext.capabilities.add
아래에 추가해준다.
apiVersion: v1
kind: Pod
metadata:
name: pod-add-settime-capability
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
capabilities:
add: # 권한을 추가한다
- SYS_TIME
시간이 변경 가능한지 확인하고 싶었으나, minikube 내부에서 NTP daemon 이 시간을 원래대로 돌려줬다. 컨테이너 내의
sh
에서 직접date +%T -s "12:00:00"; date
를 하고 나니 변경된 것을 확인할 수 있었다.
13.2.5 Dropping capabilities from a container
만약 특정 권한을 빼앗고 싶다면 securityContext.capabilities.drop
아래에 추가해주면 된다.
13.2.6 Preventing processes from writing to the container's filesystem
보안상 프로세스가 컨테이너의 파일시스템보다는 mounted volume 에 write 하도록 하는 것이 좋다. 파일시스템을 read only 로 설정하려면 securityContext.readOnlyRootFilesystem
을 true
로 설정하면 된다.
apiVersion: v1
kind: Pod
metadata:
name: pod-with-readonly-filesystem
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
readOnlyRootFilesystem: true # write 는 불가능
volumeMounts:
- name: my-volume
mountPath: /volume
readOnly: false # volume 에는 write 가능
volumes:
- name: my-volume
emptyDir:
Pod 를 생성해보면, root 로 실행되었음에도 /
디렉터리에 write 가 안된다.
Setting options at the pod level
지금까지는 각 컨테이너마다 security context 를 지정했지만, pod 레벨에서도 pod.spec.securityContext
property 를 이용해 설정할 수 있다. 모든 컨테이너가 적용 대상이 되고, 컨테이너 레벨에서 또 설정하게 되면 overriding 할 수 있다.
또한 pod 레벨에서는 추가로 사용할 수 있는 보안 기능이 있다.
13.2.7 Sharing volumes when containers run as different users
한 pod 내에서 volume 을 사용하게 되면 컨테이너 간에 데이터를 공유할 수 있다고 했다. 이게 가능했던 이유는 컨테이너가 모두 root 로 실행되어 읽기/쓰기 권한을 모두 갖고 있었기 때문이다. 한편 runAsUser
옵션을 사용하게 되면 volume 을 사용했을 때 둘 다 읽기/쓰기 권한이 없을 수도 있다.
Kubernetes 에서는 supplemental groups 를 제공하여 데이터 공유를 가능하게 해준다. fsGroup
, supplementalGroups
옵션을 사용하면 된다.
apiVersion: v1
kind: Pod
metadata:
name: pod-with-shared-volume-fsgroup
spec:
securityContext: # 이 두 옵션은 pod 레벨에서 정의된다
fsGroup: 555
supplementalGroups: [666, 777]
containers:
- name: first
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
runAsUser: 1111 # 첫 번째 컨테이너는 user ID 1111
volumeMounts:
- name: shared-volume
mountPath: /volume
readOnly: false
- name: second
image: alpine
command: ["/bin/sleep", "999999"]
securityContext:
runAsUser: 2222 # 두 번째 컨테이너는 user ID 2222
volumeMounts:
- name: shared-volume
mountPath: /volume
readOnly: false
volumes:
- name: shared-volume
emptyDir:
Pod 를 생성하고 id
명령을 실행해본다.
/ $ id
uid=1111 gid=0(root) groups=555,666,777
user ID 는 1111
이고, group ID 는 0
(root) 이지만 555,666,777
도 이 사용자와 엮여있는 것을 확인할 수 있다. fsGroup
을 555
로 설정했으므로, mount 된 volume 을 소유하고 있는 group ID 는 555
이다.
/ $ ls -l / | grep volume
drwxrwsrwx 2 root 555 4096 Jun 13 14:59 volume
Volume 안에 들어가서 파일을 생성하면 파일을 소유하고 있는 user ID 는 1111
이고 group ID 는 555
가 된다.
/ $ echo foo > /volume/foo
/ $ ls -l /volume
total 4
-rw-r--r-- 1 1111 555 4 Jun 13 15:03 foo
보통 사용자가 파일을 만들게 되면 effective group ID 로 설정되는데, fsGroup
옵션을 이용하게 되면 volume 안에 파일을 만들 때 설정할 group ID 를 지정할 수 있다.
supplementalGroups
에 대한 설명이 좀 부족하다. 단순히 user 와 엮인 추가 group ID 를 설정할 수 있다고만 적혀있다.
13.3 Restricting the use of security-related features in pods
클러스터 관리자는 PodSecurityPolicy 리소스를 이용해서 pod 의 보안과 관련된 기능들을 제한할 수 있다.
13.3.1 Introducing the PodSecurityPolicy resource
PodSecurityPolicy 리소스는 클러스터 레벨의 리소스로, 사용자들이 pod 를 생성할 때 사용할 수 있는 보안 관련 기능을 정의하기 위해 사용한다. PodSecurityPolicy 안의 규칙(policy)은 API server 에서 실행 중인 PodSecurityPolicy admission control plugin 에서 관리된다.
사용자가 pod 생성을 요청하게 되면, PodSecurityPolicy admission control plugin 이 pod 의 정의를 보고 validation 을 해준다. 만약 pod 의 정의가 PodSecurityPolicy 에 부합하면, etcd 에 저장되고, 그렇지 않으면 생성 요청이 거절된다. 추가로, 해당 플러그인이 직접 pod 리소스 정보를 변경할 수도 있다. (기본값 세팅 등)
Understanding what a PodSecurityPolicy can do
다음과 같은 작업을 제어할 수 있다.
- Pod 의 호스트 IPC/PID/네트워크 namespace 를 사용 제어
- Pod 가 bind 할 수 있는 호스트의 포트 제한
- 컨테이너를 실행할 user ID 제한
- Privileged 컨테이너 실행 가능 여부
- 커널 관련 작업 제어
- 컨테이너의 root 파일시스템 쓰기 제어
- 컨테이너를 실행할 파일시스템 group 제한
- Pod 가 사용할 수 있는 volume 종류 제한
앞에서 소개한 내용과 거의 비슷하다.
Examining a sample PodSecurityPolicy
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: default
spec:
hostIPC: false
hostPID: false
hostNetwork: false # 호스트의 IPC, PID, 네트워크 namespace 사용 불가
hostPorts:
- min: 10000
max: 11000 # bind 가능한 포트는 10000~11000
- min: 13000
max: 14000 # 13000~14000 포트도 허용
privileged: false # privileged 컨테이너 실행 불가능
readOnlyRootFilesystem: true # root 파일시스템은 읽기 전용
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
seLinux:
rule: RunAsAny # 실행할 user 와 group 은 제한 없음
volumes:
- '*' # 모든 종류의 volume 사용 가능
13.3.2 Understanding runAsUser
, fsGroup
and supplementalGroups
policies
앞 예제에서는 RunAsAny
를 사용했기 때문에 제약 조건이 없었지만, 제한하고 싶다면 MustRunAs
를 이용해서 ID 의 범위를 제한할 수 있다.
runAsUser:
rule: MustRunAs
ranges:
- min: 2
max: 2
참고로 PodSecurityPolicy 리소스를 업데이트 하더라도 기존에 생성된 pod 에는 영향을 주지 않는다. Pod 를 생성하거나 수정할 때만 플러그인이 확인한다.
또한 root user 로의 실행을 막고 싶을 때는 MustRunAsNonRoot
를 사용하면 된다.
13.3.3 Configuring allowed, default, and disallowed capabilities
Linux 커널과 관련된 권한을 통제하고 싶을 때 capabilities 를 조작하면 됐었다. PodSecurityPolicy 에서는 allowedCapabilities
, defaultAddCapabilities
, requiredDropCapabilities
를 이용해 권한을 통제한다.
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: default
spec:
allowedCapabilities:
- SYS_TIME
defaultAddCapabilities:
- CHOWN
requiredDropCapabilities:
- SYS_ADMIN
- SYS_MODULE
allowedCapabilities
를 사용하면 pod 의 securityContext.capabilities
에 어떤 값들이 포함될 수 있는지 제한할 수 있게 된다.
defaultAddCapabilities
를 사용하면 pod 에 해당 capability 가 자동으로 추가된다.
requiredDropCapabilities
를 사용하면 pod 가 어떤 capability 를 가지지 않아야 하는지 제한할 수 있다. (해당 capability 를 drop 하는 것을 require 하는 것이다)
13.3.4 Constraining the types of volumes pods can use
최소한 emptyDir
, configMap
, secret
, downwardAPI
, persistentVolumeClaim
은 사용할 수 있게 해줘야 한다.
PodSecurityPolicy 가 여러 개 있으면, 각각에서 허용한 volume 종류의 합집합이 사용 가능한 volume 종류가 된다.
13.3.5 Assigning different PodSecurityPolicies to different users and groups
PodSecurityPolicy 를 만들었는데 해당 policy 가 전역에 영향을 준다면 이를 사용하기 어려울 것이다. 그러므로 RBAC 를 이용해 사용자마다 어떤 policy 가 할당되어 적용되는지 관리할 수 있다.
방법은 간단하다. PodSecurityPolicy 를 필요한 만큼 만들어 두고, ClusterRole 을 만들어 PodSecurityPolicy 를 reference 하도록 하는 것이다. 이제 ClusterRoleBinding 을 이용해 사용자나 group 에게 ClusterRole 을 bind 하면 적용된다.
$ kubectl create clusterrole <CLUSTER_ROLE_NAME> --verb=use \
--resource=podsecuritypolicies --resource-name=<POD_SECURITY_POLICY_NAME>
$ kubectl create clusterrolebinding <CLUSTER_ROLE_BINDING_NAME> \
--clusterrole=<CLUSTER_ROLE_NAME> --group=<GROUP_NAME>
kubectl
에서 사용자를 추가하려면kubectl config set-credentials <NAME> --username=<USERNAME> --password=<PASSWORD>
를 입력하면 된다.
다른 사용자의 이름으로 리소스를 생성하려면
kubectl --user <USERNAME> create
를 하면 된다.
13.4 Isolating the pod network
앞서 살펴본 방법들은 pod 와 컨테이너 단에서 적용되는 보안 관련 설정을 살펴봤다. 이번에는 pod 사이의 네트워크 통신 측면에서 보안을 적용하는 방법을 알아본다.
네트워크 보안을 설정하기 위해서는 클러스터에서 사용하는 networking plugin 이 이를 지원해야한다. 만약 지원한다면, NetworkPolicy 리소스를 생성하여 네트워크를 분리시킬 수 있다.
NetworkPolicy 리소스를 사용하게 되면 ingress 와 egress 규칙을 설정할 수 있어 어떤 source 에서만 트래픽을 받을지, 어떤 destination 으로만 트래픽을 보낼지 제한할 수 있다.
13.4.1 Enabling network isolation in a namespace
원래 한 namespace 안의 pod 로는 아무나 접근할 수 있으므로, 이것부터 변경해야 한다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: # 모든 pod 가 match 된다
이제 NetworkPolicy 를 특정 namespace 에 생성하면 그 누구도 pod 에 접근할 수 없게 된다.
13.4.2 Allowing only some pods in the namespace to connect to a server pod
클라이언트의 연결을 허용하려면 어떤 pod 가 연결할 수 있는지 명시적으로(explicitly) 적어야 한다.
예를 들어 DB 를 갖고있는 pod 가 실행 중인데, 이를 사용하는 웹 서버 이외의 접근은 막으려고 한다. 이런 경우 NetworkPolicy 에서 ingress 규칙을 설정하면 된다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: postgres-netpolicy
spec:
podSelector: # app=database label 이 있는 pod 에 적용되는 규칙
matchLabels:
app: database
ingress:
- from:
- podSelector:
matchLabels: # app=webserver label 이 있는 pod 로부터 들어오는 트래픽을 허용
app: webserver
ports:
- port: 5432 # 개방된 포트
이렇게 설정하면 app=webserver
label 을 가진 pod 이외에는 DB pod 에 접속이 불가능하며, 심지어 웹 서버 조차도 5432 포트 외의 포트에는 접속할 수 없게 된다.
실제로는 pod 에 직접 접속하지 않고 service 를 거칠 것이다. 이 경우에도 NetworkPolicy 의 적용을 받게 된다.
13.4.3 Isolating the network between Kubernetes namespaces
만약 다양한 namespace 로부터 트래픽을 받고 싶다면 namespace 에 label 을 붙여서 사용할 수도 있다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: shoppingcart-netpolicy
spec:
podSelector:
matchLabels:
app: shopping-cart
ingress:
- from:
- namespaceSelector: # tenant=manning 을 가진 namespace 에서 오는 트래픽을 허용
matchLabels:
tenant: manning
ports:
- port: 80
13.4.4 Isolating using CIDR notation
Label selector 를 사용하는 대신 CIDR block 으로 제어할 수도 있다.
ingress:
- from:
- ipBlock:
cidr: 192.168.1.0/24 # 해당 block 의 트래픽만 허용
13.4.5 Limiting the outbound traffic of a set of pods
앞에서는 들어오는 트래픽 (inbound/ingress) 에 대한 제한이었지만, 나가는 트래픽 (outbound/egress) 도 제어할 수 있다.
spec:
podSelector:
matchLabels:
app: webserver
egress:
- to:
- podSelector:
matchLabels:
app: database
ports:
- port: 5432
위와 같이 하면 app=webserver
label 을 가진 pod 는 app=database
의 5432 포트로만 요청을 보낼 수 있게 된다.
Discussion & Additional Topics
'Computer Science > Kubernetes' 카테고리의 다른 글
Chapter 16. Advanced scheduling (0) | 2021.08.15 |
---|---|
Chapter 15. Automatic scaling of pods and cluster nodes (0) | 2021.07.18 |
Chapter 14. Managing pods' computational resources (0) | 2021.07.11 |
Chapter 12. Securing the Kubernetes API server (0) | 2021.06.06 |
Chapter 11. Understanding Kubernetes internals (0) | 2021.05.30 |
Chapter 10. StatefulSets: deploying replicated stateful applications (0) | 2021.05.17 |
댓글