프로젝트에 대한 적시 권한 있는 액세스 관리

Last reviewed 2024-07-22 UTC

---

이 문서에서는 오픈소스 도구를 사용하여 Google Cloud 프로젝트에 대해 적시 권한 있는 액세스를 구현하는 방법을 설명합니다. 적시 권한 있는 액세스를 사용하면 제한된 사용자 집합에 대해 액세스가 필요할 때만 프로젝트에 대한 임시 액세스를 부여할 수 있습니다.

이 문서는 Google Cloud 리소스에 대해 사용자 액세스를 관리하는 관리자를 대상으로 합니다. 여기에서는 사용자가 Google Cloud, Identity and Access Management(IAM), 관련 개념에 익숙하다고 가정합니다.

적시 권한 있는 액세스 관리 개요

최소 권한의 원칙을 따를 때는 일상 활동을 수행할 수 있지만 그 이상은 수행할 수 없도록 액세스를 사용자에게 부여합니다. 이 원칙을 따르면 위험을 줄이는 데 도움이 됩니다. 하지만 사용자가 예기치 않은 사고를 처리하기 위해 때때로 권한 있는 작업을 수행해야 하는 경우에는 방해가 될 수 있습니다. 예를 들어 프로덕션 시스템에서 문제를 해결하거나 민감한 정보가 포함된 문제를 해결해야 할 수 있습니다.

이 문제를 해결하기 위한 한 가지 방법은 적시 권한 있는 액세스, 즉 필요한 경우에만 권한 있는 액세스를 제공하는 것입니다. 적시 권한 있는 액세스 관리의 핵심 개념은 영구 액세스와 적격한 액세스를 구분하는 것입니다.

• 영구 액세스는 해제할 때까지 적용됩니다. 최소 권한의 원칙에 따라 영구 액세스를 제한하고 반드시 필요한 소수의 사용자에게만 제공하는 것이 좋습니다.
• 적격한 액세스는 즉시 적용되지 않습니다. 대신 프로젝트에 대해 적격한 액세스가 부여된 사용자가 액세스를 명시적으로 활성화한 후에야 프로젝트에 액세스할 수 있습니다. 또한 이를 수행하기 위한 근거를 제시해야 합니다. 사용자 액세스가 활성화되면 잠시 후 액세스가 자동으로 만료됩니다.

적시 권한 있는 액세스 관리를 사용하면 다음을 수행하는 데 도움이 될 수 있습니다.

• 실수로 인한 리소스 수정 또는 삭제 위험을 줄여줍니다. 예를 들어 사용자가 필요할 때만 권한 있는 액세스를 가진 경우 사용자가 변경하지 않아야 하는 리소스에 의도치 않게 영향을 주는 스크립트를 다른 시간에 실행하지 못하도록 방지하는 데 도움이 됩니다.
• 권한이 활성화된 이유를 나타내는 감사 추적을 만듭니다.
• 과거 활동을 분석하기 위한 감사 및 검토를 수행합니다.

Just-In-Time Access를 사용하여 권한 있는 액세스 구현

Just-In-Time Access는 App Engine 또는 Cloud Run에서 실행하도록 설계된 오픈소스 애플리케이션이며, Google Cloud 리소스에 대해 적시 권한 있는 액세스를 구현할 수 있게 해줍니다. 이 애플리케이션을 통해 관리자, 사용자, 감사자는 다음 태스크를 수행할 수 있습니다.

• 관리자는 사용자 또는 그룹에 역할을 부여하고 다음 IAM 조건을 추가하여 역할을 적격한 역할로 지정할 수 있습니다.

  has({}.jitAccessConstraint)
  

• 사용자는 적시 액세스 애플리케이션을 사용하여 자신이 액세스할 수 있는 프로젝트 및 역할을 검색할 수 있습니다.

  적시 액세스 애플리케이션의 다음 스크린샷은 한 프로젝트에서 사용자에게 자격이 있는 역할 목록을 보여줍니다.

  

  그런 후 하나 이상의 역할을 활성화하고 액세스를 얻은 근거를 제시할 수 있습니다.

  

  사용자가 역할을 활성화한 후 Just-In-Time Access는 프로젝트에 대해 사용자에게 임시 액세스를 부여합니다.

• 감사관은 Cloud Logging을 사용하여 적격한 역할이 사용자에 의해 활성화된 시간 및 이유를 검토할 수 있습니다.

무단 액세스로부터 애플리케이션을 보호하기 위해 Just-In-Time Access 애플리케이션은 IAP(Identity-Aware Proxy)를 통해서만 액세스할 수 있습니다. 관리자는 IAP를 사용하여 Just-In-Time Access에 액세스가 허용되어야 하는 사용자, 액세스하기 위해 이러한 사용자가 충족시켜야 하는 추가 조건을 제어할 수 있습니다.

시작하기 전에

Just-in-Time Access 애플리케이션을 배포하려면 먼저 적시 권한 있는 액세스를 관리하려는 리소스 계층 구조 부분을 결정해야 합니다. 다음 리소스에 대해 액세스를 관리할 수 있습니다.

• 단일 프로젝트
• 여러 프로젝트가 포함된 폴더
• 조직의 모든 프로젝트

배포를 완료하려면 다음이 필요합니다.

• 사용 중인 Google Cloud 조직에 해당하는 Cloud ID 또는 Google Workspace 계정에 대한 최고 관리자 액세스
• Just-In-Time Access를 사용하여 관리하려는 프로젝트, 폴더, 조직의 IAM 정책을 수정할 수 있는 권한입니다.
• 액세스 테스트에 사용할 수 있는 보조 Cloud ID 또는 Google Workspace 사용자

또한 Just-In-Time Access 애플리케이션을 배포할 Google Cloud 프로젝트가 필요합니다.

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

2. Make sure that billing is enabled for your Google Cloud project.

적시 액세스 배포

이 섹션에서는 Just-In-Time Access 애플리케이션을 App Engine 또는 Cloud Run에 배포하는 방법을 설명합니다.

Just-In-Time Access 애플리케이션을 Cloud Run에 배포하려면 애플리케이션을 App Engine에 배포할 때보다 더 복잡한 구성이 필요합니다. 따라서 App Engine을 지원하지 않는 리전에 배포하거나 다른 이유로 App Engine을 사용할 수 없는 경우가 아니면 App Engine을 사용하는 것이 좋습니다.

Just-In-Time Access 코드는 GitHub 저장소에 있습니다.

이 섹션에서는 사용자가 관리자라고 가정합니다.

Google Cloud 프로젝트를 구성합니다.

1. Google Cloud 콘솔에서 프로젝트로 전환하고 필요한 API를 사용 설정합니다.

   App Engine

   Enable the Cloud Asset Inventory, Resource Manager, Identity-Aware Proxy, Container Registry, Cloud Build, Identity and Access Management, and Directory APIs.

   Enable the APIs

   Cloud Run

   Enable the Cloud Asset Inventory, Resource Manager, Identity-Aware Proxy, Container Registry, Cloud Run, Compute Engine, Identity and Access Management, and Directory APIs.

   Enable the APIs

2. Cloud Shell을 엽니다.

   Cloud Shell 열기

3. 프로젝트 ID를 포함하도록 환경 변수를 설정합니다.

   gcloud config set project PROJECT_ID
   

   PROJECT_ID를 프로젝트의 ID로 바꿉니다.

4. Just-In-Time Access 애플리케이션의 서비스 계정을 만듭니다.

   SERVICE_ACCOUNT=$(gcloud iam service-accounts create jitaccess --display-name "Just-In-Time Access" --format "value(email)")
   

5. 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여하여 애플리케이션에서 서비스 계정을 사용하여 토큰을 만들 수 있게 합니다.

   gcloud iam service-accounts add-iam-policy-binding $SERVICE_ACCOUNT \
     --member "serviceAccount:$SERVICE_ACCOUNT" \
     --role "roles/iam.serviceAccountTokenCreator"
   

   애플리케이션은 토큰을 생성하여 Directory API에 액세스하고 선택적으로 복수 사용자 승인 체계 워크플로를 처리할 수 있는 권한을 사용합니다.

Just-in-Time Access 애플리케이션에 IAM 바인딩 관리 권한을 부여합니다.

이제 애플리케이션의 서비스 계정에 프로젝트 IAM 관리자 역할을 부여합니다. 이 역할을 통해 Just-In-Time Access 애플리케이션이 적시 액세스를 부여해야 할 때 임시 IAM 바인딩을 만들 수 있습니다.

프로젝트 IAM 관리자 역할은 권한이 높기 때문에 애플리케이션의 서비스 계정 및 이를 포함하는 프로젝트에 대해 액세스를 제한해야 합니다.

다음 가이드라인을 참조하세요.

• 프로젝트에 액세스할 수 있는 사용자 수를 제한하고 사용자에게 소유자 또는 편집자 역할을 부여하지 않습니다.
• 서비스 계정을 가장할 수 있는 사용자 수를 제한합니다. 이러한 가장을 수행할 수 있어야 하는 사용자에는 서비스 계정 사용자 역할 또는 서비스 계정 토큰 생성자 역할이 있는 사용자가 포함됩니다.

서비스 계정에 프로젝트 IAM 관리자 역할을 부여하려면 다음을 수행합니다.

1. 프로젝트 IAM 관리자 역할(roles/resourcemanager.projectIamAdmin) 및 Cloud 애셋 뷰어 역할(roles/cloudasset.viewer)을 적시 권한 있는 액세스를 관리하려는 리소스 계층 구조의 일부에 부여합니다.

   프로젝트

   SCOPE_ID=RESOURCE_PROJECT_ID
   SCOPE_TYPE=projects
   
   gcloud projects add-iam-policy-binding $SCOPE_ID \
       --member "serviceAccount:$SERVICE_ACCOUNT" \
       --role "roles/resourcemanager.projectIamAdmin" \
       --condition None
   
   gcloud projects add-iam-policy-binding $SCOPE_ID \
       --member "serviceAccount:$SERVICE_ACCOUNT" \
       --role "roles/cloudasset.viewer" \
       --condition None
   

   RESOURCE_PROJECT_ID를 액세스를 관리하려는 Google Cloud 프로젝트의 ID로 바꿉니다. 이 프로젝트는 Just-In-Time Access를 배포하려는 것과 다릅니다.

   폴더

   SCOPE_ID=RESOURCE_FOLDER_ID
   SCOPE_TYPE=folders
   
   gcloud resource-manager folders add-iam-policy-binding $SCOPE_ID \
       --member "serviceAccount:$SERVICE_ACCOUNT" \
       --role "roles/resourcemanager.projectIamAdmin" \
       --condition None
   gcloud resource-manager folders add-iam-policy-binding $SCOPE_ID \
       --member "serviceAccount:$SERVICE_ACCOUNT" \
       --role "roles/cloudasset.viewer" \
       --condition None
   

   RESOURCE_FOLDER_ID를 액세스를 관리하려는 프로젝트가 포함된 폴더의 ID로 바꿉니다.

   조직

   SCOPE_ID=ORGANIZATION_ID
   SCOPE_TYPE=organizations
   
   gcloud organizations add-iam-policy-binding $SCOPE_ID \
       --member "serviceAccount:$SERVICE_ACCOUNT" \
       --role "roles/resourcemanager.projectIamAdmin" \
       --condition None
   gcloud organizations add-iam-policy-binding $SCOPE_ID \
       --member "serviceAccount:$SERVICE_ACCOUNT" \
       --role "roles/cloudasset.viewer" \
       --condition None
   

   ORGANIZATION_ID를 조직의 ID로 바꿉니다.

애플리케이션의 그룹 멤버십 확인을 허용하도록 액세스 부여

Just-In-Time Access 애플리케이션을 사용하면 적격한 액세스를 특정 사용자 또는 전체 그룹에 부여할 수 있습니다. 그룹 멤버십을 평가하려면 애플리케이션이 Cloud ID 또는 Google Workspace 계정에서 그룹 멤버십 정보를 읽도록 허용되어야 합니다.

애플리케이션의 서비스 계정에 그룹 멤버십 읽기 액세스 권한을 부여하려면 다음을 수행합니다.

1. Google 관리 콘솔을 열고 최고 관리자로 로그인합니다.

2. 계정 > 관리자 역할로 이동합니다.

   관리자 역할로 이동합니다.

3. 그룹스 리더 > 관리자를 클릭합니다.

4. 서비스 계정 할당을 클릭합니다.

5. 다음 이메일 주소를 입력합니다.

   jitaccess@PROJECT_ID.iam.gserviceaccount.com
   

   PROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.

6. 추가를 클릭합니다.

7. 역할 지정을 클릭합니다.

Cloud ID 또는 Google Workspace 계정의 고객 ID 조회

Directory API를 사용하여 그룹 멤버십을 평가하려면 Just-In-Time Access 애플리케이션에 Cloud ID 또는 Google Workspace 계정의 고객 ID가 필요합니다. 이 ID를 찾으려면 다음을 수행합니다.

1. Google 관리 콘솔에서 계정 > 계정 설정으로 이동합니다.

   계정 설정으로 이동

2. 계정의 고객 ID를 복사합니다. 고객 ID는 C로 시작합니다.

   이 고객 ID는 이후 단계에서 필요합니다.

3. 관리 콘솔을 닫습니다.

애플리케이션 배포

이제 Just-In-Time Access 애플리케이션을 App Engine 또는 Cloud Run에 배포할 준비가 되었습니다.

App Engine

Just-In-Time Access 애플리케이션을 App Engine에 배포하려면 다음 단계를 수행합니다.

1. Cloud Shell에서 Cloud ID 또는 Google Workspace 계정의 고객 ID를 포함하도록 환경 변수를 설정합니다.

   ACCOUNT_CUSTOMER_ID=CUSTOMER_ID
   

   CUSTOMER_ID를 이전에 조회한 고객 ID로 바꿉니다.

2. App Engine 애플리케이션을 만듭니다.

   gcloud app create --region LOCATION
   

   LOCATION을 지원되는 App Engine 위치로 바꿉니다.

3. App Engine 기본 서비스 계정에 Artifact Registry Create-on-push 작성자(roles/artifactregistry.createOnPushWriter) 및 스토리지 관리자(roles/storage.admin) 역할을 부여하여 App Engine이 Artifact Registry를 사용하도록 허용합니다.

   PROJECT_ID=$(gcloud config get-value core/project)
   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member "serviceAccount:$[e-mail]" \
       --role "roles/artifactregistry.createOnPushWriter" \
       --condition None
   gcloud projects add-iam-policy-binding $PROJECT_ID\
       --member "serviceAccount:$[e-mail]" \
       --role "roles/storage.admin" \
       --condition None
   

4. GitHub 저장소를 클론하고 latest 브랜치로 전환합니다.

   git clone https://github.com/GoogleCloudPlatform/jit-access.git
   cd jit-access/sources
   git checkout latest
   

5. Just-In-Time Access 애플리케이션에 대한 구성 파일을 만듭니다.

   cat << EOF > app.yaml
   
   runtime: java17
   instance_class: F2
   service_account: $SERVICE_ACCOUNT
   env_variables:
       RESOURCE_SCOPE: $SCOPE_TYPE/$SCOPE_ID
       RESOURCE_CATALOG: AssetInventory
       RESOURCE_CUSTOMER_ID: $ACCOUNT_CUSTOMER_ID
       ACTIVATION_TIMEOUT: 60
       JUSTIFICATION_HINT: "Bug or case number"
       JUSTIFICATION_PATTERN: ".*"
   EOF
   

   이 구성 파일에서 변수 값을 맞춤설정할 수 있습니다. 설정 목록은 연관된 GitHub 저장소에서 구성 옵션 페이지를 참조하세요.

6. 애플리케이션을 배포합니다.

   gcloud app deploy --appyaml app.yaml
   

   출력의 target url을 기록해 둡니다. 이 URL은 Just-In-Time Access 애플리케이션의 공개 URL이 됩니다.

   NOT_FOUND: Unable to retrieve P4SA 오류 메시지가 표시되면 명령어를 다시 시도합니다.

Cloud Run

Cloud Run에 Just-In-Time Access 애플리케이션을 배포하려면 다음 단계를 수행합니다.

1. Cloud Shell에서 Cloud ID 또는 Google Workspace 계정의 고객 ID를 포함하도록 환경 변수를 설정합니다.

   ACCOUNT_CUSTOMER_ID=CUSTOMER_ID
   

   CUSTOMER_ID를 이전에 조회한 고객 ID로 바꿉니다.

2. 배포할 리전 선택:

   gcloud config set run/region REGION
   

   REGION을 Cloud Run을 지원하는 리전으로 바꿉니다.

3. 백엔드 서비스를 만듭니다.

   gcloud compute backend-services create jitaccess-backend \
     --load-balancing-scheme=EXTERNAL \
     --global
   

   나중에 이 백엔드 서비스를 사용하여 부하 분산기 및 IAP를 구성합니다.

4. GitHub 저장소를 클론하고 latest 브랜치로 전환합니다.

   git clone https://github.com/GoogleCloudPlatform/jit-access.git
   cd jit-access/sources
   git checkout latest
   

5. 애플리케이션을 빌드하고 컨테이너 이미지를 Container Registry에 내보냅니다.

   PROJECT_ID=$(gcloud config get-value core/project)
   
   docker build -t gcr.io/$PROJECT_ID/jitaccess:latest .
   docker push gcr.io/$PROJECT_ID/jitaccess:latest
   

6. Just-In-Time Access 애플리케이션에 대한 구성 파일을 만듭니다.

   PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format 'value(projectNumber)')
   REGION=$(gcloud config get-value run/region)
   IAP_BACKEND_SERVICE_ID=$(gcloud compute backend-services describe jitaccess-backend --global --format 'value(id)')
   
   cat << EOF > app.yaml
   
   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: jitaccess
     namespace: $PROJECT_NUMBER
     labels:
       cloud.googleapis.com/location: $REGION
     annotations:
       run.googleapis.com/ingress: internal-and-cloud-load-balancing
   spec:
     template:
       spec:
         serviceAccountName: $SERVICE_ACCOUNT
         containers:
         - image: gcr.io/$PROJECT_ID/jitaccess:latest
           env:
           - name: RESOURCE_SCOPE
             value: "$SCOPE_TYPE/$SCOPE_ID"
           - name: RESOURCE_CATALOG
             value: "AssetInventory"
           - name: RESOURCE_CUSTOMER_ID
             value: "$ACCOUNT_CUSTOMER_ID"
           - name: ACTIVATION_TIMEOUT
             value: "60"
           - name: JUSTIFICATION_HINT
             value: "Bug or case number"
           - name: JUSTIFICATION_PATTERN
             value: ".*"
           - name: IAP_BACKEND_SERVICE_ID
             value: "$IAP_BACKEND_SERVICE_ID"
   EOF
   
   

   이 구성 파일에서 변수 값을 맞춤설정할 수 있습니다. 설정 목록은 연관된 GitHub 저장소에서 구성 옵션 페이지를 참조하세요.

7. 애플리케이션을 배포합니다.

   gcloud run services replace app.yaml
   

부하 분산기 구성

이제 Just-In-Time Access 애플리케이션의 부하 분산기를 구성합니다.

App Engine

App Engine에서 부하 분산기를 자동으로 구성해 줍니다.

Cloud Run

Cloud Run 서비스에 HTTPS 부하 분산기를 구성합니다.

1. 부하 분산기의 고정 외부 IP 주소를 예약합니다.

   gcloud compute addresses create jitaccess-ip --global
   

2. 부하 분산기의 관리형 SSL 인증서를 만듭니다.

   gcloud compute ssl-certificates create jitaccess \
     --domains PUBLIC_FQDN \
     --global
   

   여기서 PUBLIC_FQDN은 사용할 정규화된 공개 도메인 이름(FQDN)입니다(예: jitaccess.example.com).

3. 부하 분산기의 IP 주소를 찾습니다.

   gcloud compute addresses describe jitaccess-ip \
     --global \
     --format=value\(address\)
   

4. 공개 DNS 영역에서 부하 분산기의 IP 주소를 나타내는 DNS A 레코드를 만듭니다. DNS 레코드의 정규화된 이름은 SSL 인증서에 사용한 이름과 일치해야 합니다.

   참고: 새 DNS 레코드가 전파되는 데 몇 분 또는 몇 시간이 걸릴 수 있습니다. 이 기간 동안에는 관리형 SSL 인증서를 사용할 수 없습니다. 자세한 내용은 Google 관리형 인증서 문제 해결을 참조하세요.

5. Cloud Run 서비스에 대한 서버리스 네트워크 엔드포인트 그룹을 만들고 백엔드 서비스에 연결합니다.

   gcloud compute network-endpoint-groups create jitaccess \
     --region $(gcloud config get-value run/region) \
     --network-endpoint-type=serverless  \
     --cloud-run-service jitaccess
   gcloud compute backend-services add-backend jitaccess-backend \
     --global \
     --network-endpoint-group jitaccess \
     --network-endpoint-group-region $(gcloud config get-value run/region)
   

6. 외부 IP 주소를 사용하고 트래픽을 백엔드 서비스로 전달하는 부하 분산기 프런트엔드를 만듭니다.

   gcloud compute url-maps create jitaccess \
     --default-service jitaccess-backend
   gcloud compute target-https-proxies create jitaccess-proxy \
     --ssl-certificates jitaccess \
     --url-map jitaccess
   gcloud compute forwarding-rules create jitaccess-https \
     --load-balancing-scheme EXTERNAL \
     --address jitaccess-ip \
     --target-https-proxy jitaccess-proxy \
     --global \
     --ports=443
   

IAP(Identity-Aware Proxy) 구성

이제 적시 액세스 애플리케이션의 IAP를 구성합니다.

1. Cloud Shell에서 OAuth 동의 화면을 구성합니다.

   gcloud iap oauth-brands create \
       --application_title "Just-In-Time Access" \
       --support_email=$(gcloud config get core/account)
   

2. Google Cloud Console에서 보안 > IAP(Identity-Aware Proxy)로 이동합니다.

   IAP로 이동

3. IAP를 사용 설정됨으로 설정합니다.

이제 Just-In-Time Access 애플리케이션에 액세스할 수 있는 사용자를 정의해야 합니다. 개별 사용자, 그룹, 전체 도메인에 액세스를 부여할 수 있습니다.

1. Google Cloud Console에서 IAM 및 관리자 > IAM으로 이동합니다.

   IAM으로 이동

2. 액세스 권한 부여를 클릭한 후 다음 값을 설정합니다.

   1. 주 구성원 목록에서 사용자, 그룹, 도메인을 선택합니다.
   2. 역할 목록에서 IAP 보안 웹 앱 사용자를 선택합니다.

   IAP 보안 웹 앱 사용자 역할은 사용자가 Just-In-Time Access 애플리케이션을 열 수 있게 해주지만, 추가 리소스에 대해 액세스를 제공하지 않습니다.

3. 저장을 클릭합니다.

역할 결합이 적용되려면 몇 분 정도 걸릴 수 있습니다.

App Engine

이제 IAP 구성이 완료되었습니다.

Cloud Run

IAP 구성을 완료하려면 IAP에서 사용하는 서비스 에이전트에 Cloud Run 호출자 역할(roles/run.invoker)을 부여합니다.

PROJECT_NUMBER=$(gcloud projects list \
  --filter $(gcloud config get-value project) \
  --format "value(PROJECT_NUMBER)")

gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
  --member "serviceAccount:service-$[e-mail]" \
  --role "roles/run.invoker"

적시 액세스 테스트

이제 적격한 액세스 권한을 부여하는 프로세스 및 적시 액세스 애플리케이션을 사용하여 적격한 액세스를 활성화하는 프로세스를 테스트할 수 있습니다.

적격한 액세스 부여

먼저 보조 Cloud ID 또는 Google Workspace 사용자에게 적격한 액세스를 부여합니다.

1. Google Cloud Console에서 프로젝트 목록을 사용하여 Just-In-Time Access 애플리케이션에서 관리되는 리소스 계층 구조의 일부인 프로젝트를 선택합니다.
2. IAM 페이지에서 액세스 권한 부여를 클릭합니다.
3. 보조 Cloud ID 또는 Google Workspace 사용자의 이메일 주소를 입력하고 프로젝트 > 브라우저 등의 역할을 선택합니다.
4. 조건 추가를 클릭합니다.
5. Eligible for JIT access와 같은 제목을 입력합니다.

6. 조건 편집자를 선택한 후 다음 CEL 표현식을 입력합니다.

   has({}.jitAccessConstraint)
   

7. 변경사항을 저장합니다.

액세스 활성화

이제 사용자를 전환하고 리소스에 대해 임시 액세스를 요청할 수 있습니다.

1. 브라우저 시크릿 창을 열고 앞에서 확인한 Just-In-Time Access 애플리케이션의 URL로 이동합니다.
2. 적격한 액세스를 부여한 사용자로 로그인합니다.
3. Just-In-Time Access 애플리케이션에서 액세스를 활성화하려는 역할 및 리소스를 선택합니다.

4. testing과 같은 근거를 입력한 후 액세스 요청을 클릭합니다.

   다음 페이지에서 액세스가 임시로 활성화된 것을 확인합니다.

로그 분석

이제 다시 관리 사용자로 전환해서 로그를 검토할 수 있습니다.

1. Google Cloud Console에서 Logging > 로그 탐색기로 이동합니다.

   로그 탐색기로 이동

2. 쿼리 표시를 사용 설정됨으로 설정합니다.

3. 다음 쿼리를 입력합니다.

   labels.event="api.activateRole"
   

4. 쿼리 실행을 클릭합니다.

   출력은 다음과 비슷합니다.

   {
   "textPayload": "User EMAIL activated role 'ROLE' on '//cloudresourcemanager.googleapis.com/projects/PROJECT_ID' for themselves",
   "severity": "INFO",
   "labels": {
       "resource": "//cloudresourcemanager.googleapis.com/projects/PROJECT_ID",
       "event": "api.activateRole",
       "role": "ROLE",
       "clone_id": "00c6...",
       "user": "EMAIL",
       "justification": "testing",
       ...
     },
   ...
   }
   

   활성화한 각 역할에 대해 로그 레코드가 생성됩니다. 로그 레코드에는 커스텀 필터를 만드는 데 사용할 수 있는 라벨 집합이 포함되어 있습니다.

적시 액세스 업그레이드

이 섹션에서는 새 버전의 애플리케이션 또는 다른 구성을 사용하도록 기존 적시 액세스 배포를 업그레이드하는 방법을 설명합니다.

이 섹션에서는 사용자가 관리자라고 가정합니다.

1. Google Cloud 콘솔에서 프로젝트로 전환한 후 Cloud Shell을 엽니다.

   Cloud Shell 열기

2. 프로젝트 ID를 포함하도록 환경 변수를 설정합니다.

   gcloud config set project PROJECT_ID
   

   PROJECT_ID를 프로젝트의 ID로 바꿉니다.

3. GitHub 저장소를 클론하고 latest 브랜치로 전환합니다.

   git clone https://github.com/GoogleCloudPlatform/jit-access.git
   cd jit-access/sources
   git checkout latest
   

4. 이전에 사용한 구성 파일을 다운로드하여 애플리케이션을 배포하고 이를 app.yaml 파일에 저장합니다.

   App Engine

   APPENGINE_VERSION=$(gcloud app versions list --service default --hide-no-traffic --format "value(version.id)")
   APPENGINE_APPYAML_URL=$(gcloud app versions describe $APPENGINE_VERSION --service default --format "value(deployment.files.'app.yaml'.sourceUrl)")
   
   curl -H "Authorization: Bearer $(gcloud auth print-access-token)" $APPENGINE_APPYAML_URL -o app.yaml
   cat app.yaml
   

   app.yaml 파일을 다운로드할 수 없으면 Google Cloud 콘솔에서 현재 구성을 다운로드할 수 있습니다.

   Cloud Run

   gcloud config set run/region REGION
   gcloud run services describe jitaccess --format yaml > app.yaml
   

   REGION을 기존 Cloud Run 배포가 포함된 리전으로 바꿉니다.

5. 구성을 변경하려면 app.yaml 파일을 수정합니다. 설정 목록은 연관된 GitHub 저장소에서 구성 옵션 페이지를 참조하세요.

6. 애플리케이션을 배포합니다.

   App Engine

   sed -i 's/java11/java17/g' app.yaml
   gcloud app deploy --appyaml app.yaml
   

   Cloud Run

   PROJECT_ID=$(gcloud config get-value core/project)
   
   docker build -t gcr.io/$PROJECT_ID/jitaccess:latest .
   docker push gcr.io/$PROJECT_ID/jitaccess:latest
   
   IMAGE=$(docker inspect --format='{{index .RepoDigests 0}}'  gcr.io/$PROJECT_ID/jitaccess)
   sed -i "s|image:.*|image: $IMAGE|g" app.yaml
   
   gcloud run services replace app.yaml
   

다음 단계

• 복수 사용자 승인 체계 구성
• 컨텍스트 인식 액세스를 사용하는 Just-In-Time Access에 대한 액세스 보안 방법 알아보기
• IAM 조건 자세히 알아보기
• Just-In-Time Access 애플리케이션의 커스텀 도메인 구성
• 클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기