아직 업데이트하지 않았다면 Kubernetes 배포를  새롭고 흥미로운 여러 기능 이 포함 된 최신 버전 (1.16)으로 업데이트하십시오 . 모든 새 릴리스에는 일반적으로 다양한 보안 기능이 번들로 제공됩니다. Kubernetes를 최신 버전으로 업그레이드해야하는  7 가지  이유 를 강조하는 블로그 게시물을 확인하십시오 .

PodSecurityPolicy (kubectl을 통해) Kubernetes에서 사용할 수있는 클러스터 수준 리소스로 적극 권장됩니다. 이를 사용하려면 허용 컨트롤러를 활성화해야 합니다. 허용 컨트롤러의 특성을 감안할 때 하나 이상의 정책을 승인해야합니다. 그렇지 않으면 클러스터에서 포드를 만들 수 없습니다. PodSecurityPolicy 

포드 보안 정책은 다음과 같은 몇 가지 중요한 보안 사용 사례를 해결합니다.

• 권한있는 플래그로 컨테이너 실행 방지-이 유형의 컨테이너는 기본 호스트에서 사용할 수있는 대부분의 기능을 갖습니다. 이 플래그는 또한 CAP DROP 또는 CAP ADD를 사용하여 설정 한 모든 규칙을 덮어 씁니다.
• 호스트 PID / IPC 네임 스페이스, 네트워킹 및 포트 공유 방지-이 단계는 Docker 컨테이너와 기본 호스트간에 적절한 격리를 보장합니다.
• 볼륨 유형 사용 제한-예를 들어 쓰기 가능한 hostPath 디렉토리 볼륨은 컨테이너가 외부의 호스트 파일 시스템을 통과 할 수있는 방식으로 파일 시스템에 쓸 수 있도록 허용 하므로 반드시 사용해야합니다. pathPrefix readOnly: true 
• 호스트 파일 시스템 사용 제한
• ReadOnlyRootFilesystem을 통해 루트 파일 시스템에 대한 읽기 전용 적용
• 루트 권한으로의 권한 상승 방지
• 루트 권한이있는 컨테이너 거부
• 최소 권한 원칙을 준수하여 Linux 기능을 최소한으로 제한

이러한 속성 중 일부는를 통해 제어 할 수도 있습니다 . 여기에서 보안 컨텍스트에 대해 자세히 알아볼 수 있습니다 . 그러나 일반적으로 포드 수준 보안 컨텍스트를 사용자 지정하지 말고 대신 포드 보안 정책을 사용하는 것이 좋습니다 (이러한 제어를 적용하는 방법에 대한 권장 사항 # 6 참조). securityContext 

여기에서 포드 보안 정책에 대해 자세히 알아볼 수 있습니다 . 여기 와 여기에서 입학 컨트롤러에 대해 자세히 알아볼 수 있습니다 .  

네임 스페이스를 사용하면 논리 파티션을 만들고 리소스를 분리 할 수있을뿐만 아니라 사용자 권한 범위를 제한 할 수 있습니다. 여기에서 네임 스페이스에 대해 자세히 알아볼 수 있습니다 . 

네트워크 정책은 포드 통신이 허용되는 방식을 결정하는 데 사용됩니다. 안전한 Kubernetes 네트워크 정책 구축에 대한 자세한 내용은 블로그 게시물을 확인하십시오 . 

다음과 같은 승인되지 않은 이미지를 사용하는 포드를 거부하기 위해 승인 컨트롤러에서 승인되지 않은 이미지를 사용하지 못하도록 방지합니다 . ImagePolicyWebhook 

• 최근에 스캔되지 않은 이미지
• 허용되지 않은 기본 이미지를 사용하는 이미지
• 안전하지 않은 레지스트리의 이미지

여기에서 자세히 알아볼 수 있습니다 . ImagePolicyWebhook 

Kubernetes API 서버는 외부 사용자와 Kubernetes 구성 요소 간의 모든 REST API 호출을 처리합니다.

마스터 노드에서 아래 명령을 실행하십시오.

ps -ef | grep kube-apiserver

출력에서 다음을 확인하십시오.

• --anonymous-auth 인수는 . 이 설정은 다른 인증 방법에 의해 거부되지 않은 요청이 익명으로 처리되지 않으므로 정책에 대해 허용됩니다. false
• --basic-auth-file 논쟁이 없습니다. 기본 인증은 인증을 위해 선호하는 토큰이나 인증서 대신 일반 텍스트 자격 증명을 사용합니다.
• --insecure-allow-any-token 논쟁이 없습니다. 이 설정은 인증 된 보안 토큰 만 허용되도록합니다.
• – kubelet-https 인수가 없거나으로 표시됩니다 . 이 구성은 API 서버와 kubelet 간의 연결이 TLS (Transport Layer Security)를 통해 전송 중에 보호되도록합니다. true
• --insecure-bind-address 논쟁이 없습니다. 이 구성은 API 서버가 안전하지 않은 주소에 바인딩되는 것을 방지하여 마스터 노드에 대한 비인증 및 암호화되지 않은 액세스를 방지하여 공격자가 잠재적으로 중요한 데이터를 읽을 위험을 최소화합니다.
• --insecure-port 인수는 . 이 설정은 API 서버가 안전하지 않은 포트에서 제공되는 것을 방지하여 마스터 노드에 대한 인증되지 않고 암호화되지 않은 액세스를 방지하고 공격자가 클러스터를 제어 할 위험을 최소화합니다. 0
• --secure-port 인수가 존재하지 않거나 1에서 65535 사이의 정수로 표시됩니다. 여기서 목표는 인증 및 승인을 통해 모든 트래픽이 https를 통해 제공되는지 확인하는 것입니다.
• --profiling 인수는 . 병목 현상이 발생하거나 조사가 필요한 문제를 해결해야하는 경우가 아니라면 프로파일 러가 필요 없으며 불필요하게 시스템 및 프로그램 세부 정보가 노출 될 수 있습니다. false
• --repair-malformed-updates 인수는 . 이 설정을 사용하면 클라이언트의 의도적으로 잘못된 요청이 API 서버에서 거부됩니다. false
• --enable-admission-plugins 인수가를 포함하지 않는 값으로 설정되었습니다 . 이 설정을 항상 허용하도록 구성하면 허용 제어 플러그인에서 명시 적으로 허용하지 않더라도 요청을 허용하므로 플러그인의 효율성이 떨어집니다. AlwaysAdmit
• --enable-admission-plugins 인수는를 포함하는 값으로 설정됩니다 . 이 구성은 사용자가 단순히 이미지 이름 만 알면 노드에서 어떤 포드로도 이미지를 가져올 수 없도록합니다. 이 컨트롤을 사용하면 컨테이너를 시작하기 전에 항상 이미지를 가져 오므로 유효한 자격 증명이 필요합니다. AlwaysPullImages
• --enable-admission-plugins 인수는를 포함하는 값으로 설정됩니다 . 이 제어는 포드 보안 정책에 설명되지 않은 방식으로 포드 수준 보안 컨텍스트를 사용자 지정할 수 없도록합니다. 보안 컨텍스트에 대한 추가 정보는 포드 보안 정책 섹션 (# 2)을 참조하세요. SecurityContextDeny
• --disable-admission-plugins 인수가를 포함하지 않는 값으로 설정되었습니다 . 이 컨트롤은 존재하지 않는 네임 스페이스 또는 종료되도록 설정된 네임 스페이스에 개체가 생성되지 않도록하기 때문에이 컨트롤을 비활성화하지 않으려 고합니다. NamespaceLifecycle
• --audit-log-path 인수는 감사 로그를 저장할 적절한 경로로 설정됩니다. 사용 가능한 경우 Kubernetes API 서버를 포함하여 모든 Kubernetes 구성 요소에 대한 감사를 활성화하는 것은 항상 좋은 보안 관행입니다.
• - -audit-log-maxage 인수는 내부 및 외부 데이터 보존 정책을 준수하기 위해 감사 로그 파일을 저장해야하는 일 수로 설정됩니다 . 30 
• --audit-log-maxbackup 인수는로 설정 되거나 이전 로그 파일 수를 유지하기위한 규정 준수 요구 사항을 충족하는 데 도움이되는 숫자입니다. 10 
• --audit-log-maxsize 인수는 또는 규정 준수 요구 사항을 충족하는 데 도움이되는 숫자 로 설정됩니다 . 숫자 100은 100MB를 나타냅니다. 100 
• --authorization-mode 인수가 있고로 설정되지 않았습니다 . 이 설정을 사용하면 API 서버, 특히 프로덕션 클러스터에서 승인 된 요청 만 허용됩니다. AlwaysAllow
• --token-auth-file 논쟁이 없습니다. 이 인수는 존재하는 경우 몇 가지 보안 결함이있는 정적 토큰 기반 인증을 사용합니다. 대신 인증서와 같은 대체 인증 방법을 사용하십시오.
• --kubelet-certificate-authority 논쟁이 있습니다. 이 설정은 API 서버와 kubelet 사이에 연결이있을 때 man-in-the-middle 공격을 방지하는 데 도움이됩니다.
• --kubelet-client-certificate 그리고 논쟁이 있습니다. 이 구성은 API 서버가 kubelet의 HTTPS 엔드 포인트에 대해 자신을 인증하도록합니다. (기본적으로 API 서버는이 단계를 수행하지 않습니다.) --kubelet-client-key 
• --service-account-lookup 인수가 있고로 설정됩니다 . 이 설정은 API 서버가 요청에 포함 된 서비스 계정 토큰이 etcd에 있는지 확인하지 않고 인증 토큰의 유효성 만 확인하는 인스턴스를 방지하는 데 도움이됩니다. true
• --enable-admission-plugins 인수는를 포함하는 값으로 설정됩니다 . 자세한 내용은 포드 보안 정책 (# 2)에 대한 위 섹션을 참조하십시오. PodSecurityPolicy
• --service-account-key-file 인수가 있으며 서비스 계정 토큰 서명을위한 별도의 공개 / 비공개 키 쌍으로 설정됩니다. 공개 / 비공개 키 쌍을 지정하지 않으면 TLS 제공 인증서의 비공개 키를 사용하므로 서비스 계정 토큰의 키를 교체 할 수 없습니다.
• --etcd-certfile 및 인수가 그래서 etcd 서버에 API 서버를 식별 자체가 클라이언트 인증서와 키를 사용한다는 것이다. etcd는 본질적으로 민감한 개체를 저장하므로 모든 클라이언트 연결은 TLS 암호화를 사용해야합니다. --etcd-keyfile 
• --disable-admission-plugins 인수가 설정되어 있고 . 이 구성은 새 포드가 생성 될 때 동일한 네임 스페이스 내에서 기본 서비스 계정을 사용하지 않도록합니다. ServiceAccount
• --tls-cert-file 및 인수는 API 서버가 TLS를 통해에만 HTTPS 트래픽을 제공하는 것이이 같은 있습니다. --tls-private-key-file 
• --client-ca-file 인수는 Kube 클러스터 배포에 대해 TLS 및 클라이언트 인증서 인증이 구성되었는지 확인하기 위해 존재합니다.
• --etcd-cafile 인수가 존재하며 API 서버가 SSL 인증 기관 파일을 통해 etcd 서버에 대해 자신을 확인하도록 설정되어 있습니다.
• --tls-cipher-suites 강력한 암호화 암호를 사용하는 방식으로 인수가 설정됩니다.
• --authorization-mode 인수가 포함 된 값이 있습니다. 이 구성은 kubelet이 노드와 관련하여 읽을 수있는 객체를 제한합니다. Node
• --enable-admission-plugins 인수가 설정되고 값을 포함합니다 . 이 플러그인은 kubelet이 자체 Node API 객체와 노드에 연결된 Pod API 객체 만 수정할 수 있도록합니다. NodeRestriction
• --encryption-provider-config 인수는 파일 로 설정되며이 파일에는 필요한 모든 리소스가 있어야합니다. 이 설정은 etcd 키-값 저장소에 저장된 모든 REST API 개체가 저장시 암호화되도록합니다. EncryptionConfig 
• 이 암호화 공급자가 가장 강력한 것으로 간주되므로 원하는 모든 리소스에 대해 암호화 공급자가 활용 되는지 확인하십시오 . aescbc 
• --enable-admission-plugins 인수에는 클러스터의 성능 최적화를 위해 API 서버에서 허용하는 이벤트 수에 대한 제한을 설정하는 값 이 포함 됩니다. EventRateLimit 
• --feature-gates 인수가를 포함하는 값으로 설정되지 않았습니다 . 즉, 감사 및 조사 목적으로 고급 감사가 비활성화되어 있지 않은지 확인하십시오. AdvancedAuditing=false
• --request-timeout 인수가 설정되지 않았거나 적절한 값으로 설정되었습니다 (너무 짧지도 길지도 않음). 기본값은 60 초입니다.
• --authorization-mode 인수가 존재하며을 포함하는 값으로 설정됩니다 . 이 설정은 RBAC (역할 기반 액세스 제어)가 켜져 있는지 확인합니다. 단순히 켜는 것 외에도 Kubernetes RBAC를 가장 잘 사용하는 방법에 대한 다음과 같은 몇 가지 다른 권장 사항 을 따라야 합니다.  RBAC  
  • 사용자에게 클러스터-관리자 역할을 부여하지 마십시오. 환경에 대해 매우 광범위한 권한을 제공하므로 매우 드물게 사용해야합니다.
  • 역할 집계 규칙을 감사하여 올바르게 사용하고 있는지 확인하십시오.
  • 액세스 취소를 더 어렵게 만들 수 있으므로 주제에 중복 된 권한을 부여하지 마십시오.
  • 사용하지 않는 역할을 정기적으로 제거

Kubernetes의 기본 스케줄러로 kube-scheduler는 새로 생성 된 Pod가 실행되어야하는 노드를 선택합니다. 여기에서 kube-scheduler에 대해 자세히 알아볼 수 있습니다 . 

마스터 노드에서 아래 명령을 실행하십시오.

ps -ef | grep kube-scheduler

출력에서 다음을 확인하십시오.

• --profiling 인수가로 설정되어 공격 표면이 감소합니다. 프로파일 링은 병목 현상을 식별하여 성능 병목 현상이있을 때 유용 할 수 있지만 시스템에 대한 세부 정보를 드러내는 데에도 악용 될 수 있습니다. false 
• --address 인증 또는 암호화없이 스케줄러 API 서비스를 사용할 수 있으므로 스케줄러가 비 루프백 비보안 주소에 바인딩되지 않도록 인수가 127.0.0.1로 설정됩니다

마스터 노드에서 아래 명령을 실행하십시오.

ps -ef | grep kube-controller-manager

출력에서 다음을 확인하십시오.

• --terminated-pod-gc-threshold 인수는 사용 가능한 리소스가 충분하고 성능이 저하되지 않도록하는 값으로 설정됩니다.
• --profiling 인수가로 설정됩니다 . false
• --use-service-account-credentials 인수가로 설정됩니다 . 이 설정을 RBAC와 결합하면 최소 권한 설계 원칙에 따라 제어 루프가 필요한 최소 권한으로 실행됩니다. true
• --service-account-private-key-file 인수는 서비스 계정 토큰 서명에 별도의 공개 / 비공개 키 쌍이 사용되도록 설정됩니다.
• --root-ca-file 인수가 존재하고 API 서버의 제공 인증서에 대한 루트 인증서가 포함 된 인증서 파일로 설정됩니다. 그러면 포드가 연결하기 전에 API 서버의 제공 인증서를 확인할 수 있습니다.
• RotateKubeletServerCertificate 인수가 있고로 설정되며 kubelet이 API 서버에서 인증서를 가져올 때만 적용됩니다. true
• --address 인수가 127.0.0.1로 설정되어 컨트롤러 관리자 서비스가 비 루프백 비보안 주소에 바인딩되지 않습니다

API 서버 포드 사양 파일 권한을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/manifests/kube-apiserver.yaml

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

API 서버 포드 사양 파일 소유권을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/manifests/kube-apiserver.yaml

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

컨트롤러 관리자 포드 사양 파일 권한을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/manifests/kube-controller-manager.yaml

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

컨트롤러 관리자 포드 사양 파일 소유권을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/manifests/kube-controller-manager.yaml

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

스케줄러 포드 사양 파일 권한을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/manifests/kube-scheduler.yaml

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

스케줄러 포드 사양 파일 소유권을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/manifests/kube-scheduler.yaml

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

etcd 포드 사양 파일 권한을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/manifests/etcd.yaml

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 이미 논의 된 주제에 대한 알림으로 etcd는 키-값 저장소이며 REST API 개체를 포함하므로이를 보호하는 것이 가장 중요합니다. 644 

etcd 포드 사양 파일 소유권을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/manifests/etcd.yaml

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

컨테이너 네트워크 인터페이스 파일 권한을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a <path/to/cni/files>

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

컨테이너 네트워크 인터페이스 파일 소유권을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G <path/to/cni/files>

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

etcd 데이터 디렉토리 권한을 보호하십시오.

먼저 get etcd 데이터 디렉토리에 다음 명령을 실행하십시오.

ps -ef | grep etcd

이제 이전 명령에서 찾은 etcd 데이터 디렉토리를 기반으로 다음 명령을 실행하십시오.

stat -c %a /var/lib/etcd

출력에서 권한이 또는 더 제한적인지 확인하여 etcd 데이터 디렉토리가 무단 읽기 / 쓰기로부터 보호되는지 확인하십시오. 700 

etcd 데이터 디렉토리 소유권을 보호하십시오.

먼저 get etcd 데이터 디렉토리에 다음 명령을 실행하십시오.

ps -ef | grep etcd

이제 이전 명령에서 찾은 etcd 데이터 디렉토리를 기반으로 다음 명령을 실행하십시오.

stat -c %U:%G /var/lib/etcd

출력에서 소유권이 etcd 데이터 디렉토리가 무단 읽기 / 쓰기로부터 보호되는지 확인합니다. etcd:etcd 

admins.conf 파일 권한을 보호하십시오.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/admin.conf

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

admins.conf 파일 소유권을 보호하십시오.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/admin.conf

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

scheduler.conf 파일 권한을 보호하십시오.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/scheduler.conf

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

scheduler.conf 파일 소유권을 보호하십시오.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/scheduler.conf

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

controller-manager.conf 파일 권한을 보호하십시오.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/controller-manager.conf

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

controller-manager.conf 파일 소유권을 보호하십시오.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/controller-manager.conf

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

Kubernetes PKI 디렉터리 및 파일 소유권을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

ls -laR /etc/kubernetes/pki/

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

Kubernetes PKI 디렉터리 및 파일 권한을 보호합니다.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

ls -laR /etc/kubernetes/pki/*.crt

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

Kubernetes PKI 키 파일 권한을 보호하십시오.

마스터 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정).

ls -laR /etc/kubernetes/pki/*.key

출력 에서 파일의 무결성을 유지 하기위한 권한이 있는지 확인 하십시오. 600 

이전 섹션에서 언급했듯이 etcd ( CNCF 프로젝트 )는 Kubernetes와 같은 분산 시스템에서 데이터 액세스를 위해 사용 하는 키-값 저장소 ( CNCF 프로젝트 )입니다. etcd는 Kubernetes의 진실 소스로 간주되며 필요에 따라 etcd에서 데이터를 읽고 쓸 수 있습니다. etcd 및 서버에 대한 통신을 안전하게 구성하는 것이 가장 중요합니다.  

etcd 서버 노드에서 다음 명령을 실행하십시오.

ps -ef | grep etcd

출력에서 다음을 확인하십시오.

• --cert-file 그리고 클라이언트 연결 (전송 암호화에)에만 TLS를 통해 제공되도록하기 위해 필요에 따라 인수가 설정됩니다. --key-file 
• --client-cert-auth 인수는 클라이언트의 모든 액세스 시도에 유효한 클라이언트 인증서가 포함되어 있는지 확인합니다. true 
• --auto-tls 인수가 존재하고 존재하지 않거나 전혀 존재하지 않으므로 클라이언트가 TLS에 자체 서명 된 인증서를 사용하는 것을 금지합니다. true
• 단일 etcd 서버 대신 etcd 클러스터를 사용하는 경우 etcd 클러스터 내에서 etcd 피어 연결이 암호화되도록 및 인수가 적절하게 설정되었는지 확인하십시오. 또한 이 설정은 인증 된 etcd 피어 만 etcd 클러스터에 액세스 할 수 있도록 보장하므로 인수가로 설정되어 있는지 확인하십시오 . 마지막으로 인수가 있으면로 설정되지 않았 는지 확인하십시오 . --peer-cert-file  --peer-key-file  --peer-client-cert-auth  true --peer-auto-tls  true
• 모범 사례로 Kubernetes와 동일한 인증 기관을 etcd에 사용하지 마십시오. API 서버 에서 참조하는 파일 이 etcd 에서 사용하는 파일과 다른지 확인하여 이러한 분리를 보장 할 수 있습니다 . --client-ca-file  --trusted-ca-file

kubelet는 각 노드에서 실행되는 주 "노드 에이전트"입니다. 작년 에이 Medium 기사에서 설명 했듯이 kubelet을 잘못 구성하면 여러 보안 위험에 노출 될 수 있습니다 . 실행중인 kubelet 실행 파일의 인수를 사용하거나 kubelet 구성 파일을 사용하여 kubelet의 구성을 설정할 수 있습니다.    

kubelet 구성 파일을 찾으려면 다음 명령을 실행하십시오.

ps -ef | grep kubelet | grep config

를 찾으면 kubelet 구성 파일의 위치를 ​​알 수 있습니다. --config argument

그런 다음 각 노드에서 다음 명령을 실행합니다.

ps -ef | grep kubelet

출력에서 다음을 확인하십시오.

• --anonymous-auth 인수는 입니다. 이전에 참조 된 kubelet 기사에서 악용 된 잘못된 구성 중 하나는 kubelet 서버에서 익명 (및 인증되지 않은) 요청을 처리 할 수있는 구성이었습니다. false
• --authorization-mode 인수는 마치 거기있는 것처럼 보여줍니다 . 이 없을 경우, 반드시 거기로 지정된 kubelet 설정 파일의 확인 및 해당 파일이 설정 한 이외의 뭔가 . AlwaysAllow  --config  authorization: mode  AlwaysAllow
• --client-ca-file 인수가 있고 클라이언트 인증 기관 파일의 위치로 설정됩니다. 여기에없는 경우에서 지정한 kubelet 구성 파일이 있고 해당 파일이 클라이언트 인증 기관 파일의 위치로 설정 되었는지 확인 합니다. --config  authentication: x509: clientCAFile 
• --read-only-port 인수가 있고로 설정됩니다 . 거기가 아니라면, 반드시 거기로 지정된 kubelet 설정 파일의 확인 및 설정되어 거기가 있다면. 0 --config readOnlyPort  0 
• --protect-kernel-defaults 로 표시됩니다 . 거기가 아니라면, 반드시 거기로 지정된 kubelet 설정 파일의 확인 , 해당 파일이 설정 한 대로 . true --config protectKernelDefaults  true
• --hostname-override 인수가 없으면 kubelet과 API 서버 간의 TLS 설정이 중단되지 않도록합니다.
• --event-qps 인수가 있고로 설정됩니다 . 거기가 아니라면, 확인에 의해 지정된 kubelet 설정 파일에있을 수 있도록 하고 쇼 등 . 0 --config  eventRecordQPS  0
• --tls-cert-file 및 인수를 적절하게 설정하거나 의해 지정된 kubelet의 설정이되어 적절한 설정을 포함 하고 . 이 구성은 모든 연결이 kubelet에서 TLS를 통해 발생하도록합니다. --tls-private-key-file  --config  tlsCertFile  tlsPrivateKeyFile
• RotateKubeletServerCertificate 및 로 설정 하여 kubelets는 API 서버에서 자신의 인증서 표시를 얻는 경우에, 그리고 확인하십시오 kubelet 사용하는 경우에만 강력한 암호화 암호를 확인합니다. --rotate-certificates  true 

kubelet 서비스 파일 권한을 보호하십시오.

각 작업자 노드에서 다음 명령을 실행하십시오 (시스템에서 파일 위치 지정).

stat -c %a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

kubelet.conf 파일 권한을 보호하십시오.

각 작업자 노드에서 다음 명령을 실행하십시오 (시스템에서 파일 위치 지정).

stat -c %a /etc/kubernetes/kubelet.conf

출력에서 권한이 파일의 무결성을 유지하기 위해 제한적이거나 더 제한적 인지 확인 하십시오. 644 

kubelet.conf 파일 소유권을 보호하십시오.

각 작업자 노드에서 다음 명령을 실행하십시오 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/kubernetes/kubelet.conf

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

kublete 서비스 파일 소유권을 보호하십시오.

각 작업자 노드에서 다음 명령을 실행하십시오 (시스템에서 파일 위치 지정).

stat -c %U:%G /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

출력 에서 파일의 무결성을 유지 하기 위해 소유권이 설정되었는지 확인 하십시오. root:root 

프록시 kubeconfig 파일 권한을 보호하십시오.

다음 명령을 실행하여 먼저 사용중인 kubeconfig 파일을 찾습니다.

ps -ef | grep kube-proxy

에서 kube-proxy 파일 위치 (실행중인 경우)를 가져온 다음 각 작업자 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정). --kubeconfig

stat -c %a <proxy kubeconfig file>

출력 에서 파일의 무결성을 유지하기 위해 사용 권한이 또는 더 제한적 인지 확인 합니다. 644 

프록시 kubeconfig 파일 소유권을 보호하십시오.

다음 명령을 먼저 실행하여 사용중인 kubeconfig 파일을 찾으십시오.

ps -ef | grep kube-proxy

에서 kube-proxy 파일 위치 (실행중인 경우)를 가져온 후 각 작업자 노드에서 다음 명령을 실행합니다 (시스템에서 파일 위치 지정). --kubeconfig

stat -c %U:%G <proxy kubeconfig file>

출력에서 소유권이 파일의 무결성을 유지하도록 설정되어 있는지 확인하십시오 . root:root 

인증 기관 파일 권한을 보호하십시오.

먼저 다음 명령을 실행하십시오.

ps -ef | grep kubelet

인수로 식별되는 파일 이름을 찾으십시오 . 그런 다음 이전 파일 이름을 지정하여 다음 명령을 실행합니다. --client-ca-file 

stat -c %a <filename>

출력 에서 파일의 무결성을 유지하기 위해 사용 권한이 또는 더 제한적 인지 확인 합니다. 644 

클라이언트 인증 기관 파일 소유권을 보호합니다.

먼저 다음 명령을 실행하십시오.

ps -ef | grep kubelet

- -client-ca-file 인수로 식별되는 파일 이름을 찾습니다 . 그런 다음 이전 파일 이름을 지정하여 다음 명령을 실행합니다.

stat -c %U:%G <filename>

출력에서 소유권이 root:root 파일의 무결성을 유지하도록 설정되어 있는지 확인하십시오 .

kubelet 구성 파일 권한을 보호하십시오.

먼저 다음 명령을 사용하여 kubelet 구성 파일을 찾습니다.

ps -ef | grep kubelet | grep config

출력에서 구성 파일이있는 경우 해당 위치를 볼 수 있습니다. /var/lib/kubelet/configuration.yaml과 유사합니다.

파일 위치 (이전 예제의 파일 위치 사용)를 사용하여 다음 명령을 실행하여 파일의 권한을 식별합니다.

stat -c %a /var/lib/kubelet/configuration.yaml

출력 에서 파일의 무결성을 보장하기 위해 권한이 또는 더 제한적으로 설정되어 있는지 확인하십시오 . 644 

kubelet 구성 파일 소유권을 보호하십시오.

다음 명령을 실행하십시오.

ps -ef | grep kubelet | grep config

출력에서 구성 파일이있는 경우 해당 위치를 볼 수 있습니다. /var/lib/kubelet/configuration.yaml과 유사합니다.

파일 위치 (이전 예제의 파일 위치 사용)를 사용하여 다음 명령을 실행하여 파일의 권한을 식별합니다.

stat -c %U:%G /var/lib/kubelet/configuration.yaml

출력에서 소유권이 파일의 무결성을 유지하도록 설정되어 있는지 확인하십시오 . root:root 

이 클라우드 네이티브 스택은 우리가 만든 가장 안전한 애플리케이션을 구축 할 수있는 강력한 기능을 제공합니다. 모든 노브와 다이얼이 올바르게 설정되었는지 확인하기 만하면됩니다. 이러한 구성, 코드 예제 및 자세한 권장 사항을 활용하여 가장 일반적인 Kubernetes 구성 오류와 관련된 보안 위험을 피하십시오.