2025 11 27

2025-11-27¶

RBAC (Role-Based Access Control)¶

참고: https://www.cloudflare.com/ko-kr/learning/access-management/role-based-access-control-rbac/ 참고: https://www.ibm.com/kr-ko/think/topics/rbac

개요
- 사용자에게 권한을 주는게 아니고, 역할(Role)에 권한을 주고 -> 사용자를 그 역할에 앉히는 방식
- 사용자 <-> 역할 <-> 권한
  - 사용자 <-> LDAP/ServiceType <-> 권한
  - 사용자 <-> KAKAO/ServiceType <-> 권한

장점
- 관리 효율성: 100명 들어와도 역할만 지정해주면 되기에 관리 쉬움
- 오류 감소: 사용자마다 권한 부여보다 실수 줄임
- 보안 강화: 최소 권한의 원칙 지키기 쉬움

주요 규칙
1. 역할 할당: 사용 권한 행사하려면 사용자에게 하나 이상의 활성 역할 할당
2. 역할 권한 부여: 사용자는 할당된 역할을 맡을 수 있는 권한이 있을 것
3. 권한 승인: 권한은 역할 할당을 통해 권한이 부여된 사용자에게만 부여

Vault VSO vs ESO¶

Vault에 저장된 Secret을 Pod가 안전하게 사용하도록 전달하자!

VSO(Vault Secrets Operator)
- 참고: https://developer.hashicorp.com/vault/docs/deploy/kubernetes/vso
- Vault의 기능을 쿠버네티스 네이티브한 방식으로 사용한다네... (CRD)
- Vault 경로의 어떤 정보를 쿠버 시크릿으로 만들지 CRD YAML에 선언하면 VSO가 Vault와 통신해 Secret 생성 + 동기화
  - 어플리케이션은 Vault에 접근하지 않고, 쿠버 Secret에만 접속하여 민감 정보 사용 가능 -> 보안 강화
- 특징)
  - Vault 특화 고급 기능 지원 (동적 시크릭, PKI, Transit 등...)
  - Secret으로 동기화하는 것 || 파일 형태로 마운트/환경 변수 주입 등 유연한 방식 제공
  - Secret을 디스크에 쓰지 않고 메모리에서만 처리하여 보안에 좋음
  - Vault 원본 시크릿 변경되면, VSO가 감지하여 Kubernetes Secret에 자동 반영
- 작동 방식)
  - VaultAuth, VaultStaticSecret등 전용 CRD를 통한 Vault 통신
- 절차)
  1. Namespace/ServiceAccount 생성
    - Secret을 사용할 어플리케이션이 위치하는 Namespace 만들자. Namespace에서 사용할 ServiceAccount 만들고
  2. VSORole 생성
    - 어떤 Vault에 접근할 수 있는지 정의
  3. VSO CRD 배포
  4. Kubernetes Secret 최종 확인

ESO(External Secrets Operator)
- 커뮤니티 주도 개발 프로젝트, Vault 뿐만 아니라 AWS/Google/Azure 등 다양한 외부 시크릿 저장소와 통합 가능
- 특징)
  - 범용성: Vault 외 여러 클라우드 벤터사의 시크릿 매니저 사용 가능
  - 단순함: 외부 소스의 시크릿 가져와서 쿠버 기본 리소스인 Secret으로 싱크하는 역할에 집중
  - 표준화: 동일한 ExternalSecret 리소스로 처리 가능

Helm¶

패키지 매니저이지만, 실무에서는 템플릿 엔진처럼 씀 : 변수 values.yaml, 뼈대 templates/ 분리하는 작업

Helm으로 만다는 것

쿠버 YAML을 매번 복붙하기 어려움

변하는 부분 (이미지 태그, 포트, 리소스 제한 등) 변수로 빼고, 나머지는 공통 템플릿

my-app-chart/
|-- Chart.yaml          # 메타데이터
|-- values.yaml         # 기본 변수값들이 모임
|-- templates/          # 구멍 뚫린 YAML들
    |-- deployment.yaml
    |-- service.yaml

실무 전략
- 환경별 values.yaml 분리
  - 환경별로 values-dev.yaml / values-prod.yaml 리소스 다르게
- GitOps 결합
  - 개발자가 Git에 values.yaml 수정 (이미지 태그 변경)
  - ArgoCD Git 변경 감지
  - ArgoCD가 helm template 돌려서 쿠버에 Sync
  - ArgoCD 같은 툴 쓰면 helm install 직접 칠일 거의 없음
    - ArgoCD가 helm template 수행해서, 완성된 YAML 뽑은 뒤 apply
- Chart.yaml 버전은 변경될 일이 있나?
  - 데브옵스 엔지니어가 배포 방식을 바꾸는 (ex. 파드에 사이드카 붙이기) 일이 있을때나 Chart.yaml의 버전이 올라감.
  - 배포 템플릿 자체가 바뀔때만 Chart.yaml의 버전이 올라감 (이땐 올려줘)

2025 11 27

2025-11-27¶

RBAC (Role-Based Access Control)¶

Vault VSO vs ESO¶

Helm¶

IIFE, UMD, js 모듈 시스템¶

Reactive Streams¶