[Kubernetes] 지난 밤 너가 한 짓을 알고 있다! - Audit

 

쿠버네티스에는 Audit 이라는 기능이 있습니다. 다들 눈치 채셨겠지만, Kube Api Server 에 어떤 API 를 호출했는지 감시하는 기능이죠.

쿠버네티스를 설치하면 기본적으로 제공 되지 않기 때문에 추가적으로 Audit 기능을 활성화 해주어야 합니다.

 

그래서 이번 글에서는 Audit 기능을 활성화해서 누가, 어떤 행위로, 어떤 리소스를 호출 했는지 감시해보겠습니다!

 

 

렛츠두더코드!

 

 

Audit 기능 활성화

---

control plane & data plane v1.26.1 에서 진행되었습니다

 

쿠버네티스 공식 문서를 이동한 후 Audit 을 검색해줍니다. 그리고 클릭해서 문서를 확인합니다.

k8s docs

 

밑으로 쭉쭉 내려서 로그 백엔드 섹션으로 이동합니다.

 

/etc/kubernetes/manifests/kube-apiserver.yaml 에 아래와 같이 추가합니다.

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

 

이외 추가 옵션을 줄 수 있습니다.

    --audit-policy-file=/etc/kubernetes/audit-policy.yaml 
    --audit-log-path=/var/log/kubernetes/audit/audit.log
    --audit-log-maxage=10 # 10일까지만 보관
    --audit-log-maxbackup=10 # 최대 10개의 파일만 보관
    --audit-log-maxsize=10 # 로테이트 되기 전 최대 크기는 10MB

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

 

그런 다음 볼륨을 마운트를 해줍니다.

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

 

그리고 마지막으로 HostPath 를 구성합니다.

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

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

 

HostPath 로 구성함으로써 호스트(control plane) 에 존재하는 audit-policy.yaml 을 kube-apiserver container 에 전달해주고, kube-apiserver container 에서 생성되는 audit.log 를 호스트에 생성되게 합니다.

 

근데 아마 이대로 실행하면 kube-apiserver 에서 에러가 발생할 것입니다. 왜냐 우리는 audit-policy.yaml 을 만든 적이 없기 때문입니다.

 

그럼 audit-policy.yaml 을 만들어 보죠!

 

 

audit-policy.yaml 작성하기

---

audit-policy 에는 중요한 개념 2가지가 있습니다.

 

하나는 감사 단계(audit stage), 다른 하나는 감사 수준(audit level) 입니다.

 

 

감사 단계(audit stage)

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

 

감사 수준(audit level)

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

 

정의로만 봐서는 크게 이해하기시가 힘들겁니다. 저도 이렇게만 봐서는 이해가 안갑니다..

큰 그림

 

그럼 공식 문서에 나와있는 예제를 한번 보죠! 좀 더 이해가 쉬울 겁니다!

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"

 

예제의 양이 꽤나 방대하니 중요하다고 생각하는 포인트만 추려봤습니다.

apiVersion: audit.k8s.io/v1 # 필수사항임.
kind: Policy
# Request Received 단계의 모든 요청에 대해 감사 이벤트를 생성하지 않음.
omitStages:
  - "RequestReceived"
rules:
  
  # 첫번째 룰
  # RequestResponse 수준에서 파드 변경 사항 기록
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]
      
  # 두번째 룰
  # RequestResponse 수준에서 파드 변경 사항 기록
  - level: RequestResponse
    verbs: ["get", "watch", "list"]
    resources:
    - group: ""
      resources: ["pods"]      

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

  # 네번째 룰
  - level: None

 

.omitStage 로 RequestReceived 를 선언했기 때문에 이 policy 는 어떤 룰이든 RequestReceived 단계에서 로그를 생성하지 않습니다. 즉, 핸들러 체인으로 위임되기 전에 생성되는 이벤트는 생성하지 않죠.

 

그럼 이제 차례대로 룰을 확인해보죠.

 

첫번째 룰 

  # RequestResponse 수준에서 파드 변경 사항 기록
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]

 

RequestResponse 레벨 이기 때문에 이벤트의 메타데이터, 요청/응답 모두 로깅합니다.

그리고 로깅되는 대상은 pods 입니다. 

 

예를 들어 누군가 kubectl get pods 를  했을 경우 이 이벤트에 대한 로깅이 전부 기록됩니다.

누가 했는지, 어떤 행위를 했는지, 어떤 일이 있었는지 등 pods 에 대한 전부를 기록합니다.

 

두번째 룰

  # 두번째 룰
  # RequestResponse 수준에서 파드 변경 사항 기록
  - level: RequestResponse
    verbs: ["get", "watch", "list"]
    resources:
    - group: ""
      resources: ["pods"]

 

마찬가지로 RequestResponse 레벨 이기 때문에 이벤트의 메타데이터, 요청/응답 모두 로깅합니다.

그리고 로깅되는 대상은 pods 이되, get, watch, list 에 대해서만 기록합니다.

 

즉, create, update 등에 대한 기록은 진행되지 않습니다.

눈치 채신 분도 계신지만 이렇게 policy 를 작성할 경우 첫번째 룰은 결국 두번째 룰에 의해 제한됩니다.
왜냐면 첫번째 룰에선 pods 의 verbs 에 대해 전부 허용했지만, 두번째 룰에서 pods 의 verbs 를 제한했기 때문입니다.

 

세번째 룰

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

Metadata 레벨이기 때문에 요청 메타데이터(요청하는 사용자, 타임스탬프, 리소스, 동사(verb) 등)만 로깅합니다.

그리고 대상은 secrets, configmaps 입니다.

 

즉, kubectl get secrets, kubectl edit configmaps 등 모든 행위가 기록됩니다.

 

네번째 룰

  # 네번째 룰
  - level: None

Audit 은 policy 에 특별히 명시하지 않으면 다 허용됩니다.

예를 들어 위 policy 로 봤을 땐 deployments, pvc 등 명시되지 않는 리소스나 verbs 에 대한 행위는 전부 로깅되죠.

 

따라서 네번째 룰 처럼 명시하지 않은 룰에 대해서는 로깅되는 걸 막을 수 있습니다.

 

대략적으로 audit-policy.yaml 에 대해 알아보았고 이번엔 실제로 쿠버네티스에 적용해보죠!

 

 

지난 밤 너가 한 짓을 알고 있다!

---

실습을 위한 상황을 가정해보죠!

 

자비스를 구성하는 애플리케이션은 쿠버네티스 환경에서 구동되고 있습니다.

자비스에 대한 데이터베이스 또한 파드로 실행되고 있죠. 데이터베이스에 대한 정보는 시크릿으로 배포되어있구요.

그런데!
지난 밤 누군가 자비스의 데이터베이스 비밀번호를 알아내기 위해 시크릿에 접근을 한 사실을 알게되었습니다.
Audit 기능을 통해서 누가 시크릿에 접근을 시도했는지 알아내 보고자 합니다.

 

우선 Audit 를 활성해봅시다.

/etc/kubernetes/audit-policy.yaml 을 만들어 줍시다.

apiVersion: audit.k8s.io/v1 
kind: Policy
rules:
  - level: Metadata
    resources:
    - group: "" 
      resources: ["secrets"]
      
  - level: None

 

secrets 에만 관심이 있기 때문에 나머지 리소스에 대해서는 None 처리해줍니다.

 

그런 다음 /etc/kubernetes/manifest/kube-apiserver.yaml 에 아래 옵션들을 추가해줍니다.

...
--audit-policy-file=/etc/kubernetes/audit-policy.yaml 
--audit-log-path=/var/log/kubernetes/audit/audit.log
    
...
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

 

kube-apiserver 가 성공적으로 재시작되었다면, /var/log/kubernetes/audit 에 audit.log 파일이 생성되어 있을 거고, 로그 내용이 적혀있을 겁니다.

audit.log

 

secrets 관련된 메타데이터만 로그에 저장되는 것을 확인할 수 있습니다. 또한 다양한 stage 에서 진행됩니다.

 

그럼 과연 누가 db secrets 에 접근을 했는지 찾아보죠!

cat /var/log/kubernetes/audit/audit.log | grep db |  jq

 

아하! 범인을 찾았습니다!

잡았다 요놈!

 

범인은 바로 myuser 였군요.

myuser 이 가진 Role 을 제한해야겠어요!!

 

오늘은 이렇게 쿠버네티스의 Audit 기능을 알아봤습니다.

EKS 같은 경우 셋업 할때 Audit 설정을 할 수 있으며, cloud watch 에서 확인할 수 있도록 지원합니다.

 

그러면 오늘은 여기까지!