Security - 개요

프로덕션 워크로드를 Kubernetes 위에 올린다는 건, 클러스터 자체가 곧 “플랫폼”이 된다는 뜻입니다. 그래서 보안은 기능/성능만큼이나 핵심입니다.
이 글에서는 강의에서 언급한 쿠버네티스 보안의 기본 축을 “큰 그림”으로 먼저 잡고, 실무에서 바로 확인할 수 있는 설정 포인트/명령어/YAML 예시까지 묶어서 정리합니다.

---

1) 시작은 “호스트(노드) 보안”부터: 인프라가 뚫리면 다 뚫린다

쿠버네티스 보안을 이야기할 때, 가장 먼저 봐야 하는 건 클러스터를 구성하는 호스트(물리/가상 서버) 입니다.
여기가 손상되면 컨트롤 플레인/etcd/워크로드까지 연쇄적으로 위험해집니다.

SSH 기본 하드닝: root 로그인/패스워드 인증 차단 + 키 기반만 허용

대표적으로 아래 2가지는 “기본 중 기본”입니다.

• root 직접 로그인 비활성화
• 패스워드 기반 인증 비활성화
• SSH 키 기반 인증만 허용

예시(/etc/ssh/sshd_config):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
# (선택) 특정 사용자만 허용
AllowUsers ec2-user ubuntu admin

적용:

sudo sshd -t                 # 설정 문법 체크
sudo systemctl restart sshd  # 또는 ssh

추가로 실무에서 자주 같이 묶는 것들:

• OS 보안 패치/커널 업데이트 정책
• 방화벽(보안그룹/iptables/ufw)로 관리 포트 최소화
• 노드에 불필요한 패키지/데몬 제거, 파일 권한 점검
• 관리자 접근에 MFA/접근 통제(예: Bastion, SSO) 적용

---

2) Kubernetes의 “첫 번째 방어선”: kube-apiserver 접근 제어

강의에서 강조한 것처럼, kube-apiserver는 쿠버네티스에서 모든 작업의 중심입니다.
kubectl이든, API 직접 호출이든, 최종적으로는 API 서버를 통해 거의 모든 작업이 수행됩니다.

여기서 결정해야 하는 건 딱 두 가지입니다.

• 누가(Who) 클러스터에 접근할 수 있나? → 인증(Authentication)
• 무엇을(What) 할 수 있나? → 인가(Authorization)

---

3) 인증(Authentication): “API 서버에 들어올 수 있는 사람/주체”를 정한다

인증 방식은 여러 갈래가 있습니다(클러스터 구성/운영 방식에 따라 선택).

(1) 사용자/관리자 인증: 인증서, OIDC(SSO), 외부 인증 연동 등

• 클라이언트 인증서 기반(전통적인 방식)
• OIDC 기반(요즘 가장 흔한 패턴: 사내 SSO/IdP 연동)
• LDAP 같은 외부 인증 시스템은 보통 OIDC 브릿지(예: Dex) 등을 통해 붙이는 경우가 많습니다(쿠버네티스가 LDAP을 “직접” 처리한다기보단, 외부 IdP/OIDC로 받는 구조가 일반적).

OIDC를 API 서버에 붙일 때 자주 보이는 플래그 예시(개념용):

kube-apiserver \
  --oidc-issuer-url=https://idp.example.com \
  --oidc-client-id=kubernetes \
  --oidc-username-claim=email \
  --oidc-groups-claim=groups

포인트: 인증이 되면 “들어올 수만” 있습니다. 무엇을 할지는 다음 단계(인가)가 결정합니다.

(2) 머신/애플리케이션 인증: ServiceAccount

클러스터 내부의 애플리케이션(파드)이 API를 호출해야 할 때는 ServiceAccount가 표준입니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: demo

파드에 적용:

apiVersion: v1
kind: Pod
metadata:
  name: app
  namespace: demo
spec:
  serviceAccountName: app-sa
  containers:
  - name: app
    image: nginx

---

4) 인가(Authorization): “인증된 주체가 무엇을 할 수 있나”를 정한다

강의에서는 인가 메커니즘으로 아래를 언급했습니다.

• RBAC(역할 기반 접근 제어): 가장 일반적/표준
• ABAC(속성 기반): 파일 기반 정책 등(요즘은 RBAC이 주류)
• Node Authorizer: 노드/쿠블릿 권한 관련 기본 모듈
• Webhook Authorizer: 외부 시스템에 인가 결정을 위임

API 서버에서 인가 모드를 어떤 순서로 사용할지 설정합니다(개념용):

kube-apiserver --authorization-mode=Node,RBAC

RBAC 예시 1) 특정 네임스페이스에서 Pod 읽기만 허용

Role + RoleBinding 조합:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: demo
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: demo
subjects:
- kind: User
  name: jane@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RBAC 예시 2) 클러스터 전역 권한은 최소화(ClusterRole/ClusterRoleBinding 신중)

전역 권한은 영향 범위가 커서 정말 필요한 것만 부여하는 게 원칙입니다.

kubectl auth can-i create pods -n demo --as=jane@example.com
kubectl auth can-i '*' '*' --as=jane@example.com   # 과도 권한 여부 점검용

---

5) 컴포넌트 간 통신 보안: “클러스터 내부 트래픽은 TLS로 잠근다”

강의에서 핵심으로 짚은 부분입니다.

컨트롤 플레인의 주요 컴포넌트(etcd, controller-manager, scheduler, apiserver)와
워커 노드의 컴포넌트(kubelet, kube-proxy) 사이 통신은 TLS 암호화 + 인증서 기반 신뢰로 보호됩니다.

실무에서 자주 확인하는 것들

• API 서버 ↔ etcd: etcd 클라이언트 인증서/CA
• etcd peer 간 통신: peer 인증서/CA
• API 서버 ↔ kubelet: kubelet 서버 인증서/클라이언트 인증 설정
• 인증서 만료/로테이션 전략

kubeadm 환경에서 인증서 점검/갱신(대표 명령)

sudo kubeadm certs check-expiration
sudo kubeadm certs renew all

운영 환경에서는 “언제 만료되는지”를 모니터링하고, 갱신/재시작 절차를 런북으로 만들어두는 게 중요합니다.

etcd 접근 예시: TLS 옵션이 “기본”

etcd를 운영 환경에서 다룰 때는 보통 아래처럼 CA/Cert/Key를 함께 씁니다.

export ETCDCTL_API=3
etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  endpoint health

---

6) 파드 간 통신 보안: “기본은 All-Open, NetworkPolicy로 막는다”

쿠버네티스의 네트워킹 기본 성질은 다음 한 줄로 정리됩니다.

• 기본적으로 모든 파드는 클러스터 내 다른 모든 파드에 접근 가능

그래서 실제 보안 설계는 보통 이렇게 갑니다.

1. 네임스페이스 단위로 Default Deny(최소 권한 네트워크)
2. 필요한 트래픽만 Allow 규칙으로 열기

예시 1) 네임스페이스에서 Ingress 전체 차단(Default Deny)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: demo
spec:
  podSelector: {}
  policyTypes:
  - Ingress

예시 2) frontend → backend:8080만 허용

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

주의: NetworkPolicy는 CNI가 이를 지원해야 동작합니다(클러스터 네트워크 플러그인에 따라 지원 범위가 달라짐).

---

7) 운영 관점 핵심 체크리스트(요약)

호스트/인프라

• root 로그인 금지, 패스워드 SSH 금지, 키 기반 인증
• 방화벽/보안그룹 최소 개방, OS 패치/취약점 관리

API 서버

• 인증(사용자/서비스어카운트) 체계 확립(OIDC/Cert 등)
• 인가(RBAC 중심)로 최소 권한 설계
• kubectl auth can-i로 권한 검증 습관화

컴포넌트 통신

• TLS 인증서 체계/만료 모니터링/갱신 런북
• etcd 접근 시 CA/Cert/Key 기본 적용

클러스터 네트워크

• Default Deny + 필요한 트래픽만 Allow(NetworkPolicy)