KR_K8s_RBAC_Security
Kubernetes API 그룹(API Group)은 Kubernetes API 리소스들을 관리하기 위해 그룹화한 것이다. API 그룹을 통해 관련된 리소스를 분류하고, 버전 관리를 효율적으로 수행할 수 있다.
Kubernetes API는 크게 Core Group과 Named Group으로 나뉜다.
- Image Reference : https://cloud.redhat.com/blog/kubernetes-deep-dive-api-server-part-1
Core Group은 기본적인 Kubernetes 리소스를 포함하는 그룹으로, API 그룹 이름이 공백 문자열("")로 지정된다.
이 그룹에는 파드(Pods), 서비스(Services), 레플리케이션컨트롤러(ReplicationControllers), 노드(Nodes), 네임스페이스(Namespaces) 등 Kubernetes의 핵심 기능을 제공하는 리소스가 포함된다.
예를들어 Core Group의 pods 리소스에 대한 권한을 설정할 때 다음과 같이 작성한다.
apiGroups: [""]
resources: ["pods"]Named Group은 Core Group 외의 특정한 이름을 가진 API 그룹이다.
이 그룹에는 애플리케이션 관련 리소스, 보안 관련 리소스, 구성 관련 리소스, 그 외 다양한 확장 리소스 등이 포함될 수 있다. 대표적인 Named Group으로는 extensions, apps, networking.k8s.io, rbac.authorization.k8s.io 등이 있다.
예를 들어, apps API 그룹의 deployments 리소스에 대한 권한을 설정할 때 다음과 같이 작성한다.
apiGroups: ["apps"]
resources: ["deployments"]Kubernetes의 RBAC (Role-Based Access Control)은 Kubernetes 클러스터 내에서 리소스에 대한 접근 권한을 사용자나 그룹에게 부여하는 보안 메커니즘(Authorization)이다. RBAC을 통해 특정 사용자에게 필요한 최소한의 권한만 부여함으로써 클러스터의 리소스와 정보를 안전하게 보호할 수 있다.
Kubernetes에서는 Role, ClusterRole, RoleBinding, ClusterRoleBinding 이렇게 네 가지 요소를 사용하여 RBAC을 구현한다.
Role은 Kubernetes의 특정 네임스페이스(namespace) 내에서 리소스에 대한 접근 권한을 정의하는 객체이다.
Role은 어떤 종류의 리소스에 대한 권한을 설정할지, 그리고 그 권한이 어떤 동작(예: get, list, create, update 등)을 포함하는지 명시한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: gitlab-runner-role
# kubectl apply 할 때 적용할 namespace 지정
#namespace:
rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["pods", "services", "secrets", "pods/exec", "serviceaccounts"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
출처: https://somaz.tistory.com/199 [Somaz의 IT 공부 일지:티스토리]extensions 및 apps API 그룹에 속하는 deployments 리소스에 대한 권한
- get: 리소스 조회
- list: 리소스 목록 조회
- watch: 리소스 변경 사항 감시
- create: 리소스 생성
- update: 리소스 수정
- patch: 리소스 일부 수정
- delete: 리소스 삭제
core API 그룹 (apiGroups 필드에 빈 문자열 ""이 사용)에 속하는 리소스에 대한
- pods, services, secrets, serviceaccounts: 위와 동일한 동작 권한
- pods/exec: 파드 내에서 실행 중인 컨테이너의 명령을 실행할 수 있는 권한
RoleBinding은 Role에 정의된 권한을 사용자, 그룹, 또는 다른 서비스 계정에 연결하는 객체이다.
즉, RoleBinding을 통해 특정 사용자가 Role에 명시된 권한을 가지게 된다. RoleBinding은 특정 네임스페이스에만 국한되어 작동한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
# kubectl apply 할 때 적용할 namespace 지정
#namespace:
name: gitlab-runner-role-binding
subjects:
- kind: ServiceAccount
name: default
# kubectl apply 할 때 적용할 namespace 지정
#namespace:
roleRef:
kind: Role
name: gitlab-runner-role
apiGroup: rbac.authorization.k8s.ioKubernetes 시크릿은 비밀번호, API 키, 토큰 또는 인증서와 같은 민감한 정보를 Kubernetes 클러스터 내에 안전하게 저장하는 데 사용된다. 민감한 데이터를 애플리케이션 코드 및 구성 파일과 분리하는 데 도움이 된다. 시크릿은 클러스터의 파드 및 컨테이너에서 사용할 파일 또는 환경 변수로 마운트할 수 있다.
Kubernetes Secrets으로 저장할 수 있는 리소스는 아래와 같다.
- Opaque Secrets: 임의의 사용자 정의 데이터를 저장하는 일반적인 목적의 시크릿
- Service account token Secrets: 서비스 계정 인증을 위한 토큰을 저장
- Docker config Secrets: 프라이빗 레지스트리 인증 정보를 저장
- Basic authentication Secret: 기본 인증 자격 증명을 저장
- SSH authentication secrets: SSH 인증 키를 저장
- TLS secrets: TLS 인증서와 키를 저장
- Bootstrap token Secrets: 부트스트랩 토큰을 저장
- External Secrets: 외부 시크릿 관리 시스템과 통합하기 위한 시크릿
시크릿 사용 시 주의사항:
- 시크릿은 base64로 인코딩되어 저장되지만, 이는 암호화가 아님
- ETCD에 저장될 때 암호화를 활성화하는 것을 권장
- RBAC를 통해 시크릿 접근 권한을 제한해야 함
- 필요한 경우에만 시크릿을 Pod에 마운트
Kubernetes는 컨테이너 기반의 애플리케이션 및 서비스를 관리하기 위한 오픈 소스 플랫폼이다.
- API 서버 보안: API 서버는 Kubernetes 클러스터의 핵심이며, 적절한 인증, 승인 및 인가를 통해 보호되어야 한다.
- 노드 보안: 노드는 클러스터의 일부이며, 이들에 대한 접근은 엄격하게 통제되어야 한다.
- 네트워크 정책: 파드 간의 통신을 제어하기 위한 네트워크 정책을 구현해야 한다.
- 이미지 보안: 안전하지 않은 컨테이너 이미지는 취약점을 포함할 수 있으므로, 이미지 스캐닝 및 서명을 통해 보안을 유지해야 한다.
- 컨테이너 격리: 각 컨테이너는 격리되어야 하며, 리소스 제한을 통해 다른 컨테이너 및 서비스에 영향을 미치지 않도록 해야 힌다.
- 보안 컨텍스트: 컨테이너의 권한과 능력을 제어하기 위해 보안 컨텍스트를 사용할 수 있다.
접근제어는 K8S(API 접근) 인증/인가로 구분된다.
- X.509 Client Certs: kubeconfig 에 CA crt(발급 기관 인증서) , Client crt(클라이언트 인증서) , Client key(클라이언트 개인키) 를 통해 인증
- kubectl: 여러 클러스터(kubeconfig)를 관리 가능 - contexts 에 클러스터와 유저 및 인증서/키 참고
- Service Account: 기본 서비스 어카운트(default) - 시크릿(CA crt 와 token)
- 인가 방식 : RBAC(Role, RoleBinding), ABAC, Webhook, Node Authorization
-
RBAC : 역할 기반의 권한 관리, 사용자와 역할을 별개로 선언 후 두가지를 조합(binding)해서 사용자에게 권한을 부여하여 kubectl or API로 관리 가능
- Namespace/Cluster - Role/ClusterRole, RoleBinding/ClusterRoleBinding, Service Account
- Role(롤) - (RoleBinding 롤 바인딩) - Service Account(서비스 어카운트) : 롤 바인딩은 롤과 서비스 어카운트를 연결
- Role(네임스페이스내 자원의 권한) vs ClusterRole(클러스터 수준의 자원의 권한)
- 감사 로그: 보안 사고 조사를 위해 중요한 활동을 감사 로그에 기록해야 한다.
- 로깅: 시스템 및 애플리케이션 로그는 보안 사고 대응 및 문제 해결에 필수적인 정보를 제공한다.
이 예에서는 Network Policy 적용하는 방법을 보여준다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: example-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 3306- 해당 정책은 프런트엔드 파드(role: frontend)만 TCP 포트 3306에서 액세스할 수 있도록 데이터베이스 파드(role: db)로 들어오는 트래픽을 제한한다.
이 예에서는 특정 네임스페이스의 Pod에 읽기 전용 액세스 권한을 부여하는 역할을 생성하는 방법을 보여준다.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: "example-user"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io이 예에서는 컨테이너가 루트로 실행되지 않도록 강제하는 파드 보안 정책을 보여준다.
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: non-root-psp
spec:
privileged: false
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
runAsUser:
rule: MustRunAsNonRoot
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- "*"먼저 간단하게 User Account와 Service Account에 대해 설명해보자면, 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를 위한 것이다.
Kubernetes Service Account는 Kubernetes 클러스터 내에서 실행되는 팟(Pod)이 API 서버와 상호 작용할 수 있도록 권한을 부여하는 데 사용되는 자격증명이다. 서비스 어카운트는 특정 네임스페이스(namespace)에 속하며, 자동으로 생성되거나 사용자가 직접 생성할 수 있다. 그리고 네임스페이스 생성시 디폴트 서비스 어카운트가 생성된다.
주의
- Kubernetes 1.24 버전 이전에는 서비스 계정이 최초 생성될 때 자동으로 서비스 계정 토큰이 생성되었습니다.
- Kubernetes 1.24 버전 이후, 보안 강화를 위해 서비스 계정이 생성되어도 서비스 계정 토큰이 생성되지 않습니다.
-
ServiceAccount admission 컨트롤러: ServiceAccount admission 컨트롤러는 default Service account를 지정하지 않은 Pod에 할당하는 역할을 한다.
api-server에 포함된다. -
ServiceAccount Token 컨트롤러: Token 컨트롤러는 클러스터의 각 ServiceAccount에 대한 토큰 생성 및 관리를 담당한다.
controller-manager에 포함된다. -
ServiceAccount 컨트롤러: ServiceAccount 컨트롤러는 ServiceAccount 및 관련 Secret 생성 및 삭제를 관리한다.
controller-manager에 포함된다.
- Token: 토큰은 서비스 계정을 대신하여 Kubernetes API 서버에 대한 요청을 인증하는 데 사용할 수 있는 JWT(JSON 웹 토큰)이다. 이 토큰은 Kubernetes API 서버의 개인 키로 서명되며 해당 공개 키(ca.crt에 있는)를 사용하여 확인할 수 있다. 토큰에는 해당 이름 및 속한 네임스페이스와 같은 서비스 계정에 대한 정보가 포함된다.
- ca.crt: ca.crt 파일에는 Kubernetes 클러스터에 대한 인증 기관(CA) 인증서가 포함되어 있다. 요청을 할 때 클라이언트와 API 서버 간의 신뢰를 설정하는 데 사용된다.클라이언트는 이 CA 인증서를 사용하여 API 서버의 인증서가 유효하고 동일한 CA에서 서명했는지 확인할 수 있다. 이렇게 하면 클라이언트가 악의적인 행위자가 아닌 인증된 API 서버와 통신하고 있는지 확인할 수 있다.
- Namespace: 네임스페이스는 Kubernetes의 다중 테넌트 아키텍처의 핵심 구성 요소이다. 네임스페이스는 클러스터 내의 리소스를 논리적으로 분리하는 데 사용되므로 여러 팀이나 프로젝트가 서로 간섭하지 않고 동일한 클러스터를 공유할 수 있다.
Pod Security Standards는 3가지 정책 레벨을 제공한다:
- Privileged(제한 없음), Baseline(알려진 권한 상승 방지), Restricted(강력한 보안).
Pod Security Admission(PSA)은 네임스페이스 레벨에서 적용되며 3가지 모드가 있다:
- enforce(위반 시 Pod 생성 거부), audit(위반 로그 기록, 생성 허용), warn(사용자에게 경고, 생성 허용).
실무에서는 개발 환경은 warn, 스테이징은 audit, 프로덕션은 enforce를 사용한다.
Baseline으로 시작해 점진적으로 Restricted로 전환하며, pod-security.kubernetes.io/enforce: restricted 레이블을 네임스페이스에 설정한다.
NetworkPolicy의 Egress는 Pod에서 나가는 트래픽을 제어한다.
기본 deny-all 정책 후 필요한 트래픽만 허용하는 화이트리스트 방식을 권장한다.
egress:
- to:
- namespaceSelector:
matchLabels:
name: kube-system
ports:
- protocol: UDP
port: 53- CIDR 기반 제한, Pod/Namespace Selector 조합 사용.
- Calico GlobalNetworkPolicy는 클러스터 전체 정책을 지원하며, Cilium은 L7(HTTP) 레벨 필터링과 FQDN 기반 Egress를 제공한다.
IRSA는 Pod가 AWS 리소스에 접근할 때 IAM Role을 사용하도록 하는 메커니즘이다.
- ① EKS 클러스터에 OIDC Provider 생성 →
- ② IAM Role에 Trust Relationship 설정(OIDC Provider + ServiceAccount 조건) →
- ③ ServiceAccount에
eks.amazonaws.com/role-arnannotation 추가 → - ④ Pod 생성 시 Webhook이 AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE 환경변수 주입 →
- ⑤ AWS SDK가 자동으로 STS AssumeRoleWithWebIdentity 호출.
장점: Node IAM Role보다 세밀한 권한 제어, Pod별 권한 분리, 보안 강화.
eksctl, Terraform으로 자동 구성 가능하며, S3, DynamoDB, RDS 접근에 필수적이다.
컨테이너 이미지 보안 스캔은 CI/CD 파이프라인과 런타임 양쪽에서 수행해야 한다.
- Trivy, Clair, Anchore로 빌드 시 취약점 스캔, 심각도 기준(Critical/High)으로 빌드 실패 처리.
- Admission Webhook(Kyverno, OPA Gatekeeper)으로 배포 전 검증, 서명되지 않은 이미지 차단(Sigstore/Cosign).
- 특정 레지스트리만 허용, latest 태그 금지, 루트 사용자 실행 금지, privileged 컨테이너 차단.
Falco로 런타임 이상 행위 탐지, Aqua Security/Sysdig로 통합 보안 관리.
Kubernetes Secret은 기본적으로 etcd에 평문 저장되므로 암호화가 필수다.
etcd 암호화 (EncryptionConfiguration):
- kube-apiserver 설정으로 etcd 저장 시 암호화, KMS(AWS/GCP) 통합 가능, 키 로테이션 복잡.
Sealed Secrets (Bitnami):
- 공개키로 암호화된 SealedSecret을 Git 저장 가능, 컨트롤러가 복호화 후 Secret 생성, GitOps 친화적, 단일 클러스터 종속.
External Secrets Operator:
- AWS Secrets Manager, Vault, GCP Secret Manager와 동기화, 중앙 집중식 관리, 자동 로테이션, 멀티 클러스터 지원, 외부 의존성.
선택 기준: GitOps 환경은 Sealed Secrets, 멀티 클러스터/엔터프라이즈는 External Secrets Operator, 간단한 환경은 etcd 암호화.