06-[AEWS]-EKS Security

Kubernetes Auth

출처 : sysdig BY KAIZHE HUANG

Admission Control은 클러스터에서 실행할 수 있는 항목을 정의하고 사용자 지정하는 데 도움이 되는 강력한 Kubernetes 기반 기능입니다. 감시자로서 클러스터에 들어가는 내용을 제어할 수 있습니다. 너무 많은 리소스를 요청하는 배포를 관리하고, 포드 보안 정책을 시행하며, 취약한 이미지가 배포되는 것을 차단할 수도 있습니다.

Authentication (인증)

쿠버네티스는 계정 체계를 관리함에 있어서 사람이 사용하는 사용자 어카운트와, 시스템이 사용하는 서비스 어카운트 두가지 개념을 제공한다.

사용자 어카운트

사용자 어카운트는 우리가 일반적으로 생각하는 사용자 아이디의 개념이다.쿠버네티스는 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템을 가지고 있지 않다. 반드시 별도의 외부 계정 시스템을 사용해야 하며, 계정 시스템 연동을 위해서 OAuth나 Webhook가 같은 계정 연동 방식을 지원한다.

서비스 어카운트

서비스 어카운트가 다소 낮설 수 있는데, 예를 들어 클라이언트가 쿠버네티스 API를 호출하거나, 콘솔이나 기타 클라이언트가 쿠버네티스 API를 접근하고자 할때, 이는 실제 사람인 사용자가 아니라 시스템이 된다. 그래서, 쿠버네티스에서는 이를 일반 사용자와 분리해서 관리하는데 이를 서비스 어카운트 service account라고 한다. 서비스 어카운트를 생성하는 방법은 간단하다. kubectl create sa {서비스 어카운트명} 을 실행하면 된다.

인증 방식

Basic HTTP Auth

  • HTTP 요청에 사용자 아이디와 비밀번호를 실어 보내서 인증하는 방식
  • 아이디와 비밀번호가 네트워크를 통해서 매번 전송되기 때문에 그다지 권장하지 않는 방법

Access token via HTTP Header

  • 일반적인 REST API 인증에 많이 사용되는 방식
  • 사용자 인증 후에, 사용자에 부여된 API TOKEN을 HTTP Header에 실어서 보내는 방식

Client cert

  • 클라이언트의 식별을 인증서 (Certification)을 이용해서 인증하는 방식
  • 한국으로 보자면 인터넷 뱅킹의 공인 인증서와 같은 방식으로 생각하면 된다. 보안성은 가장 높으나, 인증서 관리에 추가적인 노력이 필요

Authorization (인가)

쿠버네티스의 권한 처리 체계는 기본적으로 역할기반의 권한 인가 체계를 가지고 있다. 이를 RBAC (Role based access control)이라고 한다.

사용자의 계정은 개개별 사용자인 user, 그리고 그 사용자들의 그룹은 user group, 마지막으로 시스템의 계정을 정의하는 service account로 정의된다.권한은 Role이라는 개념으로 정의가 되는데, 이 Role에는 각각의 리소스에 대한 권한이 정의된다. 예를 들어 pod 정보에대한 create/list/delete등을 정의할 수 있다. 이렇게이렇게 정의된 Role은 계정과 RoleBinding 이라는 정의를 통해서, 계정과 연결이 된다.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  

Role을 사용자에게 부여하기 위해서 RoleBinding 설정을 아래와 같이 정의하자.아래 Role-Binding은 read-pods라는 이름으로 jane이라는 user에서 Role을 연결하였고, 앞에서 정의한 pod-reader를 연결하도록 정의하였다.

kind: RoleBinding
apiVersion: rbac.authorication.k8s.io/v1
metadata:
  name: read-pods
  namespace: dafult
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorication.k8s.io
roleRef:
  kind: Role
  name: podreader
  apiGroup: rbac.authorication.k8s.io
tistory by 조대협

RBAC 관련 플러그인 및 확인 방법

# 설치
kubectl krew install access-matrix rbac-tool rbac-view rolesum whoami

# k8s 인증된 주체 확인
kubectl whoami
arn:aws:iam::9112...:user/admin

# Show an RBAC access matrix for server resources
kubectl access-matrix # Review access to cluster-scoped resources
kubectl access-matrix --namespace default # Review access to namespaced resources in 'default'

# RBAC Lookup by subject (user/group/serviceaccount) name
kubectl rbac-tool lookup
kubectl rbac-tool lookup system:masters
  SUBJECT        | SUBJECT TYPE | SCOPE       | NAMESPACE | ROLE
+----------------+--------------+-------------+-----------+---------------+
  system:masters | Group        | ClusterRole |           | cluster-admin

kubectl rbac-tool lookup system:nodes # eks:node-bootstrapper
kubectl rbac-tool lookup system:bootstrappers # eks:node-bootstrapper
kubectl describe ClusterRole eks:node-bootstrapper

# RBAC List Policy Rules For subject (user/group/serviceaccount) name
kubectl rbac-tool policy-rules
kubectl rbac-tool policy-rules -e '^system:.*'
kubectl rbac-tool policy-rules -e '^system:authenticated'

# Generate ClusterRole with all available permissions from the target cluster
kubectl rbac-tool show

# Shows the subject for the current context with which one authenticates with the cluster
kubectl rbac-tool whoami
# Summarize RBAC roles for subjects : ServiceAccount(default), User, Group
kubectl rolesum -h
kubectl rolesum aws-node -n kube-system
kubectl rolesum -k User system:kube-proxy
kubectl rolesum -k Group system:masters
kubectl rolesum -k Group system:authenticated
# [터미널1] A tool to visualize your RBAC permissions
kubectl rbac-view
## 이후 해당 작업용PC 공인 IP:8800 웹 접속 : 최초 접속 후 정보 가져오는데 다시 시간 걸림 (2~3분 정도 후 화면 출력됨) 
echo -e "RBAC View Web http://$(curl -s ipinfo.io/ip):8800"

STS(Security Token Service) 임시 보안 자격 증명 생성

# testuser 사용자 생성
aws iam create-user --user-name testuser

# 사용자에게 프로그래밍 방식 액세스 권한 부여
aws iam create-access-key --user-name testuser
# testuser 사용자에 정책을 추가
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --user-name testuser

# get-caller-identity 확인
aws sts get-caller-identity --query Arn
# eksctl 사용 >> iamidentitymapping 실행 시 aws-auth 컨피그맵 작성해줌
# Creates a mapping from IAM role or user to Kubernetes user and groups
eksctl get iamidentitymapping --cluster $CLUSTER_NAME
eksctl create iamidentitymapping --cluster $CLUSTER_NAME --username testuser --group system:masters --arn arn:aws:iam::$ACCOUNT_ID:user/testuser

EC2 Instance Profile(IAM Role)에 맵핑된 k8s rbac 확인

# awscli 파드 생성
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: awscli-pod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: awscli-pod
  template:
    metadata:
      labels:
        app: awscli-pod
    spec:
      containers:
      - name: awscli-pod
        image: amazon/aws-cli
        command: ["tail"]
        args: ["-f", "/dev/null"]
      terminationGracePeriodSeconds: 0
EOF

# 파드 생성 확인
kubectl get pod -owide

# 파드 이름 변수 지정
APODNAME1=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[0].metadata.name})
APODNAME2=$(kubectl get pod -l app=awscli-pod -o jsonpath={.items[1].metadata.name})
echo $APODNAME1, $APODNAME2

# awscli 파드에서 EC2 InstanceProfile(IAM Role)의 ARN 정보 확인
kubectl exec -it $APODNAME1 -- aws sts get-caller-identity --query Arn
kubectl exec -it $APODNAME2 -- aws sts get-caller-identity --query Arn

# awscli 파드에서 EC2 InstanceProfile(IAM Role)을 사용하여 AWS 서비스 정보 확인 >> 별도 IAM 자격 증명이 없는데 어떻게 가능한 것일까요?
# > 최소권한부여 필요!!! >>> 보안이 허술한 아무 컨테이너나 탈취 시, IMDS로 해당 노드의 IAM Role 사용 가능!
kubectl exec -it $APODNAME1 -- aws ec2 describe-instances --region ap-northeast-2 --output table --no-cli-pager
kubectl exec -it $APODNAME2 -- aws ec2 describe-vpcs --region ap-northeast-2 --output table --no-cli-pager
 
# EC2 메타데이터 확인 : IDMSv1은 Disable, IDMSv2 활성화 상태, IAM Role - 링크
kubectl exec -it $APODNAME1 -- bash
-----------------------------------
#아래부터는 파드에 bash shell 에서 실행
curl -s http://169.254.169.254/ -v
# Token 요청 
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo
curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" ; echo

# Token을 이용한 IMDSv2 사용
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
echo $TOKEN
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/ ; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/ ; echo

# 위에서 출력된 IAM Role을 아래 입력 후 확인
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/iam/security-credentials/eksctl-myeks-nodegroup-ng1-NodeInstanceRole-1DC6Y2GRDAJHK
## 출력된 정보는 AWS API를 사용할 수 있는 어느곳에서든지 Expiration 되기전까지 사용 가능

# 파드에서 나오기
exit
---

EKS IMDS & IRSA & Pod Identity

IMDS(Instances Meta Data Service)

  • 인스턴스에 대한 데이터를 보유한 서비스
    • 인스턴스에 사용된 AMI ID (/latest/meta-data/ami-id)
    • 인스턴스 프로파일에 대한 정보 (/latest/meta-data/iam/info)
    • 인스턴스 자격 증명 문서 (/latest/dynamic/instance-identity/document, pkcs7, signature)
    • Vault 를 통한 EC2 인증 등에 사용
    • Systems Manager 기본 호스트 관리 구성, GuardDuty 런타임 모니터링 등 사용을 위한 인스턴스 자체 자격 증명 (권한 없음) (latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance)
    • 인스턴스 프로파일의 임시 자격 증명 (latest/meta-data/iam/security-credentials/role-name)
    • Userdata (/latest/user-data)

동작방식

IMDSv1

  1. IMDSv1 을 사용한다는 것이 IMDSv2 를 사용하지 못하는 것은 아님
    a. 메타데이터 사용 (http-endpoint: enabled) 설정 시, IMDS 버전 선택은 선택적임 (http-tokens: optional)
    b. 기본적으로 IMDSv1, IMDSv2 모두 사용 가능 상태
  2. 다만, 2022년 10월 부터 인스턴스 실행 시 IMDSv2 가 기본으로 설정됨
    a. http-tokens: required
  3. HTTP GET 메소드를 통한 “요청/응답” 방식으로, 별도의 토큰 발급 필요없이
    요청만 할 수 있다면 임시자격증명을 획득 가능

동작방식

IMDSv2

  1. IMDSv2 사용을 강제하게 되면, IMDSv1 방식으로 요청이 불가
    a. IMDS 버전 선택 강제 (http-tokens: required)
  2. HTTP PUT 메소드를 통해 세션토큰을 받고, 해당 세션토큰을 GET 메소드의
    헤더에 추가하여 임시자격증명을 획득 가능
    a. IMDSv1 과 달리 “세션 지향” 방식이라고 함
  3. 이외에도 다양한 보안적 이점을 누릴 수 있음
    a. GET 메소드를 통한 SSRF (Server Side Request Forgery) 방지 (세션토큰이 있어야 하니까)
    b. X-Forwarded-For 헤더 포함된 요청에 대한 세션토큰 미발급

동작 방식

IRSA(IAM Roles for Service Accounts)

  • Pod 내부 어플리케이션 컨테이너가 역할을 사용할 수 있게 해주는 기능

IRSA가 없었을때

IRSA 적용 이후

동작방식

EKS Pod Identity

  • IRSA와 달리 외부 단일 지점에서 Pod이 역할을 사용할 수 있도록 하는 기능
  • 기존에 ECS에서 사용하던 방식을 도입
  • Kubernetes 1.24 버전 이상을 사용

동작방식

  1. 링크 로컬 주소와 EC2의 IMDS의 유사성:
    • 링크 로컬 주소는 EC2의 인스턴스 메타데이터 서비스 (Instance Metadata Service, IMDS)와 유사한 역할을 합니다. IMDS는 EC2 인스턴스에서 실행되는 메타데이터에 액세스할 수 있는 엔드포인트입니다. 링크 로컬 주소도 로컬 네트워크 인터페이스를 통해 인스턴스의 메타데이터에 접근할 수 있는 역할을 합니다.
  2. 어떤 방식으로 접근되는지:
    • 이 링크 로컬 주소는 모든 EC2 인스턴스에서 오픈되어 있는 것이 아니며, Capabilities와 네트워크 인터페이스의 조합으로 제한됩니다. 즉, 특정 Capabilities와 네트워크 인터페이스에만 해당 주소가 오픈되어 있습니다.
    • 예를 들어, 80 포트를 열었을 때 해당 네트워크 인터페이스에 링크 로컬 주소가 바인딩됩니다. 이는 특정 네트워크 인터페이스에만 접근이 가능하고, 모든 EC2 인스턴스에서 이 주소에 접근할 수 있는 것은 아닙니다.

실습

결과

OWASP Kubernetes Top Ten

OWASP는 “Open Web Application Security Project”의 약자로, 웹 애플리케이션 보안에 대한 정보를 제공하고 보안 취약점을 식별하고 해결하기 위한 비영리 단체입니다. OWASP는 전 세계의 보안 전문가들이 모여 웹 애플리케이션 보안을 개선하기 위해 노력하고 있는 공동체입니다. OWASP는 다양한 보안 취약점, 보안 취약점에 대한 대응 방법, 보안 도구 및 자료 등을 제공하여 개발자, 보안 전문가 및 조직이 웹 애플리케이션 보안을 향상시키도록 돕습니다.

OWASP는 주로 다음과 같은 활동을 수행합니다:

  1. 보안 취약점 목록: OWASP Top 10과 같은 보안 취약점 목록을 작성하고 유지보수합니다. 이 목록은 웹 애플리케이션에서 가장 일반적으로 발견되는 보안 취약점을 나열하고 설명하여 개발자와 보안 전문가가 이를 인지하고 대응할 수 있도록 돕습니다.
  2. 보안 가이드: OWASP는 웹 애플리케이션 보안을 위한 다양한 가이드와 자료를 제공합니다. 이 가이드에는 보안 취약점을 식별하고 예방하는 방법, 보안 테스트를 수행하는 방법, 보안 프레임워크 및 도구 사용 방법 등이 포함됩니다.
  3. 보안 도구 및 프로젝트: OWASP는 다양한 보안 도구와 프로젝트를 개발하고 유지보수합니다. 이 도구와 프로젝트는 웹 애플리케이션 보안을 향상시키는 데 도움이 되며, 취약점 스캐너, 보안 헤더 생성기, 보안 교육 자료 등이 포함됩니다.
  4. 교육 및 컨퍼런스: OWASP는 보안 컨퍼런스 및 워크샵을 주관하고 보안 교육 자료를 제공하여 개발자와 보안 전문가가 보다 안전한 웹 애플리케이션을 개발하고 운영할 수 있도록 지원합니다.

kyverno

Kyverno는 Kubernetes를 위해 특별히 설계된 정책 엔진으로, CNCF 프로젝트로서 팀이 협업하고 정책을 코드로 강제할 수 있도록 해줍니다. 이를 통해 Kubernetes 리소스를 YAML로 선언적으로 정의할 수 있으며, 별도의 정책 언어를 배울 필요가 없습니다. Kyverno를 사용하면 정책을 Kubernetes 리소스로 쉽게 작성할 수 있으며, 결과는 Kubernetes 리소스 및 이벤트로 사용할 수 있습니다. 또한 Kyverno 정책을 사용하여 리소스를 검증, 변형 및 생성할 수 있으며, 이미지 서명 및 인증을 검증하여 완전한 소프트웨어 공급 사슬 보안 표준을 준수할 수 있습니다. 또한 Kyverno 정책은 리소스 종류, 이름, 레이블 선택기 등을 사용하여 리소스를 일치시킬 수 있습니다.

Kyverno의 기능은 다음과 같습니다:

  • 정책을 Kubernetes 리소스로 사용하여 검증, 변형, 생성 또는 정리할 수 있습니다.
  • 소프트웨어 공급 사슬 보안을 위해 컨테이너 이미지를 확인할 수 있습니다.
  • 이미지 메타데이터를 검사할 수 있습니다.
  • 레이블 선택기 및 와일드카드를 사용하여 리소스를 일치시킬 수 있습니다.
  • Kustomize와 유사한 방식으로 오버레이를 사용하여 검증 및 변형할 수 있습니다.
  • Namespace 간에 구성을 동기화할 수 있습니다.
  • 거부된 리소스를 차단하거나 정책 위반을 보고할 수 있습니다.
  • 자체 서비스 보고서 및 정책 예외를 생성할 수 있습니다.
  • Kyverno CLI를 사용하여 정책을 테스트하고 CI/CD 파이프라인에서 리소스를 유효성 검사할 수 있습니다.
  • git 및 kustomize와 같은 익숙한 도구를 사용하여 정책을 코드로 관리할 수 있습니다.

Kyverno는 동적 Admission Control로 실행되며, Mutating/Validating Admission에서 작동하여 허용/거부 결과를 반환합니다.
주요 구성 요소는 Webhook Server 및 Webhook Controller입니다. Webhook Server는 Kubernetes API 서버에서 수신된 AdmissionReview 요청을 처리하고 Engine으로 보냅니다. 이는 Webhook Controller에 의해 동적으로 구성되며, 설치된 정책을 감시하고 해당 정책과 일치하는 리소스만 요청하도록 웹훅을 수정합니다. Cert Renewer는 웹훅에 필요한 인증서를 감시하고 갱신하는 역할을 합니다. Background Controller는 UpdateRequests를 조정하여 생성 및 기존 정책을 처리합니다. Report Controllers는 중간 리소스에서 Policy Reports의 생성 및 조정을 처리합니다.

Pod / Container Security context

파드와 컨테이너의 보안 컨텍스트는 Kubernetes에서 실행되는 워크로드의 보안 관련 환경 및 설정을 의미합니다. 이는 파드 내부의 각 컨테이너에 적용되는 보안 관련 설정으로 구성됩니다. 보안 컨텍스트는 다음과 같은 요소를 포함할 수 있습니다:

  1. 권한 및 권한 부여: 컨테이너가 어떤 작업을 수행할 수 있는지 제어하는 데 사용됩니다. 이러한 권한은 리눅스에서는 Linux Security Modules(LSM)을 통해 설정될 수 있으며, 예를 들어 SELinux 또는 AppArmor을 사용할 수 있습니다. Kubernetes에서는 Security Context를 사용하여 컨테이너의 권한을 설정할 수 있습니다. 이를 통해 컨테이너가 특정 사용자 ID로 실행되거나 특정 리눅스 캐퍼빌리티(capability)을 가지도록 설정할 수 있습니다.
  2. 네트워크 보안: 컨테이너 간 및 외부와의 통신을 제어하는 데 사용됩니다. Kubernetes에서는 네트워크 정책(Network Policies)을 사용하여 특정 파드 간의 트래픽을 제한하거나 특정 네트워크 정책을 적용할 수 있습니다. 또한 PodSecurityPolicy를 사용하여 특정 파드의 네트워크 특성을 제어할 수 있습니다.
  3. 파일 시스템 및 리소스 제한: 컨테이너가 파일 시스템에 액세스하는 권한과 리소스를 사용하는 제한을 설정하는 데 사용됩니다. Kubernetes에서는 Security Context를 사용하여 컨테이너의 파일 시스템 권한을 설정하고, 리소스 제한 및 요청을 설정할 수 있습니다.
  4. 환경 변수 및 시크릿 관리: 컨테이너에서 사용되는 환경 변수와 시크릿을 안전하게 관리하는 데 사용됩니다. Kubernetes에서는 Secrets 및 ConfigMaps를 사용하여 컨테이너에서 사용되는 중요한 정보를 안전하게 관리할 수 있습니다.
  5. 접근 제어: 컨테이너 간 및 호스트 시스템과의 상호 작용을 제어하는 데 사용됩니다. Kubernetes에서는 PodSecurityPolicy를 사용하여 특정 파드에서 허용되는 호스트 시스템과의 상호 작용을 제어할 수 있습니다.

Container Security Context

종류개요
privilleged특수 권한을 가진 컨테이너로 실행
capabilitiesCapabilities 의 추가와 삭제
allowPrivilegeEscalation컨테이너 실행 시 상위 프로세스보다 많은 권한을 부여할지 여부
readOnlyRootFilesystemroot 파일 시스템을 읽기 전용으로 할지 여부
runAsUser실행 사용자
runAsGroup실행 그룹
runAsNonRoot
root 에서 실행을 거부
seLinuxOptionsSELinux 옵션

readOnlyRootFilesystem

  • root 파일 시스템을 읽기 전용으로 사용
#
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: rootfile-readonly
spec:
  containers:
  - name: netshoot
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
    securityContext:
      readOnlyRootFilesystem: true
  terminationGracePeriodSeconds: 0
EOF

# 파일 생성 시도
kubectl exec -it rootfile-readonly -- touch /tmp/text.txt
touch: /tmp/text.txt: Read-only file system
command terminated with exit code 1

# 기존 파일 수정 시도 : 아래 /etc/hosts파일 말고 다른 파일로 예제 만들어 두자
## 기본적으로  mount 옵션이 ro 이긴 한데. 특정 파일이나 폴더가 rw로 mount가 되어서 그곳에서는 파일 생성, 삭제등이 가능하네요.
## 특히 /etc/hosts 파일은 HostAliases로 항목 추가가 가능한데, 해당 파링은 kubelet에 의해 관리되고, 파드 생성/재시작 중 덮었여질 수 있다.
## /dev 라던가 /sys/fs/cgroup 폴더 안에서도 가능하네요.
## /etc/hostname 같은 경우는 호스트와 별도의 파일이지만 mount가 / (ro)에 속하게 되어 제한이 걸리네요.
kubectl exec -it rootfile-readonly -- cat /etc/hosts
kubectl exec -it rootfile-readonly -- sh -c "echo write > /etc/hosts"
kubectl exec -it rootfile-readonly -- cat /etc/hosts

# 특정 파티션, 파일의 ro/rw 확인
kubectl exec -it rootfile-readonly -- mount | grep hosts
/dev/root on /etc/hosts type ext4 (rw,relatime,discard)

kubectl exec -it rootfile-readonly -- mount | grep ro
overlay on / type overlay (ro,relatime~~~~~~~~~~

## /proc, /dev, /sys/fs/cgroup, /etc/hosts, /proc/kcore, /proc/keys, /proc/timer_list
kubectl exec -it rootfile-readonly -- mount | grep rw
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
...

# 파드 상세 정보 확인
kubectl get pod rootfile-readonly -o jsonpath={.spec.containers[0].securityContext} | jq
{
  "readOnlyRootFilesystem": true
}

Linux Capabilities

  • 슈퍼 유저의 힘을 작은 조각으로 나눔
# Linux Capabilities 확인 : 현재 38개
capsh --print
...
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read

# proc 에서 확인 : bit 별 Capabilities - 링크
cat /proc/1/status | egrep 'CapPrm|CapEff'
CapPrm:	0000003fffffffff
CapEff:	0000003fffffffff

Capability Description                                                                                                                                                                
cap_chown 파일이나 디렉토리의 소유자를 변경할 수 있는 권한
cap_dac_override 파일이나 디렉토리의 접근 권한을 무시하고 파일이나 디렉토리에 대한 접근을 수행할 수 있는 권한 (DAC의 약자는 Discretionary access control이다)
cap_dac_read_search 파일이나 디렉토리를 읽거나 검색할 수 있는 권한
cap_fowner 파일이나 디렉토리의 소유자를 변경할 수 있는 권한
cap_fsetid 파일이나 디렉토리의 Set-User-ID (SUID) 또는 Set-Group-ID (SGID) 비트를 설정할 수 있는 권한
cap_kill 다른 프로세스를 종료할 수 있는 권한
cap_setgid 프로세스가 그룹 ID를 변경할 수 있는 권한
cap_setuid 프로세스가 사용자 ID를 변경할 수 있는 권한
cap_setpcap 프로세스가 자신의 프로세스 권한을 변경할 수 있는 권한
cap_linux_immutable 파일의 immutability(불변성) 속성을 변경할 수 있는 권한을 제공
cap_net_bind_service 프로그램이 특정 포트에 바인딩(bind)하여 소켓을 개방할 수 있는 권한
cap_net_broadcast 프로세스가 네트워크 브로드캐스트 메시지를 보낼 수 있는 권한
cap_net_admin 네트워크 인터페이스나 소켓 설정을 변경할 수 있는 권한
cap_net_raw 네트워크 패킷을 송수신하거나 조작할 수 있는 권한
cap_ipc_lock 메모리 영역을 잠금(lock)하고 언락(unlock)할 수 있는 권한
cap_ipc_owner IPC 리소스(Inter-Process Communication Resources)를 소유하고, 권한을 변경할 수 있는 권한
cap_sys_module 커널 모듈을 로드하거나 언로드할 수 있는 권한
cap_sys_rawio 입출력(I/O) 포트와 같은 하드웨어 리소스를 직접 접근할 수 있는 권한
cap_sys_chroot 프로세스가 chroot() 시스템 콜을 호출하여 프로세스의 루트 디렉토리를 변경할 수 있는 권한
cap_sys_ptrace 다른 프로세스를 추적(trace)하거나 디버깅할 수 있는 권한
cap_sys_pacct 프로세스 회계(process accounting)를 위한 파일에 접근할 수 있는 권한
cap_sys_admin 시스템 관리자 권한을 제공하는 권한
cap_sys_boot 시스템 부팅과 관련된 작업을 수행할 수 있는 권한
cap_sys_nice 프로세스의 우선순위를 변경할 수 있는 권한
cap_sys_resource 자원 제한(resource limit)과 관련된 작업을 수행할 수 있는 권한
cap_sys_time 시스템 시간을 변경하거나, 시간 관련 시스템 콜을 사용할 수 있는 권한
cap_sys_tty_config 터미널 설정을 변경할 수 있는 권한
cap_mknod mknod() 시스템 콜을 사용하여 파일 시스템에 특수 파일을 생성할 수 있는 권한
cap_lease 파일의 잠금과 관련된 작업을 수행할 수 있는 권한
cap_audit_write 시스템 감사(audit) 로그에 대한 쓰기 권한
cap_audit_control 시스템 감사(audit) 설정과 관련된 작업을 수행할 수 있는 권한
cap_setfcap file system capability을 설정할 수 있는 권한
cap_mac_override SELinux 또는 AppArmor과 같은 MAC(Mandatory Access Control) 시스템을 우회하고 자신의 프로세스가 접근 가능한 파일, 디바이스, 네트워크 등을 제한 없이 접근할 수 있는 권한 
cap_mac_admin SELinux 또는 AppArmor과 같은 MAC(Mandatory Access Control) 시스템을 관리하고 수정할 수 있는 권한
cap_syslog 시스템 로그를 읽거나, 쓸 수 있는 권한
cap_wake_alarm 시스템의 RTC(Real-Time Clock)를 사용하여 장치를 깨우거나 슬립 모드를 해제할 수 있는 권한
cap_block_suspend 시스템의 전원 관리 기능 중 하나인 Suspend(절전 모드)를 방지하는 권한
cap_audit_read 시스템 감사(audit) 로그를 읽을 수 있는 권한

Pod의 Linux Capablities 기본 확인

Pod 시간 변경 시도

Pod에 권한 추가 후 변경 시도

Pod Security Context

  • 파드 레벨에서 보안 컨텍스트를 적용 : 파드에 포함된 모든 컨테이너가 영향을 받음
  • 파드와 컨테이너 정책 중복 시, 컨테이너 정책이 우선 적용됨
종류개요
runAsUser실행 사용자
runAsGroup실행 그룹
runAsNonRootroot 에서 실행을 거부
supplementalGroups프라이머리 GUI에 추가로 부여할 GID 목록을 지정
fsGroup파일 시스템 그룹 지정
systls덮어 쓸 커널 파라미터 지정
seLinuxOptionsSELinux 옵션 지정

runuser (실행 사용자 변경)

runAsNonRoot (root 사용자로 실행 제한)

fsGroup(파일시스템 그룹 지정)

sysctls (커널 파라미터 설정)

Leave a Comment