지식의 추월차선

[KCSA]14% - Overview of Cloud Native Security

✅ 1. The 4Cs of Cloud Native Security4C = Code → Container → Cluster → Cloud이건 보안 레이어를 안쪽부터 바깥쪽으로 쌓아 올리는 개념이야. 각각이 독립적이면서도 서로 영향을 줘.계층 설명 핵심 개념Code어플리케이션 소스코드 보안- Static Analysis (SAST)- Secrets 관리- 의존성 취약점 분석 (SCA)Container이미지 자체의 보안- 최소한의 Base Image 사용- 멀티스테이지 빌드- 이미지 서명 및 취약점 스캔- 루트 계정 미사용Cluster쿠버네티스 클러스터 보안- RBAC- PodSecurityContext- NetworkPolicy- Admission Controller (OPA, Kyverno 등)Cloud..

✅ Kubernetes 애플리케이션 보안 체크리스트 (개발자용)📌 1. 기본 보안 하드닝 (Base Security Hardening)📐 애플리케이션 설계항목 설명보안 원칙을 고려해 설계최소 권한, 입력 검증, 무신뢰 기본 원칙 등적절한 QoS 클래스 설정requests와 limits 설정 필수memory limit ≥ memory request 설정OOM 이슈 방지민감한 앱은 CPU limit도 설정 🆔 서비스 계정항목 설명default ServiceAccount 사용 금지마이크로서비스 별로 생성automountServiceAccountToken: false필요할 때만 API 접근 허용🔒 2. 보안 컨텍스트 설정🧱 Pod-Level 설정항목 설명runAsNonRoot: true 설정루트 실행 ..

✅ Kubernetes 보안 체크리스트 요약 (한눈에 보기)🔐 인증(Authentication) & 권한(Authorization)항목 설명system:masters 그룹 사용 금지초기 부트스트랩 이후엔 사용 금지 (비상용으로만)컨트롤러 매니저는 서비스 계정으로 실행--use-service-account-credentials 사용인증서 관리루트/중간 인증서 만료는 3년 이내, 루트는 오프라인/제한 관리접근 권한 정기 검토최소 24개월 이내 정기 검토RBAC 모범 사례 준수최소 권한 원칙에 따라 Role/Binding 설정🌐 네트워크 보안항목 설명CNI 플러그인은 NetworkPolicy 지원해야 함Ingress/Egress 모두 제어하는 NetworkPolicy 적용기본은 “deny all” 정책 적..

🧱 기본 개념: SecurityContext란?Kubernetes Pod나 Container에 적용할 수 있는 보안 설정 블록주요 기능:루트 권한 제한 (runAsNonRoot)사용자/그룹 ID 지정 (runAsUser, runAsGroup)Linux Capabilities 조정seccomp, AppArmor, SELinux 적용1️⃣ 루트 권한 없이 실행하기 (runAsNonRoot)보안의 기본! 컨테이너를 root가 아닌 사용자로 실행이미지 자체가 root로 빌드되었어도 Pod 설정이 우선됨securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 3000⚠️ 주의: 설정한 사용자/그룹이 앱 실행에 필요한 권한이 있는지 확인해야 함2️⃣ ..

🔐 Kubernetes API 서버 우회 위험 및 대응 가이드📌 왜 중요한가?Kubernetes API 서버는 클러스터의 중앙 관문이야.보안 로깅, 정책 적용(admission control) 등 많은 보안 기능들이 API 서버를 통해서만 작동함.그런데, 어떤 요소들은 이 API 서버를 우회해서 동작할 수 있어! → 이게 보안 구멍1️⃣ Static Pod 우회문제점kubelet이 직접 파일시스템 또는 URL에서 static pod manifest를 읽어 실행이 방식은 API 서버를 거치지 않음 → admission controller나 audit log가 작동 안 함hostPath 같은 민감한 리소스를 마운트할 수 있음namespace가 유효하지 않으면 API에 표시되지도 않음 → 탐지 어려움대응법..

🔐 Kubernetes 인증 메커니즘 하드닝 가이드→ 안전한 클러스터 운영을 위한 인증 방식 선택법!🧭 인증 구성 시 기본 원칙가능한 적은 수의 인증 방식만 활성화하자→ 인증 방식이 많을수록 관리 복잡 + 보안 취약점 증가Kubernetes는 자체 사용자 DB를 갖고 있지 않음→ 외부 인증 시스템을 통해 사용자 정보를 받아옴여러 인증 소스를 쓰는 경우, 모든 소스에서 사용자 액세스를 감사(Audit) 해야 함🌐 프로덕션에서 추천되는 방식사용자들이 직접 kubectl 등으로 API에 접근하는 경우: → 외부 인증 시스템 사용 (예: OIDC) 추천클러스터 내부 기능(컨트롤러, 서비스 등)에는 내장 인증도 사용 가능🔒 인증 방식별 설명 및 보안 주의사항1️⃣ X.509 클라이언트 인증서시스템 컴포넌트..

🔑 멀티 테넌시(Multi-tenancy)란?한 클러스터를 여러 사용자/조직/고객이 함께 사용하는 것클러스터를 나눠 쓰면 비용이 절약되고 관리도 간편하지만→ 보안, 공정한 자원 분배, 소음 문제(노이즈 네이버) 같은 이슈 발생 가능🎯 두 가지 주요 유형유형 설명Multi-Team하나의 조직 내 여러 팀이 클러스터 공유 → 각 팀은 kubectl, GitOps 등으로 직접 리소스 제어Multi-Customer (SaaS)여러 고객을 위한 앱 인스턴스를 같은 클러스터에서 운영 → 고객은 클러스터에 직접 접근하지 않음🧩 테넌트(Tenant)란?Multi-Team: 보통 "팀"이 테넌트Multi-Customer: 보통 "고객" 단위가 테넌트혼합도 가능: 예) SaaS 회사가 내부 팀도 공유하고, 고객별 워..

🔐 Kubernetes Secrets 보안 모범 사례→ 비밀번호, API 토큰, SSH 키 같은 민감한 정보를 안전하게 관리하는 방법!🎯 핵심 개념 요약Secret이란?→ 비밀번호, OAuth 토큰, SSH 키 같은 민감 정보를 저장하는 Kubernetes 객체ConfigMap이랑 뭐가 달라?→ ConfigMap은 민감하지 않은 설정값, Secret은 민감한 데이터를 위한 것!주의! Secret은 기본적으로 암호화되지 않은 상태로 etcd에 저장돼→ 설정을 바꾸면 암호화 저장 가능함🛠️ 클러스터 관리자용 Best Practices1️⃣ etcd에 저장되는 Secret을 암호화하기기본값은 평문(base64만 인코딩) 저장이야.꼭 EncryptionConfiguration 설정해서 etcd 저장소 내 ..

🔐 Kubernetes RBAC 잘 사용하는 법🧱 기본 원칙: 최소 권한 원칙 (Least Privilege)정말 필요한 권한만 부여하자!사용자나 서비스 계정에 꼭 필요한 권한만 주고, 그 외엔 주지 말자.예를 들어, 전체 클러스터가 아닌 특정 네임스페이스에서만 권한을 주는 게 안전해.그래서 RoleBinding을 쓰는 게 좋고, ClusterRoleBinding은 꼭 필요할 때만!와일드카드 권한(*)은 피하자!*을 쓰면 지금 있는 리소스뿐만 아니라 미래에 생길 리소스에도 권한을 주게 돼. 위험해!cluster-admin 계정은 최소한으로!대신, 낮은 권한 계정 + impersonate 권한 조합을 쓰면 실수로 전체 클러스터 망치는 걸 막을 수 있어.system:masters 그룹은 절대 주지 말자!..

🔐 Kubernetes API 접근 제어란?사용자(또는 애플리케이션)는 kubectl, 클라이언트 라이브러리, REST API를 통해 Kubernetes API에 접근해.이 요청은 다음과 같은 4단계 보안 절차를 거쳐 처리돼:[1] 인증 → [2] 권한 확인 → [3] 어드미션 컨트롤 → [4] 저장📡 0단계: 전송 보안(Transport Security)기본적으로 API 서버는 포트 6443에서 TLS로 보호됨실제 운영 환경에서는 보통 포트 443 사용--secure-port, --bind-address 플래그로 포트와 IP 설정 가능API 서버는 TLS 인증서를 클라이언트에게 제공함사설 인증서(CA) 사용하는 경우, 클라이언트의 ~/.kube/config에 해당 CA의 인증서가 등록되어 있어야 함..