쿠버네티스 감사는 클러스터에 대한 보안 관련 시간순 기록 세트를 제공합니다. Kube-apiserver는 감사를 수행합니다. 실행 단계의 각 요청은 이벤트를 생성하고, 이 이벤트는 특정 정책에 따라 사전 처리되어 백엔드에 기록됩니다. 정책은 기록될 내용을 결정하고 백엔드는 해당 기록을 유지합니다.
CIS(Center for Internet Security) Kubernetes 벤치마크 제어를 준수하는 일환으로 감사 로그를 구성하는 것이 좋습니다.
cluster.yml에서 다음 구성을 사용하여 기본적으로 감사 로그를 활성화할 수 있습니다.
서비스:
kube-api:
감사 로그:
활성화됨: true
감사 로그가 활성화되면 /etc/kubernetes/audit-policy.yaml에서 기본값을 확인할 수 있습니다. 로그 백엔드는 감사 이벤트를 JSONlines 형식의 파일에 기록합니다. 다음 kube-apiserver 플래그를 사용하여 로그 감사 백엔드를 구성할 수 있습니다.
--audit-log-path는 로그 백엔드가 감사 이벤트를 기록하는 데 사용하는 로그 파일 경로를 지정합니다. 이 플래그를 지정하지 않으면 로그 백엔드가 비활성화됩니다. -는 표준 출력을 의미합니다.
--audit-log-maxage는 오래된 감사 로그 파일을 보관할 최대 일수를 정의했습니다.
--audit-log-maxbackup은 보관할 감사 로그 파일의 최대 수를 정의합니다.
--audit-log-maxsize는 감사 로그 파일이 순환되기 전 최대 크기를 MB 단위로 정의합니다. 클러스터의 제어 평면에서 kube-apiserver를 Pod로 실행하는 경우, 감사 레코드가 유지되도록 정책 파일과 로그 파일의 위치에 hostPath를 마운트해야 합니다. 예:
--감사 정책 파일=/etc/kubernetes/감사 정책.yaml \
--audit-log-path=/var/log/audit.log

해결책(단계별) :
1. 컨테이너에 대한 SecurityContext를 생성합니다.

2. Dockerfile을 수정하여 취약한 라이브러리를 제거합니다. - Dockerfile을 업데이트하여 이미지에서 취약한 라이브러리를 제거합니다. 3. 이미지를 다시 빌드하고 레지스트리에 푸시합니다. - 업데이트된 Dockerfile을 사용하여 이미지를 다시 빌드합니다. - 업데이트된 이미지를 레지스트리에 푸시합니다. 4. 업데이트된 배포를 적용합니다. bash kubectl apply -f my-app-deployment.yaml - 'privileged: false': 컨테이너가 루트 권한으로 실행되는 것을 방지합니다. - 'allowPrivilegeEscalation: false: 컨테이너의 권한 상승 기능을 비활성화합니다. - 'capabilities: drop: ["ALL"]': 컨테이너에서 모든 기능을 제거합니다. - Dockerfile에서 취약한 라이브러리 제거: 컨테이너가 런타임 중에 취약한 라이브러리에 액세스하는 것을 방지합니다. 중요 참고 사항: - 이러한 조치는 컨테이너가 취약한 라이브러리에 액세스하는 것을 제한하고 상승된 권한으로 실행되는 것을 방지하기 위한 것입니다. - 취약성을 완화하려면 기본 이미지와 종속성을 정기적으로 업데이트하는 것이 중요합니다. - 컨테이너의 특정 요구 사항에 따라 '기능' 목록을 조정해야 할 수도 있습니다. - 보안 정책이 효과적이고 애플리케이션 기능을 손상시키지 않는지 확인하기 위해 항상 보안 정책을 철저히 테스트하세요.

ETCDCTL_API=3 etcdctl get /registry/secrets/default/cks-secret --cacert="ca.crt" --cert="server.crt" --key="server.key"
산출

암호화 구성을 사용하여 공급자 AES-CBC 및 ID를 사용하여 리소스 비밀을 보호하는 매니페스트를 생성하여 저장 중인 비밀 데이터를 암호화하고 모든 비밀이 새 구성으로 암호화되도록 합니다.

$vim /etc/falco/falco_rules.local.yaml
- 규칙: 컨테이너 드리프트 감지됨(열기+생성)
설명: open+create로 인해 컨테이너에 새로운 실행 파일이 생성됨
상태: >
evt.type에 (open, openat, creat)를 입력하고
evt.is_open_exec=true 및
컨테이너 및
runc_writing_exec_fifo가 아니고
runc_writing_var_lib_docker가 아니고
user_known_container_drift_activities가 아니며
이벤트.원시>=0
출력: >
%evt.time,%user.uid,%proc.name # 이것을 추가하세요/falco 문서를 참조하세요
우선순위: 오류
$kill -1 <Falco의 PID>
설명
[desk@cli] $ ssh node01
[node01@cli] $ vim /etc/falco/falco_rules.yaml
Container Drift Detected를 검색하여 falco_rules.local.yaml에 붙여넣습니다.
[node01@cli] $ vim /etc/falco/falco_rules.local.yaml
- 규칙: 컨테이너 드리프트 감지됨(열기+생성)
설명: open+create로 인해 컨테이너에 새로운 실행 파일이 생성됨
상태: >
evt.type에 (open, openat, creat)를 입력하고
evt.is_open_exec=true 및
컨테이너 및
runc_writing_exec_fifo가 아니고
runc_writing_var_lib_docker가 아니고
user_known_container_drift_activities가 아니며
이벤트.원시>=0
출력: >
%evt.time,%user.uid,%proc.name # 이것을 추가하세요/falco 문서를 참조하세요
우선순위: 오류
[node01@cli] $ vim /etc/falco/falco.yaml