튜토리얼: GKE Enterprise 보안

GKE Enterprise는 보안 문제에 대한 심층 방어를 제공하기 위해 개별적으로 작동하거나 함께 작동하도록 모든 수준에서 기본 제공되는 보안 기능과 함께 안전한 서비스를 구축하고 제공하기 위한 일관된 플랫폼을 제공합니다. 이 튜토리얼에서는 Google Cloud에서 Anthos 샘플 배포를 사용하여 GKE Enterprise의 강력한 보안 기능을 설명합니다. Anthos 샘플 배포는 GKE 클러스터, 서비스 메시, 여러 마이크로서비스를 포함한 Bank of GKE Enterprise 애플리케이션과 함께 실제 GKE Enterprise 실무 환경을 배포합니다.

목표

이 튜토리얼에서는 다음 작업을 통해 GKE Enterprise의 보안 기능을 소개합니다.

엔드 투 엔드 보안 통신을 보장하기 위해 구성 동기화를 사용하여 하여 서비스 메시에 상호 TLS(mTLS)를 적용합니다.
권한이 있는 컨테이너가 포함된 포드가 실수로 정책 컨트롤러를 사용하여 배포되지 않도록 보안 가드레일을 설정합니다.

비용

Bank of Anthos 애플리케이션을 배포하면 이미 구독을 구입한 경우가 아니라면 당사의 가격 책정 페이지에 표시된 대로 Google Cloud에서 GKE Enterprise에 대한 사용한 만큼만 지불 비용이 발생합니다.

Compute Engine VM 및 부하 분산기 요금과 같이 Bank of Anthos 애플리케이션을 실행하는 동안 발생하는 기타 Google Cloud 비용도 사용자가 부담합니다.

추가 요금이 청구되지 않도록 튜토리얼을 완료하거나 배포를 살펴본 후 삭제하는 것이 좋습니다.

시작하기 전에

이 튜토리얼은 Explore Anthos 튜토리얼의 후속 튜토리얼입니다. 이 가이드를 시작하기 전에 해당 페이지의 안내를 따라 프로젝트를 설정하고 Anthos 샘플 배포를 설치하세요.

Cloud Shell 환경 설정

이 가이드에서는 Cloud Shell 명령줄 및 편집기를 사용하여 클러스터 구성을 변경합니다.

Anthos 샘플 배포는 가이드의 셸 환경을 초기화하기 위해 다음을 수행하는 스크립트를 제공합니다.

대화형으로 작업하고 배포 변경사항을 확인하기 위해 누락된 명령줄 도구를 설치합니다.
anthos-sample-cluster1의 Kubernetes 컨텍스트를 설정합니다.
구성 동기화가 구성 변경사항을 클러스터와 동기화하기 위해 사용하는 저장소를 클론합니다. 커밋하고 업스트림 저장소로 푸시한 변경사항은 구성 동기화에 의해 인프라에 동기화됩니다. 이는 인프라에 변경사항을 적용하는 데 권장되는 방법입니다.

환경을 설정하려면 다음 안내를 따르세요.

활성 Cloud Shell 세션이 있는지 확인합니다. 튜토리얼 프로젝트의 Google Cloud 콘솔에서 Cloud Shell 활성화 를 클릭하여 Cloud Shell을 실행할 수 있습니다.
작업할 디렉터리를 만듭니다.
```
mkdir tutorial
cd tutorial
```

초기화 스크립트를 다운로드합니다.

curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env

초기화 스크립트를 Cloud Shell 환경으로 가져옵니다.

source init-anthos-sample-deployment.env

출력:

/google/google-cloud-sdk/bin/gcloud
/google/google-cloud-sdk/bin/kubectl
Your active configuration is: [cloudshell-13605]
export PROJECT as anthos-launch-demo-1
export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config
Fetching cluster endpoint and auth data.
kubeconfig entry generated for anthos-sample-cluster1.
Copying gs://config-management-release/released/latest/linux_amd64/nomos...
\ [1 files][ 40.9 MiB/ 40.9 MiB]
Operation completed over 1 objects/40.9 MiB.
Installed nomos into ~/bin.
Cloned ACM config repo: ./anthos-sample-deployment-config-repo

디렉터리를 구성 저장소로 변경하고 이 가이드의 나머지 부분에 대한 작업 디렉터리로 사용합니다.
```
cd anthos-sample-deployment-config-repo
```

서비스 메시에 mTLS 적용

글로벌 확장을 예상하고 CIO는 리전별 데이터 개인정보 보호 및 암호화 법률에 따라 민감한 정보를 보호하기 위해 모든 사용자 데이터를 전송 중에 암호화하도록 지시했습니다.

현재 모든 트래픽이 안전한지 확인합니다.

Anthos 샘플 배포가 배포된 프로젝트의 Cloud Service Mesh 페이지로 이동합니다.

Cloud Service Mesh 페이지로 이동
서비스 목록에서 transactionhistory를 클릭합니다. GKE Enterprise 탐색에서 확인한 것처럼 서비스 세부정보 페이지에는 이 서비스에 사용할 수 있는 모든 원격 분석이 표시됩니다.
transactionhistory 페이지의 탐색 메뉴에서 연결된 서비스를 선택합니다. 여기에서 서비스의 인바운드 연결 및 아웃바운드 연결을 모두 확인할 수 있습니다. 잠금 해제된 자물쇠 아이콘은 일부 트래픽이 상호 TLS(mTLS)를 사용하지 않는 이 포트에서 관찰되었음을 나타냅니다.

mTLS는 트래픽이 두 서비스 간에 양방향으로 안전하고 신뢰할 수 있도록 보장하는 보안 프로토콜입니다. 각 서비스는 인증된 서비스의 암호화된 트래픽만 허용합니다. 이와 같이 Cloud Service Mesh는 메시에 암호화되지 않은 트래픽이 있음을 명확하게 보여줍니다. Cloud Service Mesh에는 암호화되지 않은 트래픽에 일반 텍스트와 mTLS가 혼합되어 있는지(주황색) 또는 일반 텍스트만 있는지(빨간색) 여부를 나타내는 다른 색상이 사용됩니다.

GKE Enterprise에서는 몇 단계만 더 거치면 규정을 준수할 수 있습니다. 소스 코드 수준에서 변경하고 이 상황에 맞게 애플리케이션을 다시 빌드하고 재배포하는 대신 구성 동기화를 사용해 중앙 Git 저장소에서 새 구성을 자동으로 배포하여 구성을 통해 새 암호화 정책을 선언적으로 적용할 수 있습니다.

이 섹션에서는 다음 작업을 수행합니다.

Git 저장소에서 정책 구성을 조정하여 서비스가 mTLS를 통해 암호화된 통신을 사용하도록 합니다.
구성 동기화를 사용하여 저장소에서 정책 변경사항을 자동으로 선택하고 Cloud Service Mesh 정책을 조정합니다.
저장소와 동기화되도록 구성된 클러스터에서 정책이 변경되었는지 확인합니다.

구성 동기화 설정 확인

nomos 명령어는 Config Management Operator와 상호작용하고 로컬 머신 또는 Cloud Shell에서 다른 유용한 구성 동기화 작업을 수행할 수 있는 명령줄 도구입니다. 구성 동기화가 클러스터에 올바르게 설치 및 구성되었는지 확인하려면 nomos status를 실행합니다.
```
nomos status
```
출력:
```
Connecting to clusters...
Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
-------   -------                  -----------  -----------------   -----------   ---------------
*         anthos-sample-cluster1   SYNCED       abef0b01            master        Healthy
```
구성 동기화가 클러스터를 구성 저장소의 마스터 브랜치와 동기화하도록 구성되어 있는지 확인합니다. 첫 번째 열의 별표는 현재 컨텍스트가 anthos-sample-cluster1로 설정되어 있음을 나타냅니다. 표시되지 않는 경우 현재 컨텍스트를 anthos-sample-cluster1로 전환합니다.
```
kubectl config use-context anthos-sample-cluster1
```
출력:
```
Switched to context "anthos-sample-cluster1".
```

master 분기에 있는지 확인합니다.

git checkout master

출력:

Already on 'master'
Your branch is up to date with 'origin/master'.

업스트림 구성 저장소를 확인합니다.

git remote -v

출력:

origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch)
origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)

아직 anthos-sample-deployment-config-repo 디렉터리에 있는지 확인하고 다음 명령어를 실행하여 git 설정을 확인합니다. 이 도우미 함수는 초기화 스크립트에 의해 해당 환경에 제공되며, git config 명령어를 실행하여 git 구성의 기존 user.email 및 user.name 값을 확인합니다. 이러한 값이 구성되지 않았으면 이 함수가 현재 활성 상태의 Google Cloud 계정에 따라 저장소 수준에서 기본값을 설정합니다.
```
init_git
```
결과(예시):
```
Configured local git user.email to user@example.com
Configured local git user.name to user
```

이제 저장소에 정책 변경사항을 커밋할 수 있습니다. 이러한 커밋을 업스트림 저장소(원본)로 푸시하면 구성 동기화는 관리하도록 구성한 클러스터에 이러한 변경사항을 적용합니다.

모든 서비스 트래픽을 암호화하도록 정책 업데이트

Cloud Service Mesh 구성은 YAML 파일을 사용하여 선언적으로 지정됩니다. 모든 서비스 트래픽을 암호화하려면 서비스에서 허용할 수 있는 트래픽 유형을 지정하는 YAML과 서비스에서 특정 대상으로 전송하는 트래픽 유형을 지정하는 YAML을 모두 수정해야 합니다.

가장 먼저 살펴봐야 할 YAML 파일은 namespaces/istio-system/peer-authentication.yaml로, 이는 메시의 모든 서비스가 기본적으로 허용하는 트래픽 유형을 지정하는 메시 수준 인증 정책입니다.
```
cat namespaces/istio-system/peer-authentication.yaml
```
출력:
```
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: PERMISSIVE
```
보시다시피 PeerAuthentication mTLS 모드는 PERMISSIVE입니다. 즉, 서비스에서 일반 텍스트 HTTP 트래픽과 mTLS 트래픽을 모두 허용합니다.

mTLS 모드를 STRICT로 설정하여 서비스 간 암호화된 통신만 허용하도록 namespaces/istio-system/peer-authentication.yaml을 수정합니다.

cat <<EOF> namespaces/istio-system/peer-authentication.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

그런 다음 namespaces/istio-system/destination-rule.yaml에서 대상 규칙을 확인합니다. 이는 트래픽 암호화 여부 등 지정된 대상으로 트래픽을 전송하는 규칙을 지정합니다. TLSmode는 DISABLE입니다. 즉, 트래픽은 일치하는 모든 호스트에 일반 텍스트로 전송됩니다.

cat namespaces/istio-system/destination-rule.yaml

출력:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  annotations:
    meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
  name: default
  namespace: istio-system
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: DISABLE

TLSmode ISTIO_MUTUAL을 사용하여 Istio가 클러스터의 일치하는 모든 호스트에 TLS를 사용 설정하는 트래픽 정책을 설정하도록 namespaces/istio-system/destination-rule.yaml를 수정합니다.

cat <<EOF> namespaces/istio-system/destination-rule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  annotations:
    meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
  name: default
  namespace: istio-system
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

저장소에 변경사항 푸시

구성 변경사항을 푸시할 준비가 거의 끝났습니다. 하지만 마지막으로 업데이트를 커밋하기 전에 몇 가지 사항을 확인하는 것이 좋습니다.

nomos vet를 실행하여 구성이 유효한지 확인합니다.
```
nomos vet
```
결과가 없으면 검증 오류가 없음을 나타냅니다.
변경사항을 푸시하면 구성 동기화가 이를 가져와서 시스템에 적용합니다. 예기치 않은 결과가 발생하지 않도록 구성의 현재 라이브 상태가 수정한 이후에 변경되지 않았는지 확인하는 것이 좋습니다. kubectl을 사용하여 클러스터에 mTLS가 사용 중지되었다는 점이 destinationrule에 반영되어 있는지 확인합니다.
```
kubectl get destinationrule default -n istio-system -o yaml
```
출력:
```
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
...
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: DISABLE
```
이제 이러한 변경사항을 커밋하여 업스트림 저장소에 푸시합니다. 다음 명령어는 init 스크립트에서 환경에 가져온 watchmtls라는 도우미 함수를 사용합니다. 이 도우미 함수는 이전에 시도한 nomos status 명령어와 kubectl 명령어의 조합을 실행합니다. Ctrl+C를 눌러 종료할 때까지 클러스터에서 변경사항을 감시합니다. 클러스터에 변경사항이 적용되고 동기화될 때까지 디스플레이를 모니터링합니다.
```
git commit -am "enable mtls"
git push origin master && watchmtls
```
또한 GKE Enterprise의 Cloud Service Mesh 페이지에 반영된 변경사항을 확인할 수도 있습니다.

Cloud Service Mesh 페이지로 이동

빨간색 잠금 해제 자물쇠 아이콘이 변경된 것을 알 수 있습니다. 기본적으로 지난 1시간 동안 mTLS와 일반 텍스트가 혼합된 상태로 표시되므로 자물쇠 아이콘은 녹색(완전히 암호화된 트래픽)이 아닌 주황색(혼합 트래픽)으로 표시됩니다. 한 시간 후에 다시 확인하는 경우 모든 서비스 트래픽이 성공적으로 암호화되었음을 나타내는 녹색 자물쇠가 표시됩니다.

정책 컨트롤러를 사용하여 가드레일 설정

보안팀은 권한이 있는 컨테이너(루트 액세스 권한이 있는 컨테이너)를 사용하여 pod를 실행할 때 발생할 수 있는 잠재적인 루트 공격에 대해 우려하고 있습니다. 현재 구성은 권한이 있는 컨테이너를 배포하지 않지만 성능을 저하시키거나 심지어 고객 데이터를 손상시킬 수 있는 위협 벡터를 가능한 많이 보호할 수 있습니다.

팀의 근면성을 감안하더라도 지속적 배포 프로세스를 통한 향후 구성 업데이트에서 의도하지 않게 루트 공격에 취약해질 수 있는 위험이 있습니다. 이 위험으로부터 보호하기 위해 보안 가드레일을 설정하기로 결정합니다.

가드레일 시행

가드레일은 사용자 환경을 보호하는 정책을 시행하기 위한 자동 관리 제어 기능입니다. 정책 컨트롤러에는 기본 Kubernetes 객체가 적용되지 않는 커스텀 규칙을 정의하고 적용하는 지원이 포함됩니다. 정책 컨트롤러는 조직의 고유한 보안, 규제 규정 준수, 거버넌스 요구사항에 따라 적용되는 가드레일을 확인, 감사, 시행합니다.

정책 컨트롤러 사용

정책 컨트롤러는 클러스터의 리소스가 생성, 업데이트, 삭제될 때마다 정책을 시행하는 데 사용되는 게이트키퍼라는 오픈소스 정책 엔진을 기반으로 합니다. 이러한 정책은 정책 컨트롤러 템플릿 라이브러리 또는 다른 게이트키퍼 제약조건 템플릿의 제약조건을 사용하여 정의됩니다.

Google Cloud의 Anthos 샘플 배포에는 이미 정책 컨트롤러가 설치되어 있으며 정책 컨트롤러 템플릿 라이브러리가 사용 설정되어 있습니다. 라이브러리의 권한이 있는 컨테이너에 대한 기존 제약조건을 사용하여 가드레일을 구현할 때 이를 활용할 수 있습니다.

권한이 있는 컨테이너에 대한 정책 제약조건 적용

보안팀의 문제를 해결하려면 K8sPSPPrivilegedContainer 제약조건을 적용합니다. 이 제약조건은 pod가 권한이 있는 컨테이너에서 실행되지 못하도록 합니다.

Cloud Shell 터미널을 사용하여 다음과 같이 라이브러리 제약조건의 텍스트로 새 constraint.yaml 파일을 만듭니다.

cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
EOF

nomos vet를 사용하여 구성을 적용하기 전에 업데이트된 구성이 유효한지 확인합니다.
```
nomos vet
```
오류가 없으면 명령어가 자동으로 반환됩니다.

변경사항을 커밋하고 푸시하여 정책을 적용합니다. nomos status를 watch 명령어와 함께 사용하면 변경사항이 클러스터에 적용되었는지 확인할 수 있습니다. 완료되면 Ctrl+C 키를 눌러 watch 명령어를 종료합니다.

git add .
git commit -m "add policy constraint for privileged containers"
git push && watch nomos status

출력:

Connecting to clusters...
Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
-------   -------                  -----------  -----------------   -----------   ---------------
*         anthos-sample-cluster1   SYNCED       f2898e92            master        Healthy

정책 테스트

정책을 적용한 후 권한이 있는 컨테이너에서 pod 실행을 시도하여 테스트할 수 있습니다.

Cloud Shell 터미널에서 다음 명령어를 사용하여 가이드 디렉터리 nginx-privileged.yaml에 이 예시 사양의 콘텐츠가 포함된 새 파일을 만듭니다.

cat <<EOF> ~/tutorial/nginx-privileged.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged-disallowed
  labels:
    app: nginx-privileged
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true
EOF

kubectl apply를 사용하여 pod 실행을 시도합니다.

kubectl apply -f ~/tutorial/nginx-privileged.yaml

출력:

Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security
Context: {"privileged": true}

이 오류는 Kubernetes 환경을 모니터링하는 게이트키퍼 허용 컨트롤러가 새 정책을 적용했음을 나타냅니다. 포드 사양에 권한이 있는 컨테이너가 있으므로 포드 실행이 차단되었습니다.

정책 컨트롤러를 사용하여 가드레일을 설정하는 데 적용할 수 있는 버전 제어 정책의 개념은 클러스터 거버넌스를 표준화, 통합, 중앙화하여 배포 후 환경의 활성 모니터링을 통해 정책을 적용하므로 강력합니다.

게이트키퍼 저장소에서 사용자 환경에 대한 가드레일로 사용할 수 있는 다양한 유형의 정책을 찾을 수 있습니다.

배포 더 살펴보기

이 튜토리얼에서는 일부 GKE Enterprise 보안 기능을 사용하는 방법을 다루고 있지만 GKE Enterprise는 그 밖에도 많은 정보와 작업들을 배포에 제공합니다. 다음 섹션의 삭제 안내를 따르기 전에 다른 튜토리얼을 자유롭게 사용해 보거나 직접 Google Cloud의 Anthos 샘플 배포를 계속 살펴보세요.

삭제

Bank of Anthos 애플리케이션을 모두 살펴본 후에는 Google Cloud에서 만든 리소스가 할당량을 차지하지 않고 이후에 요금이 청구되지 않도록 리소스를 삭제할 수 있습니다.

옵션 1. 프로젝트를 삭제할 수 있습니다. 하지만 프로젝트를 유지하려는 경우에는 옵션 2를 사용하여 배포를 삭제하면 됩니다.
옵션 2. 현재 프로젝트를 유지하려면 terraform destroy를 사용해서 샘플 애플리케이션과 클러스터를 삭제할 수 있습니다.

프로젝트 삭제(옵션 1)

청구되지 않도록 하는 가장 쉬운 방법은 튜토리얼에서 만든 프로젝트를 삭제하는 것입니다.

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

배포 삭제(옵션 2)

이 방법을 사용하면 Bank of Anthos 애플리케이션과 클러스터가 삭제되지만 프로젝트는 삭제되지 않습니다. Cloud Shell에서 다음 명령어를 실행합니다.

설치 스크립트를 호스팅하는 디렉터리로 이동합니다.
```
cd bank-of-anthos/iac/tf-anthos-gke
```
샘플 및 클러스터를 삭제합니다.
```
terraform destroy
```
메시지가 표시되면 프로젝트 ID를 입력합니다.

다시 배포하려면 시작하기 전에 섹션의 설명대로 모든 요구사항이 충족되었는지 확인합니다.

다음 단계

GKE Enterprise 문서에서 다양한 기능을 살펴볼 수 있습니다.

튜토리얼 더보기

GKE Enterprise를 사용한 서비스 관리에서 Anthos 샘플 배포를 사용한 서비스 관리에 대해 알아봅니다.
Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터를 살펴봅니다.

GKE Enterprise 자세히 알아보기

기술 개요에서 GKE Enterprise에 대해 자세히 알아보기
설정 가이드에서 실제 프로덕션 환경에서 GKE Enterprise 설정 방법 알아보기
Cloud Service Mesh 문서에서 Cloud Service Mesh를 더 많이 사용하는 방법을 알아보세요.
정책 컨트롤러 가이드에서 정책 컨트롤러에 대해 자세히 알아보기
구성 동기화 문서 및 정책 컨트롤러 문서에서 선언적 중앙 집중식 구성 및 정책 관리에 대해 자세히 알아보기