참조

https://thenewstack.io/10-kubernetes-best-practices-you-can-easily-apply-to-your-clusters/

루트 사용자 허용 안함

컨테이너의 모든 프로세스는 기본적으로 루트 사용자 (uid 0)로 실행됩니다.

컨테이너 호스트의 잠재적 인 손상을 방지하려면 컨테이너 이미지를 빌드 할 때 루트가 아닌 최소 권한 사용자 ID를 지정하고 모든 애플리케이션 컨테이너가 루트가 아닌 사용자로 실행되는지 확인하는 것이 중요합니다.

Ubuntu

FROM openjdk:8-jdk-alpine

RUN groupadd appgroup && useradd -G appgroup appuser
USER appuser

권한있는 컨테이너 허용 안 함

권한있는 컨테이너는 컨테이너 uid 0이 호스트의 uid 0에 매핑되는 모든 컨테이너로 정의됩니다.

권한있는 컨테이너 내의 프로세스는 무제한 호스트 액세스를 얻을 수 있습니다.

적절한 설정이 없으면 프로세스는 부모로부터 권한을 얻을 수도 있습니다.

응용 프로그램 컨테이너는 권한 모드에서 실행되지 않아야하며 권한 에스컬레이션은 허용되지 않아야합니다.

apiVersion: v1  
kind: Pod  
metadata:  
  name: hello-world  
spec:  
  containers:  
  # specification of the pod’s containers  
  # ...  
  securityContext:  
    readOnlyRootFilesystem: true  
    runAsNonRoot: true

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

새로운 기능 추가 금지

Linux에서는 기능을 사용하여 세분화 된 권한을 정의 할 수 있습니다.

Kubernetes를 사용하면 커널 액세스 수준을 높이고 잠재적으로 위험한 다른 동작을 허용하는 기능을 추가 할 수 있습니다.

애플리케이션 포드가 런타임에 새 기능을 추가 할 수 없는지 확인합니다.

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"]

커널 매개 변수 변경 허용 안함

Sysctl 인터페이스를 사용하면 런타임에 커널 매개 변수를 수정할 수 있습니다.

Kubernetes 포드에서 이러한 매개 변수는 구성의 일부로 지정할 수 있습니다.

커널 매개 변수 수정은 익스플로잇에 사용될 수 있으며 새 매개 변수 추가는 제한 되어야 합니다.

바인드 마운트 (hostPath 볼륨) 사용 허용 안함

Kubernetes 포드는 컨테이너에서 호스트 바인드 마운트 (예 : 컨테이너 호스트에 마운트 된 디렉토리 및 볼륨)를 사용할 수 있습니다.

호스트 리소스를 사용하면 공유 데이터에 액세스하거나 권한 상승을 허용 할 수 있습니다.

또한 호스트 볼륨을 사용하면 애플리케이션 포드가 특정 호스트에 연결됩니다. 바인드 마운트 사용은 애플리케이션 포드에 허용되지 않아야합니다.

도커 소켓 바인드 마운트에 대한 액세스 허용 안 함

도커 소켓 바인드 마운트를 사용하면 노드의 Docker 데몬에 액세스 할 수 있습니다.

이 액세스는 권한 에스컬레이션 및 Kubernetes 외부의 컨테이너 관리에 사용할 수 있습니다.

따라서 애플리케이션 워크로드에 대해 도커 소켓에 대한 액세스를 허용해서는 안됩니다.

호스트 네트워크 및 포트 사용 금지

컨테이너 호스트 네트워크 인터페이스를 사용하면 포드가 호스트 네트워킹 스택을 공유 할 수 있으므로 애플리케이션 포드에서 네트워크 트래픽을 스누핑 할 수 있습니다.

읽기 전용 루트 파일 시스템 필요

읽기 전용 루트 파일 시스템은 변경 불가능한 인프라 전략을 시행하는 데 도움이됩니다.

컨테이너는 컨테이너가 종료 된 경우에도 상태를 유지할 수있는 마운트 된 볼륨에 쓰기 만하면됩니다.

변경 불가능한 루트 파일 시스템은 악성 바이너리가 호스트 시스템에 쓰는 것을 방지 할 수도 있습니다.

포드 리소스 요청 및 제한 필요

애플리케이션 워크로드는 클러스터 리소스를 공유합니다. 따라서 각 포드에 할당 된 리소스를 관리하는 것이 중요합니다.

요청 및 제한은 포드별로 구성하고 최소한 CPU 및 메모리 리소스를 포함하는 것이 좋습니다.

          resources:
            limits:
              cpu: "1"
              memory: "1Gi"
            requests:
              cpu: "500m"
              memory: "500Mi"

livenessProbe 및 readinessProbe 필요

활성 및 준비 상태 프로브는 배포, 다시 시작 및 업그레이드 중에 포드의 수명주기를 관리하는 데 도움이됩니다.

이러한 검사가 제대로 구성되지 않은 경우 초기화하는 동안 포드가 종료되거나 준비되기 전에 사용자 요청 수신을 시작할 수 있습니다.

          readinessProbe:
            httpGet:
              port: http
              path: /actuator/health/readiness
            failureThreshold: 3
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 3
          livenessProbe:
            httpGet:
              port: http
              path: /actuator/health/liveness
            failureThreshold: 3
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 3
          startupProbe:
            httpGet:
              port: http
              path: /actuator/health
            initialDelaySeconds: 30
            failureThreshold: 5
            periodSeconds: 10

Page tree

08-14. Kubernetes 모범 사례