🔐 쿠버네티스 클러스터 보안 [securityContext, Network Policiy, Audit, Trivy, Kube-bench]

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

보안 컨텍스트 (securityContext)

포드 또는 컨테이너에 대한 권한 및 액세스 제어 설정을 정의합니다.

• 임의적 접근 제어: 파일과 같은 객체에 대한 접근 권한은 사용자 ID(UID)와 그룹 ID(GID)를 기준으로 결정됩니다 .

• SELinux(보안 강화 Linux) : 개체에 보안 레이블이 할당됩니다.

• 특권 또는 비특권으로 실행됩니다.

• Linux 기능 : 프로세스에 일부 권한을 부여하지만 루트 사용자의 모든 권한을 부여하지는 않습니다.

• AppArmor : 프로그램 프로필을 사용하여 개별 프로그램의 기능을 제한합니다.

• Seccomp : 프로세스의 시스템 호출을 필터링합니다.

• readOnlyRootFilesystem: 컨테이너의 루트 파일 시스템을 읽기 전용으로 마운트합니다.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000 # 컨테이너 UID 
    runAsGroup: 3000 # 컨테이너 GID
    fsGroup: 2000 # 보조적 그룹
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

• allowPrivilegeEscalation: 프로세스가 상위 프로세스보다 더 많은 권한을 얻을 수 있는지 여부를 제어합니다. no_new_privs 이 bool은 플래그가 컨테이너 프로세스에 설정되는지 여부를 직접 제어합니다.
  allowPrivilegeEscalation컨테이너가 다음과 같은 경우에는 항상 true입니다.
  • true일 경우 특권 모드로 실행되거나
  • CAP_SYS_ADMIN을 가짐
• false: 부모프로세스보다 권한을 더 갖지 못하도록함, Privileage Escalation 을 방지함

컨테이너 내부 보안 컨텍스트

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      runAsUser: 2000 # 해당 컨테이너에서 우선순위 더 높음
      allowPrivilegeEscalation: false

spec.containers.securityContext : 컨테이너 내부 UID
spec.seucirtyContext: 파드 내부 UID

권한 부여

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

내부 컨테이너 권한 부여 : capabilities

적용

외부에서 파드 내부 또는 컨테이너에 접근했을 때, 내부에서 동작 가능한 범위를 사전에 정해둔 UID등 유저 권한 설정을 제한하여 내부에 공격 및 피해를 방지 가능하다.

---

네트워크 정책 (Network Policies)

https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/

네트워크 정책을 통해 파드간 통신 설정

• 네트워크 내에 존재하는 엔드포인트 파드간의 통신 방법에만 적용
  • 허용되는 다른 파드(예외: 파드는 자신에 대한 접근을 차단할 수 없음)
  • 허용되는 네임스페이스
  • IP 블록(예외: 파드 또는 노드의 IP 주소와 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨)
• 파드에 허용되는 트래픽 규칙을 정의 및 제한

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector: # 정책을 적용할 파드
    matchLabels:
      role: db
  policyTypes:
    - Ingress
    - Egress
  ingress: # role: db인 파드에 적용할 인그레스 화이트리스트
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.1.0/24
        - namespaceSelector: #네임스페이스에 할당된 레이블
            matchLabels:
              project: myproject
        - podSelector: # 특정한 포드에 할당된 레이블 매치
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 6379
  egress: # 외부로 나가는 통신을 제한시키도록 설정 (ingress와 조건 동일)
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 5978

egress

나가는 트래픽에 대한 정책 설정
각 네트워크폴리시에는 화이트리스트 egress 규칙이 포함될 수 있다. 각 규칙은 to 와 ports 부분과 모두 일치하는 트래픽을 허용한다.
(화이트리스트 - 블랙리스트의 반대)

• namespace가 defualt 이고
• role=db 레이블을 가진 모든 파드에서 TCP포트 5978 의 CIDR 10.0.0.0/24 로의 연결을 허용함

ingress

들어오는 트래픽에 대한 정책 설정
각 네트워크폴리시에는 화이트리스트 ingress 규칙 목록이 포함될 수 있다. 각 규칙은 from 과 ports 부분과 모두 일치하는 트래픽을 허용한다.

• "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6379로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다.

  • 아래는 모두 하나라도 만족하면 통과됨 (or연산)
  • "role=frontend" 레이블이 있는 "default" 네임스페이스의 모든 파드(ingress 대상포드)
  • 네임스페이스와 "project=myproject" 를 레이블로 가지는 모든 파드(ingress 요청포드)
  • 172.17.0.0–172.17.0.255 와 172.17.2.0–172.17.255.255 의 범위를 가지는 IP 주소(예: 172.17.0.0/16 전체에서 172.17.1.0/24 를 제외)

정책 겹칠시

or 연산 허용 -> group3 에는 막아놨는데 group2에서 허용하면 통신 가능

---

Audit

https://kubernetes.io/ko/docs/tasks/debug/debug-cluster/audit/

쿠버네티스 감사(auditing)는 클러스터의 작업 순서를 문서화하는 보안 관련 시간별 레코드 세트를 제공한다. 클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션 및 컨트롤 플레인 자체에서 생성된 활동을 감사한다.

감사를 통해 클러스터 관리자는 다음 질문에 답할 수 있다.

• 무슨 일이 일어났는지?
• 언제 일어난 일인지?
• 누가 시작했는지?
• 어떤 일이 있었는지?
• 어디서 관찰되었는지?
• 어디서부터 시작되었는지?
• 그래서 어디까지 갔는지?

1. 감사 기록

언제 데이터를 기록할지

감사 기록은 kube-apiserver 컴포넌트 내에서 수명주기를 시작한다. 실행의 각 단계에서 각 요청은 감사 이벤트를 생성하고, 감사 이벤트는 특정 정책에 따라 사전 처리되고 백엔드에 기록된다. 정책은 기록된 내용을 결정하고 백엔드는 기록을 유지한다. 현재 백엔드 구현에는 로그 파일 및 웹훅이 포함된다.

각 요청들은 연관된 단계(stage) 와 함께 기록될 수 있다. 정의된 단계는 다음과 같다.

• RequestReceived - 감사 핸들러가 요청을 수신한 직후, 그리고 핸들러 체인으로 위임되기 전에 생성되는 이벤트에 대한 단계이다.
• ResponseStarted - 응답 헤더는 전송되었지만, 응답 본문(body)은 전송되기 전인 단계이다. 이 단계는 오래 실행되는 요청(예: watch)에 대해서만 생성된다.
• ResponseComplete - 응답 내용이 완료되었으며, 더 이상 바이트가 전송되지 않을 때의 단계이다.
• Panic - 패닉이 발생했을 때 생성되는 이벤트이다.

감사 로깅 기능은 감사에 필요한 일부 컨텍스트가 요청마다 저장되기 때문에 API 서버의 메모리 사용량을 증가시킨다. 메모리 소비량은 감사 로깅 구성에 따라 다르다.

2. 감사 정책

어떤 데이터를 기록할지

감사 정책은 기록해야 하는 이벤트와 포함해야 하는 데이터에 대한 규칙을 정의한다. 감사 정책 오브젝트 구조는 audit.k8s.io API 그룹에 정의되어 있다. 이벤트가 처리되면 규칙 목록과 순서대로 비교된다. 첫번째 일치 규칙은 이벤트의 감사 수준(audit level)을 설정한다.

• None - 이 규칙에 해당되는 이벤트는 로깅하지 않는다.
• Metadata - 요청 메타데이터(요청하는 사용자, 타임스탬프, 리소스, 동사(verb) 등)는 로깅하지만 요청/응답 본문은 로깅하지 않는다.
• Request - 이벤트 메타데이터 및 요청 본문을 로깅하지만 응답 본문은 로깅하지 않는다. 리소스 외의 요청에는 적용되지 않는다.
• RequestResponse - 이벤트 메타데이터 및 요청/응답 본문을 로깅한다. 리소스 외의 요청에는 적용되지 않는다.

--audit-policy-file 플래그를 사용하여 정책이 포함된 파일을 kube-apiserver에 전달할 수 있다. 플래그를 생략하면 이벤트가 기록되지 않는다. 감사 정책 파일에 rules 필드가 반드시 제공되어야 한다. 규칙이 없는(0개인) 정책은 적절하지 않은(illegal) 것으로 간주된다.

audit/audit-policy.yaml

apiVersion: audit.k8s.io/v1 # 필수사항임.
kind: Policy
# Request Received 단계의 모든 요청에 대해 감사 이벤트를 생성하지 않음.
omitStages:
  - "RequestReceived"
rules:
  # RequestResponse 수준에서 파드 변경 사항 기록
  - level: RequestResponse
    resources:
    - group: ""
      # 리소스 "파드" 가 RBAC 정책과 부합하는 파드의 하위 리소스에 대한
      # 요청과 일치하지 않음.
      resources: ["pods"]
  # 메타데이터 수준에서 "pods/log", "pods/status"를 기록함.
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # "controller-leader" 라는 컨피그맵에 요청을 기록하지 않음."
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # 엔드포인트 또는 서비스의 "system:kube-proxy"에 의한 감시 요청 기록하지 않음.
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # 핵심 API 그룹
      resources: ["endpoints", "services"]

  # 인증된 요청을 특정 리소스가 아닌 URL 경로에 기록하지 않음.
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # 와일드카드 매칭(wildcard matching).
    - "/version"

  # kube-system에 컨피그맵 변경 사항의 요청 본문을 기록함.
  - level: Request
    resources:
    - group: "" # 핵심 API 그룹
      resources: ["configmaps"]
    # 이 정책은 "kube-system" 네임스페이스의 리소스에만 적용됨.
    # 빈 문자열 "" 은 네임스페이스가 없는 리소스를 선택하는데 사용할 수 있음.
    namespaces: ["kube-system"]

  # 메타데이터 수준에서 다른 모든 네임스페이스의 컨피그맵과 시크릿 변경 사항을 기록함.
  - level: Metadata
    resources:
    - group: "" # 핵심 API 그룹
      resources: ["secrets", "configmaps"]

  # 요청 수준에서 코어 및 확장에 있는 다른 모든 리소스를 기록함.
  - level: Request
    resources:
    - group: "" # 핵심 API 그룹
    - group: "extensions" # 그룹의 버전을 기재하면 안 된다.

  # 메타데이터 수준에서 다른 모든 요청을 기록하기 위한 모든 수집 정책.
  - level: Metadata
    # 이 정책에 해당하는 감시자와 같은 장기 실행 요청은
    # RequestReceived에서 감사 이벤트를 생성하지 않음.
    omitStages:
      - "RequestReceived"

3. 감사 백엔드

감사 백엔드는 감사 이벤트를 외부 저장소에 유지한다. 기본적으로 kube-apiserver는 두 가지 백엔드를 제공한다.

• 이벤트를 파일 시스템에 기록하는 로그 백엔드
• 이벤트를 외부 HTTP API로 보내는 Webhook 백엔드

4. 로그 백엔드

--audit-policy-file 플래그를 사용하여 정책이 포함된 파일을 kube-apiserver에 전달할 수 있다. 플래그를 생략하면 이벤트가 기록되지 않는다. 감사 정책 파일에 rules 필드가 반드시 제공되어야 한다. 규칙이 없는(0개인) 정책은 적절하지 않은(illegal) 것으로 간주된다.

로그 백엔드는 감사이벤트를 JSONlines 형식으로 파일에 기록한다. 다음의 kube-apiserver 플래그를 사용하여 로그 감사 백엔드를 구성할 수 있다.

• --audit-log-path 는 로그 백엔드가 감사 이벤트를 쓰는 데 사용하는 로그 파일 경로를 지정한다. 이 플래그를 지정하지 않으면 로그 백엔드가 비활성화된다. - 는 표준 출력을 의미한다.
• --audit-log-maxage 는 오래된 감사 로그 파일을 보관할 최대 일수를 정의한다.
• --audit-log-maxbackup 은 보관할 감사 로그 파일의 최대 수를 정의한다.
• --audit-log-maxsize 는 감사 로그 파일이 로테이트 되기 전의 최대 크기(MB)를 정의한다.

클러스터의 컨트롤 플레인이 kube-apiserver를 파드로 실행하는 경우 감사 레코드가 지속되도록 정책 파일 및 로그 파일의 위치에 hostPath 를 마운트 해야한다. 예를 들면

/etc/kubernetes/manifests/kube-apiserver.yaml

--audit-policy-file=/etc/kubernetes/pki/audit.conf
--audit-log-path=/var/log/audit.log

불륨 마운트

/etc/kubernetes/manifests/kube-apiserver.yaml

...
volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/kubernetes/audit/
    name: audit-log
    readOnly: false

...
volumes:
- name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
    type: File

- name: audit-log
  hostPath:
    path: /var/log/kubernetes/audit/
    type: DirectoryOrCreate

• 
• 

---

Trivy

https://aquasecurity.github.io/trivy/v0.46/

컨테이너 취약점 진단

도커 이미지/ 컨테이너 내부의 모듈을 읽어서 해당 모듈들의 취약점을 데이터 베이스로 가져와서 모니터링

https://aquasecurity.github.io/trivy/v0.46/docs/target/container_image/

---

kube-bench

쿠버네티스 보안 점검 벤치마크: https://www.cisecurity.org/
https://aquasecurity.github.io/kube-bench/v0.6.15/

kube-bench 설치

curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.deb -o kube-bench_0.6.2_linux_amd64.deb

sudo apt install ./kube-bench_0.6.2_linux_amd64.deb -f

git hub 설치

git clone https://github.com/aquasecurity/kube-bench.git
cd kube-bench

config파일 기준 보안 점검 확인

./kube-bench --config-dir `pwd`/cfg --config `pwd`/cfg/config.yaml : configuration 디렉터리 및 파일 설정 (현재 환경에 따른 동작 정의된 파일)

---

falco

쿠버네티스 컨테이너 보안 모니터링

특정 이벤트 탐지 가능

• kubernetes 위협 탐지 엔진
• 런타임 보안 프로젝트 (런타임에서 동작하는 것을 실시간으로 모니터링)

설치

https://falco.org/ko/docs/installation/

falco on 쿠버네티스

https://falco.org/ko/docs/getting-started/falco-kubernetes-quickstart/

falco 생성 로그 매칭 필드

https://falco.org/ko/docs/reference/rules/supported-fields/

falco 실행

systemctl start falco
systemctl status falco
systemctl restart falco

로그파일 확인

/etc/falco/falco.yaml : falco 설정 파일

• file_output.filename: /var/log/events.log 를 통해서 로그파일 위치 설정 가능
  cat /var/log/events.log | grep falco

룰 추가

vi /etc/falco/falco_rules.yaml
vi /etc/falco/faco_rules.local.yaml : 사용자 정의 룰