가이드: 안전한 Anthos

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

목표

이 가이드에서는 다음 작업을 통해 Anthos의 보안 기능을 소개합니다.

  • 엔드 투 엔드 보안 통신을 보장하기 위해 Anthos Config Management를 사용하여 하여 서비스 메시에 상호 TLS(mTLS)를 적용합니다.

  • 권한이 있는 컨테이너가 포함된 pod가 의도치 않게 배포되지 않도록 보안 가드레일을 설정합니다.

비용

Anthos 샘플 배포를 사용하면 Anthos를 구독하지 않는 한, 가격 책정 페이지에 나와 있는 Google Cloud의 Anthos 종량제 요금이 발생합니다.

Compute Engine VM 및 부하 분산기 요금과 같이 Anthos 샘플 배포를 실행하는 동안 발생하는 기타 Google Cloud 비용도 사용자가 부담합니다. 배포의 Google Cloud Marketplace 페이지에서 이러한 모든 리소스의 예상 월간 비용을 확인할 수 있습니다.

추가 요금이 청구되지 않도록 가이드를 완료하거나 배포를 살펴본 후 삭제하는 것이 좋습니다. Anthos 샘플 배포는 프로덕션 용도가 아니며 해당 구성요소를 업그레이드할 수 없습니다.

시작하기 전에

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

Cloud Shell 환경 설정

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

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

  • 대화형으로 작업하고 배포 변경사항을 확인하기 위해 누락된 명령줄 도구를 설치합니다.

  • anthos-sample-cluster1의 Kubernetes 컨텍스트를 설정합니다.

  • Anthos Config Management가 구성 변경사항을 클러스터와 동기화하기 위해 사용하는 저장소를 클론합니다. 커밋하고 업스트림 저장소로 푸시한 변경사항은 Anthos Config Management에 의해 인프라에 동기화됩니다. 이는 인프라에 변경사항을 적용하는 데 권장되는 방법입니다.

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

  1. 활성 Cloud Shell 세션이 있는지 확인합니다. 가이드 프로젝트의 Cloud Console에서 Cloud Shell 활성화 셸 활성화 버튼를 클릭하여 Cloud Shell을 실행할 수 있습니다.

  2. 작업할 디렉터리를 만듭니다.

    mkdir tutorial
    cd tutorial
    
  3. 초기화 스크립트를 다운로드합니다.

    curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
    
  4. 초기화 스크립트를 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
    
  5. 디렉터리를 구성 저장소로 변경하고 이 가이드의 나머지 부분에 대한 작업 디렉터리로 사용합니다.

    cd anthos-sample-deployment-config-repo
    

서비스 메시에 mTLS 적용

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

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

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

    Anthos Service Mesh 페이지로 이동

  2. 서비스 목록에서 transactionhistory를 클릭합니다. Anthos 탐색에서 확인한 것처럼 서비스 세부정보 페이지에는 이 서비스에 사용할 수 있는 모든 원격 분석이 표시됩니다.

  3. transactionhistory 페이지의 탐색 메뉴에서 연결된 서비스를 선택합니다. 여기에서 서비스의 인바운드 연결 및 아웃바운드 연결을 모두 확인할 수 있습니다. 잠금 해제된 자물쇠 아이콘은 일부 트래픽이 상호 TLS(mTLS)를 사용하지 않는 이 포트에서 관찰되었음을 나타냅니다.

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

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

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

  1. Git 저장소에서 정책 구성을 조정하여 서비스가 mTLS를 통해 암호화된 통신을 사용하도록 합니다.

  2. Anthos Config Management를 사용하여 저장소에서 정책 변경사항을 자동으로 선택하고 Anthos Service Mesh 정책을 조정합니다.

  3. 저장소와 동기화되도록 구성된 클러스터에서 정책이 변경되었는지 확인합니다.

Anthos Config Management 설정 확인

  1. nomos 명령어는 Config Management Operator와 상호작용하고 로컬 머신 또는 Cloud Shell에서 다른 유용한 Anthos Config Management 작업을 수행할 수 있는 명령줄 도구입니다. Anthos Config Management가 클러스터에 올바르게 설치 및 구성되었는지 확인하려면 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 Config Management가 클러스터를 구성 저장소의 마스터 분기와 동기화하도록 구성되어 있는지 확인합니다. 첫 번째 열의 별표는 현재 컨텍스트가 anthos-sample-cluster1로 설정되어 있음을 나타냅니다. 표시되지 않는 경우 현재 컨텍스트를 anthos-sample-cluster1로 전환합니다.

    kubectl config use-context anthos-sample-cluster1
    

    결과:

    Switched to context "anthos-sample-cluster1".
    
  2. master 분기에 있는지 확인합니다.

    git checkout master
    

    결과:

    Already on 'master'
    Your branch is up to date with 'origin/master'.
    
  3. 업스트림 구성 저장소를 확인합니다.

    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)
    
  4. 아직 anthos-sample-deployment-config-repo 디렉터리에 있는지 확인하고 다음 명령어를 실행하여 git 설정을 확인합니다. 이 도우미 함수는 초기화 스크립트에 의해 해당 환경에 제공되며, git config 명령어를 실행하여 git 구성의 기존 user.emailuser.name 값을 확인합니다. 이러한 값이 구성되지 않았으면 이 함수가 현재 활성 상태의 Google Cloud 계정에 따라 저장소 수준에서 기본값을 설정합니다.

    init_git
    

    결과(예시):

    Configured local git user.email to user@example.com
    Configured local git user.name to user
    

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

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

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

  1. 가장 먼저 살펴봐야 할 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 트래픽을 모두 허용합니다.

  2. 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
    
  3. 그런 다음 namespaces/istio-system/destination-rule.yaml에서 대상 규칙을 확인합니다. 이는 트래픽 암호화 여부 등 지정된 대상으로 트래픽을 전송하는 규칙을 지정합니다. TLS 모드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
    
  4. 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
    

저장소에 변경사항 푸시

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

  1. nomos vet를 실행하여 구성이 유효한지 확인합니다.

    nomos vet
    

    결과가 없으면 검증 오류가 없음을 나타냅니다.

  2. 변경사항을 푸시하면 Anthos Config Management가 이를 가져와서 시스템에 적용합니다. 예기치 않은 결과가 발생하지 않도록 구성의 현재 라이브 상태가 수정한 이후에 변경되지 않았는지 확인하는 것이 좋습니다. 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
    
  3. 이제 이러한 변경사항을 커밋하여 업스트림 저장소에 푸시합니다. 다음 명령어는 init 스크립트에서 환경에 가져온 watchmtls라는 도우미 함수를 사용합니다. 이 도우미 함수는 이전에 시도한 nomos status 명령어와 kubectl 명령어의 조합을 실행합니다. Ctrl+C를 눌러 종료할 때까지 클러스터에서 변경사항을 감시합니다. 클러스터에 변경사항이 적용되고 동기화될 때까지 디스플레이를 모니터링합니다.

    git commit -am "enable mtls"
    git push origin master && watchmtls
    

    Anthos의 Anthos Service Mesh 페이지에 반영된 변경사항을 확인할 수도 있습니다.

    Anthos Service Mesh 페이지로 이동

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

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

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

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

가드레일 시행

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

정책 컨트롤러 사용

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

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

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

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

  1. 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
    
  2. nomos vet를 사용하여 구성을 적용하기 전에 업데이트된 구성이 유효한지 확인합니다.

    nomos vet
    

    오류가 없으면 명령어가 자동으로 반환됩니다.

  3. 변경사항을 커밋하고 푸시하여 정책을 적용합니다. nomos statuswatch 명령어와 함께 사용하면 변경사항이 클러스터에 적용되었는지 확인할 수 있습니다. 완료되면 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 실행을 시도하여 테스트할 수 있습니다.

  1. 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
    
  2. 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 환경을 모니터링하는 게이트키퍼 허용 컨트롤러가 새 정책을 적용했음을 나타냅니다. Pod 사양에 권한이 있는 컨테이너가 있으므로 pod 실행이 차단되었습니다.

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

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

배포 더 살펴보기

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

삭제

Anthos 샘플 배포를 모두 살펴본 후 Google Cloud에서 만든 리소스를 삭제하면 이 리소스가 할당량을 차지하지 않고 이후에 요금이 청구되지 않습니다. 다음 섹션은 이러한 리소스를 삭제하거나 사용 중지하는 방법을 설명합니다.

  • 옵션 1. 프로젝트를 삭제할 수 있습니다. 권장 방법입니다. 하지만 프로젝트를 유지하려는 경우에는 옵션 2를 사용하여 배포를 삭제하면 됩니다.

  • 옵션 2. (실험용) 기존의 빈 프로젝트에서 작업하는 경우 배포 삭제부터 시작하여 이 가이드의 모든 단계를 수동으로 되돌리는 것이 좋습니다.

  • 옵션 3. (실험용) Google Cloud 전문가이거나 클러스터에 기존 리소스가 있는 경우 이 가이드에서 만든 리소스를 수동으로 삭제하는 것이 좋을 수 있습니다.

프로젝트 삭제(옵션 1)

  1. Cloud Console에서 리소스 관리 페이지로 이동합니다.

    리소스 관리로 이동

  2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
  3. 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

배포 삭제(옵션 2)

Deployment Manager에서 생성된 항목을 실행 취소하도록 허용하는 방식입니다. 배포에 오류가 발생했더라도 이 방식을 사용하여 실행취소할 수 있습니다.

  1. Cloud Console의 탐색 메뉴에서 Deployment Manager를 클릭합니다.

  2. 배포를 선택한 후 삭제를 클릭합니다.

  3. 삭제를 다시 클릭하여 확인합니다.

  4. 배포에 오류가 발생했더라도 배포를 선택하여 삭제할 수 있습니다.

  5. 삭제를 클릭해도 삭제되지 않으면 마지막 수단으로 삭제하지만 리소스는 유지를 시도할 수 있습니다. Deployment Manager에서 리소스를 삭제할 수 없는 경우 해당 리소스를 확인한 후 나중에 수동으로 삭제해야 합니다.

  6. Deployment Manager에서 삭제를 완료할 때까지 기다립니다.

  7. (임시 단계) 탐색 메뉴에서 네트워크 서비스 > 부하 분산을 클릭한 후 anthos-sample-cluster1 클러스터에서 만든 전달 규칙을 삭제합니다.

  8. (선택사항) https://source.cloud.google.com/<project_id>로 이동합니다. 이름에 config-repo가 있는 저장소를 삭제합니다(있는 경우).

  9. (선택사항) 배포 중에 만든 서비스 계정과 관련된 모든 IAM 역할을 삭제합니다.

수동 삭제(옵션 3)

Google Cloud Console에서 리소스를 수동으로 삭제하는 방식입니다.

  1. Cloud Console의 탐색 메뉴에서 Kubernetes Engine을 클릭합니다.

  2. 클러스터를 선택하고 삭제를 클릭한 후 삭제를 다시 클릭하여 확인합니다.

  3. Cloud Console의 탐색 메뉴에서 Compute Engine을 클릭합니다.

  4. 점프 서버를 선택하고 삭제를 클릭한 후 삭제를 다시 클릭하여 확인합니다.

  5. 옵션 2의 7단계와 8단계를 따릅니다.

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

다음 단계

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

가이드 더보기

Anthos 자세히 알아보기

설문조사 참여

이 가이드를 완료한 후 설문조사에 참여해 주세요. 이 가이드를 수행하는 중에 발생한 문제에 대해 의견을 들려주세요. 설문조사를 통해 의견을 제출해 주셔서 감사합니다.

감사합니다.

Anthos팀