📘 [MinIO & Cilium 기반 오브젝트 스토리지 연동 시리즈 #6] Cilium + ServiceAccount 조합 제어 실습

✅ 목표: Cilium의 네트워크 정책에서 ServiceAccount 정보를 활용하여
특정 서비스 계정에만 MinIO 접근을 허용하는 제어 방식을 실습합니다.
파드의 라벨만이 아니라 역할(Role) 기반 접근 통제가 가능함을 확인합니다.

---

🔎 이번 글에서 수행할 작업 요약

1. 테스트용 ServiceAccount 및 파드 생성
2. Cilium 정책에서 ServiceAccount 기반 접근 허용 구성
3. 접근이 허용되는 파드와 차단되는 파드를 비교 테스트
4. 흐름 추적 및 정책 검증

---

🧱 1단계: ServiceAccount 기반 파드 구성

이 단계의 목적: 특정 ServiceAccount를 사용하는 테스트 파드를 만들고,
이후 네트워크 정책에서 해당 계정을 기준으로 접근을 허용하도록 설정합니다.

# etl-client-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: etl-client                     # 🔹 접근 허용 대상인 ServiceAccount 이름
  namespace: etl                      # 🔹 etl 네임스페이스에 생성됨
---
apiVersion: v1
kind: Pod
metadata:
  name: sa-test-client                # 🔹 테스트용 파드 이름
  namespace: etl
  labels:
    app: client                       # 🔹 접근 정책에서 사용할 레이블
spec:
  serviceAccountName: etl-client      # ✅ 위에서 생성한 SA를 명시적으로 연결
  containers:
  - name: curl
    image: curlimages/curl:latest     # 🔹 네트워크 요청 테스트용 경량 이미지
    command: ["sleep", "3600"]        # 🔹 파드를 대기 상태로 유지

# 위 YAML 파일 적용
kubectl apply -f etl-client-sa.yaml

---

🛡️ 2단계: ServiceAccount 기반 Cilium 정책 작성

이 단계의 목적: ServiceAccount가 etl-client인 파드만
MinIO(9000 포트)에 접근할 수 있도록 정책을 정의합니다.

# cilium-sa-policy.yaml
apiVersion: "cilium.io/v2"                         # 🔹 Cilium 정책을 위한 API 버전
kind: CiliumNetworkPolicy                          # 🔹 리소스 종류
metadata:
  name: allow-minio-from-etl-sa                    # 🔹 정책 이름
  namespace: minio                                 # 🔹 MinIO가 있는 네임스페이스에 적용
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/name: minio                # ✅ MinIO 파드를 대상으로 ingress 제어
  ingress:
  - fromEndpoints:
    - matchLabels:
        k8s:serviceaccount.name: etl-client        # ✅ 접근 허용할 ServiceAccount 이름
        io.kubernetes.pod.namespace: etl           # 🔹 해당 SA가 소속된 네임스페이스 지정
    toPorts:
    - ports:
      - port: "9000"                               # 🔹 MinIO 포트
        protocol: TCP                              # 🔹 TCP 프로토콜

# 정책 적용
kubectl apply -f cilium-sa-policy.yaml

---

🧪 3단계: 접근 허용/차단 비교 테스트

이 단계의 목적: 같은 네임스페이스에 속해 있더라도
ServiceAccount의 차이에 따라 접근이 제한되는지를 직접 확인합니다.

# ✅ etl-client SA를 사용하는 파드에서 MinIO 접근 테스트
kubectl exec -it sa-test-client -n etl -- \
  curl -I http://minio.minio.svc.cluster.local:9000
# -I 옵션: HTTP 헤더만 요청 → 정책 허용 여부만 확인 가능

# ❌ 기본 ServiceAccount 사용하는 파드에서 MinIO 접근 시도 (차단 예상)
kubectl run default-client --rm -it --restart=Never \
  --image=curlimages/curl:latest -n etl -- sh

# 파드 내부에서 명령 실행
curl -I http://minio.minio.svc.cluster.local:9000

☑️ default-client 파드는 SA 조건을 만족하지 않으므로 요청이 차단됨 (Connection refused 또는 timeout 발생)

---

🔍 4단계: 흐름 추적 및 정책 효과 확인

이 단계의 목적: Cilium 모니터링 도구(Hubble, CLI)를 활용해
네트워크 요청 흐름이 정책에 의해 DROP 또는 FORWARD 되는지를 추적합니다.

# Hubble CLI를 통해 정책 적용 여부 확인
hubble observe --namespace minio --protocol http --verdict DROP
# DROP된 요청 확인 → 정책 차단 효과 검증

# 또는 Cilium 모니터를 통한 로우레벨 흐름 확인
cilium monitor -n minio | grep DROP

✅ default-client에서 보낸 요청이 DROP되고, sa-test-client는 통과(FORWARDED)되면 정책이 정상 작동함을 의미합니다.

---

📎 요약 및 핵심 정리

• ServiceAccount를 기반으로 역할 중심의 네트워크 접근 제어가 가능함을 확인함
• Cilium의 정책에서 k8s:serviceaccount.name을 사용하여 세밀한 조건을 부여할 수 있었음
• 같은 네임스페이스 내에서도 서비스 계정에 따라 접근 권한이 달라지는 구조를 실제로 테스트함
• 보안성과 유지보수 측면에서 라벨 기반 정책보다 정밀한 제어가 가능함을 확인함