[CKA] Security

Security Primitives

호스트에 대한 모든 액세스는 보안되어야 하고, 루트 액세스는 비활성화 되어야하며 암호 기반 인증도 비활성화되어야 하며, 오직 SSH Key를 기반으로 한 인증만 사용할 수 있다.

kube-apiserver는 쿠버네티스 모든 동작의 중심으로, api에 직접 접근하거나 kubectl을 통해 상호작용하게 된다. 첫번째 방어선인 api 서버에 대한 접근을 어떻게 제어할 수 있을까?

누가 클러스터에 접근할 수 있는가? 그리고 무엇을 할 수 있을까? 이 두가지로 결정해야한다.

Who can access the api server

Authentication Mechanisms에 의해 결정된다. 이 인증 방법은 여러개의 방법이 있다.

• Files - Username and Passwords
• Files - Username and Tokens
• Certificates
• External Authentication providers - LDAP
• Service Accounts

What can they do

• RBAC Authorization - Role Based Access Control
• ABAC Authorization - Attribute Based Access Control
• Node Authorization
• Webhook Mode
• ETCD clust, kube controller manager, scheduler, api server 와 같은 다양한 컴포넌트 사이의 모든 통신은 TLS Encryption 에 의해 보호된다.
• 클러스터 내의 applications 간의 통신은 Network Policy에 의해 제한된다.

Authentication

쿠버네티스는 사용자 계정을 관리하지 않고 사용자를 관리하기 위해 외부 소스(파일, 인증서, LDAP)에 의존한다.

• kubectl create serviceaccount sa 1
  • service account를 통해 관리 할 수 있다.

Static Password file

• 유저와 유저의 패스워드의 리스트를 담은 CSV 파일을 생성하고 사용할 수 있다.
  • user-details.csv
• 해당 CSV File에는 user, userID, password 세개의 컬럼이 있다.
• filename option을 통해서 API 서버에 전달할 수 있다.
  • --basic-auth-file=user-details.csv
• kubeatm 툴을 사용한다면 pod definition yaml file의 command에 해당 옵션을 추가해줄 수 있다.

Static Token File

• password file과 마찬가지로 옵션을 통해 전달한다.
  • --token-auth-file=user-details.csv
  • 위의 예시와 파일 이름은 같지만 파일 내용은 password가 아닌 token이 저장되어 있다.

하지만 위의 두 방식은 추천되는 방식은 아니지만 이해하기 가장 쉬운 방식이다.

PKI (Puplic Key Infrastructure) - 참고

TLS Certification에 대해 이해하기 전에 Public key를 통한 인증 인프라가 어떤식으로 구성되는지 먼저 이해를 하자.

은행 계좌를 예로 들어보자.

유저가 은행 사용을 별도의 암호화 없이 플레인 텍스트 형태로 유저의 정보를 서버에 보내게 된다면 해커의 네트워크에 탐지되어 정보를 손쉽게 해커가 사용할 수 있게 된다. 이를 방지하기 위해서 암호화를 하여 서버에 보내게 되는데, 이렇게 하면 해커가 유저에 대한 데이터를 추출하더라도 암호화 되어 아무것도 할 수 없게 된다.

암호화 된 데이터는 서버로 보내지는데, 이 때 key가 없으면 서버에서도 암호화 된 데이터를 복호화 할 수가 없다. 따라서 key의 사본을 함께 서버로 보내주어야 한다.

key의 사본은 동일한 네트워크로 보내지기 때문에 해커가 이를 추출하여 복화하 할 수 있다.

이것이 SYMMETRIC ENCRYPTION 이다.

하지만 위에서 설명한 대로 동일한 키로 암,복호화가 이루어지기 때문에 키를 교환해주어야 한다. 이것이 ASYMMETRIC ENCRYPTION이다.

ASYMMETRIC ENCRYPTION에서는 Private Key와 Public Key의 쌍으로 암호화를 한다.

Public Key는 데이터를 암호화 할 때 사용한다. 이는 공유되어도 되는 Key이다.

Private Key는 Public Key를 복호화 할 때 사용하기 때문에 누구에게도 공유되어서는 안된다. Public Key로 일단 암호화가 되고 나면, 쌍이 되는 Private Key로만 복호화를 진행할 수 있다. 이는 SSH-keygen 을 사용하여 생성할 수 있다.

위의 예시를 다시 암호화 해보면 다음과 같이 된다.

1. server는 ssh key를 생성한다. 이 key는 certificate가 있는 key이다.
   1. 이때, server는 CSR(Certificate Signing Request)를 CA(Certificate Authority)에 보낸다.
   2. CA는 private key를 통해 CSR에 서명하고, 서명된 certificate를 다시 서버에 보낸다. 서버는 서명된 certificate를 통해 웹앱을 확인한다.
      1. 모든 브라우저는 CA의 public key를 내장하고 있기 때문에 CA의 key로 인증한 정보를 알 수 있는 것
2. 유저가 어플리케이션에 접근할 때, server는 먼저 public key로 암호화한 certificate를 보낸다.
3. 사용자의 브라우저가 암호화된 certificate를 읽고, 해당 서버의 public key를 찾고, symmetric key를 서버에서 제공받은 public key를 사용하여 암호화한다. 이렇게 되면 symmetric key는 보안이 적용된 상태가 된다.
4. 해커는 암호화 된 symmetric key와 server에서 제공한 public key에 대한 정보를 빼간다. 해커에게는 public key에 대한 정보밖에 없기 때문에 이를 복호화 할 수 없다.
5. symmetric key는 server의 public key를 통해 암호화되어 server로 보내진다.
6. server는 자신의 private key를 통해 이를 복호화하여 symmetric key를 찾는다.
7. 이후 유저가 symmetric key를 통해 암호화 한 데이터를 server에 보내더라도, 해커는 symmetric key가 암호화 된 public key만을 가지고 있어 복호화를 하지 못하기 때문에 실제 symmetric key를 가지고 있지 않아서 이후 통신하는 데이터를 사용할 수 없게 된다.

TLS Certification (Transport Layer Security)

쿠버네티스 클러스터는 마스터노드와 워커 노드로 구성되어 있다. 물론 이 노드들 간의 모든 통신은 보안이 필요하고 반드시 암호화되어야 한다.

쿠버네티스에는 다음의 사진과 같이 각 리소스간의 안전한 통신을 위해서 key 쌍이 존재한하며, 각 Certification은 CA에 서명된 Certification이어야 한다.

Certification 생성

certification을 생성할 수 있는 많은 도구가 있지만 여기서는 open ssl을 사용하여 생성하는 것을 알아보자.

Root Certificate

• private key 생성
  • openssl genrsa -out ca.key 2048
  • ca.key 생성
• Certificate Signing Request (CSR)
  • openssl req -new -key ca.key -subj “/CN=KUBERNETES-CA” -out ca.csr
  • ca.csr 생성
  • 아직 서명이 되지 않은 상태
• Signing Certificate (인증서 생성)
  • 생성한 private key를 사용하여 CSR에 Signing
  • openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
  • ca.crt 생성
  • CA가 자신의 private key와 root certificate file을 가지게 된다.

Client Certificate

admin 생성 과정과 scheduler, controller-manaer, proxy의 생성 과정은 동일하다.

admin user를 위한 certificate 생성

• private key 생성
  • openssl genrsa -out admin.key 2048
• Certificate Signing Request
  • openssl req -new -key admin.key -subj “/CN=kube-admin” -out admin.csr
  • 사용자 이름을 명시해야한다. (kube-admin)
• Signing Certificate
  • openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -out admin.crt
  • 앞에서 만든 ca.crt와 ca.key를 통해 인증서를 서명한다.

위의 과정은 새로운 user에 대해 새 계정을 만드는 과정과 유사하다. (user_id=certificate, password=key) 그렇다면 다른 user와 admin은 어떻게 구분할까?

• certificate에 group detail을 추가할 수 있다.
• 쿠버네티스의 system masters 그룹이 관리자 권한을 가지고 있다.
• csr 생성시 다음과 같이 그룹을 명시해준다.
  • openssl req -new key admin.key -subj "/CN=kube-admin/O=system:masters" -out admin.csr

certificate 사용

• kube-api 서버에 요청시 생성한 key 쌍을 넣어준다.
  • curl [<https://kube-apiserver:6443/api/v1/pods>](<https://kube-apiserver:6443/api/v1/pods>) --key admin.key --cert admin.crt --cacert ca.crt
• kubeconfig yaml에 명시해준다.
• apiVersion: V1 clusters: - cluster: certificate-authority: ca.crt server: <https://kube-apiserver:6443> name: kubernetes kind: Config users: - name: kubernetes-admin user: client-certificate: admin.crt client-key: admin.key

Serverside Certificate

• certificate 생성 과정은 위의 과정과 동일하다.

ETCD Server Certificate

• ETCD server는 고가용성을 위해 클러스터 내 여러 서버에 배포될 수 있다.
  • 각 멤버들간의 통신을 보호하기 위해 추가적인 peer certificate를 생성해야한다.
  • certificate가 한번 생성되면 ETCD server를 시작할 때, 이를 명시해주어야 한다. (ectd.yaml)

kube-api server Certificate

• kube-api server는 많은 컴포넌트 요청이 들어오고, 많은 operation이 kube-api server를 통해 이루어지는 만큼 alias가 많다.
  • e.g) 정식 명칭은 kube-api server 이지만 Kubernetes라고 불린다.
• alias 지정
  • openssl config file(openssl.cnf)생성
  • alt_names에 대체 DNS 또는 IP를 지정한다.
• 그 후 Certification에 Signing
  • openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -out apiserver.crt

참고) 모든 컴포넌트는 클라이언트를 확인하기 위해 인증서를 확인해야한다. 그런 다으 TLS 인증서 옵션에서 API 서버 인증서를 제공한다.

--client-ca-file=/var/lib/kubernetes/ca.pem \\\\
--tls-cert-file=/var/lib/kubernetes/apiserver.crt \\\\
--tls-private-key-file=/var/lib/kubernetes/apiserver.key \\\\

kubelet certificate

• node마다 kubelet은 존재하기 때문에, 각 node에 certificate가 필요하다.
  • 이름이 node에 따라서 정해진다.
• certificate를 생성하고, kubelet-config 파일에 해당 정보를 알려준다.
  • 이 과정을 각 node에 수행해주어야 한다.
• kubelet은 client로서 kube-api server와 통신하기 위한 client cert도 필요하다.
  • kube-api server가 어떤 node인지 알 수 있도록 이름이 지정된다.
  • node는 system component이므로 system:node:node01과 같이 지정된다.
  • kube-api server가 올바른 permission을 주기 위해 node들을 SYSTEM:NODES 라는 그룹에 추가한다.

View Certificate Details

올바른 정보를 보려면 어디를 봐야하는지 아는것이 중요하다.

• kubeadm이 셋업 되어 있는 환경에서 kube-api server 정의 파일을 다음의 경로에서 찾을 수 있다.
  • /etc/kubernetes/manifests/kube-apiserver.yaml
  • 이 커맨드 사용으로 api server가 가진 모든 인증 정보를 볼 수 있다.
• 특정 certificate 정보 확인
  • openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout
• apiver.crt config 확인
  • openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text

Certificates API

팀에 새로운 인원이 합류하거나 인증서의 유효기간이 만료되었을 경우 새로운 인증서를 발급받아야하는데 이는 admin 권한을 가진 인원을 통해 이루어진다.

1. 발급받고자 하는 본인의 private key를 생성하고 admin에게 CSR을 요청
2. 기존 admin은 받은 CSR을 CA 서버를 통해 certificate 생성
3. 관리자는 받은 certificate를 요청자에게 돌려줌으로서 새로운 접근 권한이 생김

그런데 CA 서버는 쿠버네티스의 구성 중 어디에 있는걸까?

→ CA는 사실상 직접 생성한 key, certificate file pair에 불과하다. 이 file을 보호하기 위해 안전한 서버에 위치하도록 하고, 이를 CA Server라고 칭한다. 현재는 쿠버네티스 마스터 노드에 인증서가 위치한다. 따라서 마스터 노드 또한 CA Server 이며, kubeadm 또한 파일 쌍인 CA를 생성하고, 마스터 노드 자체에 저장한다.

팀이 성장하고 많은 인원이 합류하면 매번 수동으로 인증서를 관리해주어야 하기 때문에 보다 자동화 된 솔루션이 필요하다. 쿠버네티스에는 인증서 API를 사용하여 이를 수행할 수 있는 Certificates API가 내장되어 있다.

이 API를 사용하면 API 호출을 통해서 쿠버네티스에 직접 CSR 요청을 보낼 수 있다. 위의 예시와 동일한 요청을 보낼 경우 certificates API를 호출하면 다음과 같이 자동화가 된다.

• certificate signing request라는 object를 생성
  • admin이 logging on하여 직접 서명하지 않는다.
• Review Request
  • CSR이 생성되면 클러스터 관리자가 모든 인증서 서명 요청(CSR)을 볼 수 있다.
  • kubectl get csr
• approve using kubectl command
  • kubectl certificate approve <user>
• extracted and shared with the user

생성된 인증서는 yaml file에서 확인할 수 있다.

• kubectl get csr <user> -o yaml
  • base 64 encoding 형식의 certificate를 확인할 수 있다.

쿠버네티스에서는 이러한 cert 관련 작업 수행을 어디서 할까?

→ Controller Manager

→ conteroller manager 내부 CSR-APPROVING , CSR-SIGNING 가 이러한 태스크를 담당한다.

KubeConfig

• kubectl command를 사용하여 특정 certification 정보를 옵션으로 지정하여 해당 certification에 대한 정보를 조회할 수 있다.
  • kubectl get pods --server my-kube-plyaground:6443 \\ --client-key admin.key \\ --client-certificate admin.crt \\ --certificate-authority ca.crt
• 상기 옵션은 너무 길다. 이 옵션에 대한 내용을 config 파일로 생성하여 조회할 수 있다.
  • 이후 kubectl get pods --kubeconfig config
• # config # KuBeConfig File --server my-kube-plyaground:6443 --client-key admin.key --client-certificate admin.crt --certificate-authority ca.crt
• default로, kubectl tool은 home directory 하위의 .kube 디렉토리 하위의 config 라는 이름의 파일을 찾는다. 그렇기 config 파일을 /Home/.kube/config 생성하면 kubectl command를 입력할 때 경로를 특정할 필요 없다.
• namespace를 지정하여 구분할 수 있다.
• cluster의 ca는 path(certificate-authority: path)로 지정할수도 있고, 직접 encoding 된 data(certificate-authority-data: encoding data)로 넣어줄 수 있음.
• config command
  • kubectl config view
  • kubectl config view —kubeconfig=my-custom-config
  • kubectl config use-config prod-user@production
    • config file의 current-context 변경

Authorization

Node Authorizer

• system:node (certificate)이름을 가진 user로부터의 요청은 node authorizer로부터 인증되고 권한이 부여된다.

ABAC(Attribute Based Access Control)

• user or user group을 권한 집합과 연결하는 역할을 한다.
• policy file을 생성해서 지정할 수 있다.
  • e.g) Alice can do anything to all resources:
• Json 형태로 다음과 같이 지정한다.
• {apiVersion": "abac.authorization.kubernetes.io/v1beta1, "kind: "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", apiGroup": "*"}}

이렇게 하니 모든 유저마다 위와 같은 과정을 거쳐주어야 하니 불편하다. 이를 조금 더 쉽게 할 수 있는 방법이 RBAC이다.

RBAC(Role Based Access Control)

• user or user group을 권한 집합과 연결하며 ABAC보다 더 쉽게 제어할 수 있다.
• 특정 권한을 생성하고 user를 연결하는 방식이다.
  • Developmer라는 그룹을 생성하고 해당 그룹에 view pods, create pods, delete pods, crate configmaps와 같이 개발에 필요한 권한을 부여한다.
  • 이 권한이 필요한 사용자를 이 그룹에 직접 매핑시켜주면 된다.
    • e.g) user1 → Developer, user2 → Developer

create role definitio file

# developer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""] # core group인 경우 비어놓고, 다른 api는 이름을 지정해주어야함
  resources: ["pods"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["ConfigMap"]
  verbs: ["create"]
# resource name을 지정하여 해당 resource만을 이 role definition에 종속할 수 있음.
# resourceNames: ["blue", "orange"]

kubectl create -f developer-role.yaml

line user to that role

# devuser-developer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
subjects: # 연결할 유저에 대한 상세정보
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k9s.io
roleRef: # 생성한 Role에 대한 상세정보
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

kubectl create -f devuser-developer-binding.yaml

• 이는 default namespace에 저장된다. namespace를 변경하고 싶다면 yaml file에 namespace를 지정해주면 된다.

View RBAC

• kubectl get roles
• kubectl get rolebindings
• kubectl describe role developer
• kubectl describe rolebinding devuser-developer-binding

사용자가 클러스터의 특정 리소스에 대한 액세스 권한이 있는지 확인하고 싶다면?

• kubectl auth can-i create developments
  • result: yes or no
  • --as <user> 옵션으로 해당 유저에 대한 권한 확인 가능
  • --namespace <namespace> 옵션으로 해당 네임스페스에 존재하는 권한 확인 가능
• 관리자인 경우 다른 사용자로 가장하여 권한을 확인할 수 있다.

Webhook

• open policy agent와 같이 admission control과 authorization을 돕는 third-party를 사용한다.
  • 쿠버네티스가 open policy agent에 권한 체크 요청을 하도록 할 수 있다.

AlwaysAllow, AlwaysDeny

• 권한 체크 없이 모두 수용 or 모두 거절
• 이와 같은 Auth mode 옵션은 kube-api server 옵션으로 저장된다.
  • --authorization-mode=AlwaysAllow
  • kubectl describe pod kube-apiserver-controlplane -n kube-system

Cluster Role

cluster role은 namespace가 없는 resource이다. 쿠버네티스 객체는 항상 네임스페이스가 지정되거나 지정되지 않아야하기 때문에 리소스의 이름이 다르다.(Role and ClusterRole)

cluster scoped resources에 대한 role을 제외하고는 role과 동일하다.

cluster role은 전체 네임스페이스에 적용되기 때문에 네임스페이스를 별도로 명시하지 않아도 된다. 그 외에는 role과 유사하다.

# cluster-admin-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-administrator
rules:
- apiGroups: [""]
  resources: ["nodes"]
# 리소스가 아닌 URL 형식으로 룰을 설정하는것도 가능하다.
# nonResourceURLs: ["/healthcheck", "/metrics/*"]
# verbs: ["get", "post"]
# url에 대한 요청을 관리하기 때문에 get, post를 사용할 수 있다.
  verbs: ["list", "get", "create", "delete"]

kubectl create -f cluster-admin-role.yaml

# cluster-admin-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
subjects: # user detail
- kind: User
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
roleRef: # clusterrole detail
  kind: ClusterRole
  name: cluster-administrator
  apiGroup: rbac.authorization.k8s.io

kubectl create -f cluster-admin-role-binding.yaml

cluster role 조회

kubectl get clusterroles

→ 너무 많아서 몇개가 있는지 알 수 없을 때, 갯수를 알고 싶을 때

→ kubectl get clusterroles --no-headers | wc -l or kubectl get clusterroles --no-headers -o json | jq '.items | length’

Service Account

service account 개념은 authentication, authorization과 같은 쿠버네티스의 다른 보안 관련 개념과 연결된다.

application이 kubernetes cluster와 상호작용하기 위해 사용하는 계정이며, service account를 통해 요청이 인증된다.

• kubectl create serviceaccount dashboard-sa
  • serviceaccount가 생성되면, token이 자동으로 생성된다.
  • 이 token은 외부 application이 kubernetes api에 인증하는데 사용되며, secret object로 생성된다.
• kubectl get serviceaccount
• kubectl describe serviceaccount dashboard-sa
  • Tokens field에서 token을 확인할 수 있다. 해당 토큰을 다시 describe하면 실제 token 값까지 확인할 수 있다.
  • kubectl describe secret dashboard-sa-token-kbbdm
• 각 namespace는 default serviceaccount를 가진다. pod가 생성되면 default serviceaccount와 그의 token이 자동으로 pod의 volume mount로 mount된다.
  • kubectl exec -it my-kuberenetes-dashboard cat /var/run/secrets/kubernetes.io/serviceaccount/token
  • pod 내 mount 된 것을 확인할 수 있다.
• pod 생성시 다른 serviceaccount를 사용하고 싶다면 spec.serviceAccountName 필드에 지정하면 된다. 주의할 점으로는 존재하는 pod에 변경은 불가하며, 변경시에는 pod를 삭제 후 재생성 해주어야 한다.
  • deployment의 경우는 존재하더라도 edit 할 수 있으며, 이 경우 자동으로 새로운 rollout deployment를 생성한다.
• spec.automountServiceAccountToken=false로 지정하여 자동 mount되는 것을 방지할 수 있다.

Image Security

image를 받아올 때, credential을 어떻게 넘길까?

• credential을 가진 docker-registry 타입의 secret을 생성한다.
  • kubectl create secret docekr-registry regcred --docker-server= \\ --docker-username= \\ --docker-password= \\ --docker-email=
• pod 생성시 imagePullSecrets 필드에 생성한 secret을 지정한다.
• apiVeresion: v1 kind: Pod metadata: name: sepc: containers: - name: image: imagePullSecrets: - name: regcred

Security Contexts

container 또는 pod 수준에서 보안 설정을 선택할 수 있다.

• pod 수준에서 구성 시 설정이 pod 내의 모든 container에 적용된다.
• pod와 container 수준 모두 설정하면 container 수준의 설정이 적용된다.
• pod 수준에서의 security contexts 설정은 다음과 같다.
• apiVersion: v1 kind: Pod metadata: name: web-pod spec: securityContext: runAsUser: 1000 # User Id containers:
• 위와 같은 설정을 container 수준으로 변경하면 yaml file의 구성도 다음과 같이 달라져야한다.
• apiVersion: v1 kind: Pod metadata: name: web-pod spec: containers: - name: image: securityContext: runAsUser: 1000 # 기능 추가하고 싶으면 capabilities: # container 수준에서만 지원되는 필드 add: ["MAC_ADMIN"]
• kubectl exec ubuntu-sleeper -- whoami : container 실행 user 확인 command

Network Policy

Ingress traffic: web server user로부터 들어오는 traffic

egress traffic: App Server로 보내는 요청

kubernetes의 네트워킹을 위한 전제 조건 중 하나는 어떤 솔루션을 구현하든 간에, 경로와 같은 추가 설정을 구성하지 않고도 포드가 서로 통신할 수 있어야 한다는 것이다. 그렇기 때문에 Kubernetes는 기본적으로 모든 pod에서 다른 pod 또는 service로 트래픽을 허용하는 "All Allow" 규칙으로 구성된다.

network policy를 사용하여 특정 통신만 허용하도록 할 수 있다. 즉, pod 내부로 들어오는 ingress traffic과 외부로 나가는 egress traffic을 제한할 수 있다.

참고) Network Policy는 pod, replicaset, services와 같은 쿠버네티스 네임스페이스의 다른 객체이다.

생성

aviVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector: # 어떤 pod에 적용할지 정의
    matchLabels:
      role: db
  policyTypes: # policy type 지정
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          name: api-pod
    ports: # traffic 허용 port 정의
    - protocol: TCP
      port: 3306

kubectl create -f policy-definition.yaml

Developing Network Policies

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          name: api-pod
    ports:
    - protocol: TCP
      port: 3306

클러스터에 label은 같지만 namespaces는 서로 다른 여러 api pod가 있는 경우는 어떻게 될까? 예를 들어 개발, 테스트 및 제품 환경의 namespaces가 서로 다르고, 이러한 환경 각각에 동일한 label을 가진 api pod가 있다고 가정해보자.

현재의 network policy를 사용하면 label이 일치하는 모든 namespace의 모든 pod가 데이터베이스 pod에 도달할 수 있다.

prod namespace의 api-pod이 db pod에 도달하도록만 허용하고 싶다면 어떻게 해야할까? 다음을 추가해주자.

prodSelector:
 ...
namespaceSelector: # namespace별로 선택할 수 있음
  matchLabels:
    name: prod

또한 IP Block을 사용하면 traffic이 db pod에 도달할 수 있도록 허용할 수 있는 IP 주소 범위를 지정할 수 있다.

여기서 만약에 podSelector와 namespaceSelector 둘 다 앞에 -를 추가하여 구성하면 어떻게 될까?

이제 이것들은 두개의 별개의 규칙이 된다. 따라서 첫번째 규칙과 일치하는 트래픽이 허용된다. 즉, 네임스페이스 및 트래픽 matching에서 label이 api-pod와 일치하는 모든 pod의 트래픽이 허용된다.