이 문서에서는 베어메탈용 Anthos 클러스터의 보안을 강화하는 방법을 설명합니다.
SELinux를 사용하여 컨테이너 보호
Red Hat Enterprise Linux(RHEL) 및 CentOS에 지원되는 SELinux를 사용 설정하여 컨테이너를 보호할 수 있습니다. 호스트 머신이 RHEL 또는 CentOS를 실행 중이고 클러스터에서 SELinux를 사용 설정하려면 모든 호스트 머신에서 SELinux를 사용 설정해야 합니다. 자세한 내용은 SELinux를 사용하여 컨테이너 보호를 참조하세요.
root 사용자로 컨테이너 실행 안함
기본적으로 컨테이너의 프로세스는 root로 실행됩니다. 이렇게 하면 컨테이너에서 한 프로세스에 문제가 발생할 경우 이 프로세스가 호스트 머신에서 루트로 실행되기 때문에 보안 문제가 발생할 수 있습니다. 따라서 모든 워크로드를 비루트 사용자로 실행하는 것이 좋습니다.
다음 섹션에서는 비루트 사용자로 컨테이너를 실행하는 두 가지 방법을 설명합니다.
방법 #1: Dockerfile에 USER 명령 추가
이 방법은 Dockerfile을 사용하여 컨테이너가 root 사용자로 실행되지 않도록 합니다. Dockerfile에서는 컨테이너 내에서 프로세스를 실행할 사용자를 지정할 수 있습니다. 다음 Dockerfile 스니펫은 이 방법을 보여줍니다.
....
#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot
#Run Container as nonroot
USER nonroot
....
이 예시에서 Linux 명령어 useradd -u는 컨테이너 내에 nonroot라는 사용자를 만듭니다. 이 사용자의 사용자 ID(UID)는 8877입니다.
Dockerfile의 다음 줄은 USER nonroot 명령어를 실행합니다. 이 명령어는 이미지의 이 시점에서 명령어가 nonroot 사용자로 실행되도록 지정합니다.
컨테이너 프로세스가 nonroot에 대해 올바르게 실행될 수 있도록 UID 8877에 권한을 부여합니다.
방법 #2: Kubernets 매니페스트 파일에 securityContext 필드 추가
이 방법은 Kubernetes 매니페스트 파일을 사용해서 컨테이너가 root 사용자로 실행되지 않도록 합니다. 포드에 대해 보안 설정이 지정되고 이러한 보안 설정은 다시 포드 내에 있는 모든 컨테이너에 적용됩니다.
다음 예시에서는 지정된 포드에 대한 매니페스트 파일의 일부를 보여줍니다.
apiVersion: v1
kind: Pod
metadata:
name: name-of-pod
spec:
securityContext:
runAsUser: 8877
runAsGroup: 8877
....
runAsUser 필드는 포드에 있는 모든 컨테이너에 대해 모든 프로세스가 사용자 ID 8877로 실행되도록 지정합니다. runAsGroup 필드는 이러한 프로세스의 기본 그룹 ID(GID)를 8877로 지정합니다. 컨테이너 프로세스가 올바르게 실행될 수 있도록 UID 8877에 필요 충분한 권한을 부여하는 것도 잊지 않아야 합니다.
그러면 컨테이너 내부의 프로세스가 루트보다 적은 권한을 갖는 UID 8877로 실행됩니다.
Anthos clusters on bare metal의 시스템 컨테이너에는 2000-4999 범위의 UID 및 GID가 사용됩니다. 따라서 사용자 워크로드에 권한을 할당할 때는 이 예약된 범위에 포함되지 않는 UID 및 GID를 사용하세요.
워크로드가 자체 수정하는 기능을 제한
특정 Kubernetes 워크로드, 특히 시스템 워크로드에는 자체 수정 권한이 있습니다. 예를 들어 일부 워크로드는 수직적으로 자동 확장됩니다. 이렇게 하면 노드를 이미 손상시킨 공격자가 클러스터에서 추가로 에스컬레이션할 수 있습니다. 예를 들어 공격자는 노드에 있는 워크로드가 동일 네임스페이스에 존재하는 권한이 높은 서비스 계정으로 실행되도록 변경할 수 있습니다.
워크로드에 자체 수정 권한이 애초에 부여되지 않는 것이 좋습니다. 자체 수정이 필요한 경우 몇 가지 유용한 보안 정책을 제공하는 오픈소스 Gatekeeper 라이브러리에서 NoUpdateServiceAccount와 같은 Gatekeeper 또는 Policy Controller 제약조건을 적용하여 권한을 제한할 수 있습니다.
정책을 배포할 때는 일반적으로 클러스터 수명 주기를 관리하는 컨트롤러가 정책을 우회할 수 있도록 해야 합니다. 이는 컨트롤러가 클러스터 업그레이드 적용과 같이 클러스터를 변경할 수 있도록 하기 위해 필요합니다. 예를 들어 Anthos clusters on bare metal에 NoUpdateServiceAccount 정책을 배포하는 경우 Constraint에 다음 매개변수를 설정해야 합니다.
parameters:
allowedGroups:
- system:masters
allowedUsers: []
유지보수
클러스터가 작동되고 실행된 다음에는 보안 유지를 위해 보안 게시판을 모니터링하고 클러스터를 업그레이드해야 합니다.
보안 게시판 모니터링
Anthos 보안팀은 심각도가 높거나 매우 높은 취약점에 대한 보안 게시판 게시합니다.
이 게시판은 일반적인 Google Cloud 취약점 번호 지정 스킴을 따르며 기본 Google Cloud 게시판 페이지와 베어메탈용 Anthos 클러스터 출시 노트에서 연결됩니다. 다음 XML 피드를 사용해서 베어메탈용 Anthos 클러스터 및 관련 제품의 보안 게시판을 구독하세요.
https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
심각도가 높거나 매우 높은 취약점을 해결하기 위해 고객의 조치가 필요한 경우 Google에서는 이메일로 고객에게 연락합니다. 또한 지원 채널의 지원 계약을 통해 고객에게 연락할 수도 있습니다.
Google이 GKE 및 Anthos에 대해 보안 취약점 및 패치를 관리하는 방법은 보안 패치 적용을 참조하세요.
클러스터 업그레이드
Kubernetes에는 새로운 보안 기능과 보안 패치가 정기적으로 제공됩니다. 베어메탈용 Anthos 클러스터 출시 버전에는 클러스터에 영향을 줄 수 있는 보안 취약점을 해결하는 Kubernetes 보안 향상 기능이 포함되어 있습니다.
사용자는 Anthos 클러스터를 최신 상태로 유지해야 합니다. 각 출시 버전의 출시 노트를 검토합니다. Anthos 클러스터에 대한 보안 위험을 최소화하기 위해 매달 새로운 패치 출시 버전 업데이트를 수행하고 부 버전 업데이트는 최소 3개월 주기로 계획합니다.
클러스터 업그레이드의 여러 장점 중 하나는 클러스터의 kubeconfig 파일을 자동으로 새로 고친다는 점입니다. kubeconfig 파일은 사용자를 클러스터에 인증합니다. kubeconfig 파일은 bmctl로 클러스터를 만들 때 클러스터 디렉터리에 추가됩니다. 기본 이름과 경로는 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig입니다.
클러스터를 업그레이드하면 클러스터의 kubeconfig 파일이 자동으로 갱신됩니다. 그렇지 않으면 kubeconfig 파일은 생성된 지 1년 후에 만료됩니다.
클러스터 업그레이드 방법에 대한 자세한 내용은 클러스터 업그레이드를 참조하세요.