예정된 승인 변경사항 준비

Application Integration은 통합이 작업을 수행할 권한을 얻는 방식을 변경하고 있으며 변경사항은 곧 적용됩니다. 대부분의 통합은 현재와 동일하게 계속 실행되지만, 일부 통합은 먼저 구성을 변경해야 하며, 변경하지 않으면 해당 통합이 실행을 중지합니다. 이 페이지의 모든 항목은 이미 제어하고 있는 구성을 사용하므로 지금 바로 모든 작업을 수행할 수 있습니다.

예정된 승인 변경사항

Application Integration은 통합 실행을 위해 ID가 처리되는 방식을 업데이트하고 있습니다. 모든 실행의 기본 ID가 명시적으로 표시됩니다. 실행은 실행을 트리거한 사용자로 작동하므로 호출하는 시스템은 해당 사용자의 액세스 권한을 적용하거나 선택한 실행 서비스 계정으로 작동합니다. 이 계정은 프로젝트의 다른 서비스 계정과 마찬가지로 제어, 범위 지정, 감사할 수 있습니다.

다음 두 가지 사항을 따릅니다. 통합을 실행하려면 실행 서비스 계정으로 작동할 권한도 필요합니다. 사용 가능한 ID가 없는 실행은 계속 실행되지 않고 중지됩니다.

시작하기 전에

다음 작업을 순서대로 완료합니다. 다른 두 작업은 모두 게시로 끝나고 게시 자체는 권한이 확인되므로 첫 번째 작업을 먼저 수행합니다.

  1. 서비스 계정 사용자 부여를 자동화에서 사용하는 서비스 계정을 포함하여 통합을 실행, 승인, 수정 또는 게시하는 모든 사용자에게 이미 사용 중인 모든 실행 서비스 계정에 대해 수행합니다.
  2. 사용자 없이 실행되고 실행 서비스 계정이 없는 통합에 실행 서비스 계정 설정 을 수행합니다.
  3. 서비스 계정 사용자 부여를 **서비스 계정** 또는 **OIDC 토큰** 유형의 모든 인증 프로필에 지정된 서비스 계정에 대해 수행합니다. 이러한 계정은 일반적으로 실행 서비스 계정과 다른 계정입니다.

실행 서비스 계정이 필요한 통합

통합에 실행 서비스 계정이 필요한지 확인

전체 실행에 사용할 수 있는 사용자 인증 정보가 없는 경우에만 실행 서비스 계정이 필요합니다. 이러한 상황은 두 가지 경우에만 발생합니다.

통합 실행 방법 사용자 인증 정보를 사용할 수 있나요? 실행 서비스 계정이 필요한가요?
동기식 : 사용자가 시작하고 결과를 기다립니다. 예, 전체 실행에 사용 가능 아니요
비동기식 : 대기열에 추가되고 나중에 완료됩니다. 트리거되는 순간에만 예
무인 : 일정 또는 이벤트가 시작합니다. 아니요, 사용자가 없습니다. 예

영향을 받는 통합 식별

먼저 사용자가 없는 상태로 실행되는 경우가 있나요? 다음 중 하나라도 참이면 실행됩니다.

둘째, 실행 서비스 계정이 비어 있나요? 리전의 모든 게시된 버전을 실행 서비스 계정과 함께 나열하려면 다음 명령어를 실행합니다.

curl -s -G -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-urlencode "filter=state=ACTIVE" \
  --data-urlencode "pageSize=1000" \
  "https://REGION-integrations.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/integrations/-/versions" \
| jq -r '.integrationVersions[]
         | [ .name, (.runAsServiceAccount // "NONE") ]
         | @tsv'

다음을 바꿉니다.

  • REGION: 통합의 리전입니다. 지원되는 리전 목록은 위치를 참조하세요.
  • PROJECT_ID: Google Cloud 프로젝트의 ID입니다.

NONE이 표시된 행은 첫 번째 절반이 적용되는 경우에만 조치가 필요합니다. 통합 툴바의 정보 통합 요약 창에서 콘솔의 Google Cloud 단일 통합을 확인할 수도 있습니다.

통합 업데이트

서비스 계정 사용자 부여

역할을 부여하려면 다음 명령어를 실행하세요.

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT \
    --project=SERVICE_ACCOUNT_PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/iam.serviceAccountUser'

다음을 바꿉니다.

  • SERVICE_ACCOUNT: 실행 서비스 계정 또는 인증 프로필에 지정된 계정의 이메일 주소입니다.
  • SERVICE_ACCOUNT_PROJECT_ID: 서비스 계정을 소유하는 프로젝트의 ID입니다.
  • PRINCIPAL: 사용자의 이메일 주소입니다.

그룹의 경우(일반적으로 사용자가 가입하고 탈퇴하는 경우에도 유지되므로 더 나은 방법임) user:를 group:으로 바꿉니다. 자동화의 경우 serviceAccount:를 사용합니다.

콘솔에서 Google Cloud 동일한 작업을 수행하려면 IAM 및 관리자 > 서비스 계정으로 이동하여 서비스 계정을 선택한 후 권한 > 액세스 권한 부여를 클릭합니다. 자세한 내용은 서비스 계정에 대한 액세스 관리를 참조하세요.

실행 서비스 계정 설정

  1. 서비스 계정을 선택하거나 만들고 통합 태스크가 터치하는 리소스에 필요한 역할을 부여합니다. 부여할 항목을 확인하려면 프로젝트의 Application Integration 서비스 에이전트인 service-PROJECT_NUMBER@gcp-sa-integrations.iam.gserviceaccount.com가 현재 보유하고 있는 역할을 확인하고 이 통합에서 사용하는 부분만 새 계정에 부여합니다.
  2. 자동화를 포함하여 통합을 실행, 승인, 수정 또는 게시하는 모든 사용자에게 서비스 계정 사용자를 부여합니다.
  3. 통합을 열고 통합 툴바의 정보 통합 요약 창에서 서비스 계정을 설정합니다.
  4. 통합을 게시합니다. 자세한 내용은 통합 테스트 및 게시 를 참조하세요.

Google Cloud는 모든 통합에서 공유되는 광범위한 권한이 있는 계정 하나를 사용하는 대신 각 통합에 전용의 최소 범위 서비스 계정을 사용하는 것이 좋습니다. 이렇게 하면 통합의 효과가 포함되고 감사 로그에 이름으로 표시됩니다. 자세한 내용은 서비스 계정 작업 권장사항을 참조하세요.

누락된 권한 문제 해결

상황 표시되는 내용 필요한 조치
사용자가 통합을 트리거하지만 실행 서비스 계정으로 작동할 수 없음 PERMISSION_DENIED로 트리거가 거부됩니다. 실행이 대기열에 추가되기 전에 검사가 실행되므로 실행 로그에 아무것도 표시되지 않습니다. 태스크가 실패한 것이 아니라 아무 일도 일어나지 않은 것처럼 보입니다. 트리거하는 사용자에게 서비스 계정 사용자 부여
사용자 인증 정보가 없는 실행에는 실행 서비스 계정이 없음 커넥터, REST 엔드포인트 호출, Cloud Run 함수 태스크가 연결하려는 대상에 대해 실패합니다. 게시 시: The integration is missing run-as service account since governance is enabled for your project. 실행 서비스 계정 설정
태스크에서 호출자가 서비스 계정으로 작동할 수 없는 인증 프로필을 사용함 실행의 나머지 부분이 계속되는 동안 해당 태스크가 거부됩니다. You do not have permission to use Auth Config ID because you cannot act as its service account: SERVICE_ACCOUNT. 서비스 계정 사용자 부여 프로필에 지정된 계정에
승인자가 실행 서비스 계정으로 작동할 수 없음 승인 프로세스가 눈에 띄는 오류를 생성하지 않고 자동으로 실패합니다. 실행이 만료될 때까지 일시중지 상태로 유지되므로 승인이 작동을 중지한 것처럼 보입니다. 서비스 계정 사용자 부여 승인할 수 있는 모든 사용자에게
사용자가 권한 없이 통합을 수정하거나 게시함 Publisher does not have required permission to publish integration with service account: SERVICE_ACCOUNT. 이미 게시된 항목은 계속 실행됩니다. 자동화에서 게시하는 경우 콘솔이 아닌 배포 파이프라인에 표시됩니다. 서비스 계정 사용자 부여 대상: 편집자, 게시자, 자동화
태스크가 트리거한 사용자로 실행되고 해당 사용자가 리소스에 연결할 수 없음 통합에 변경사항이 없더라도 실행이 정상적으로 시작된 후 하나의 태스크가 리소스 이름을 지정하지 못하고 실패합니다. 해당 사용자에게 리소스에 대한 액세스 권한을 부여하거나 통합을 이미 액세스 권한이 있는 실행 서비스 계정으로 이동합니다. 일반적으로 통합의 액세스 권한이 실행하는 사용자에 따라 달라지는 것을 방지하므로 더 나은 방법입니다.

Application Integration 오류 코드의 전체 목록은 오류 코드를 참조하세요.

일반적인 질문

역할을 부여했는데도 여전히 실패합니다. 무엇이 누락되었나요?

  • 지원금이 잘못된 프로젝트로 이동했습니다. 통합을 소유하는 프로젝트가 아닌 서비스 계정을 소유하는 프로젝트에서 권한을 부여해야 합니다.
  • 아직 적용되지 않았습니다. 몇 분 정도 기다리세요. 승인 결정은 일반적인 IAM 전파 지연 외에도 잠시 캐시됩니다.
  • 두 번째 서비스 계정이 관련되어 있습니다. 실행 서비스 계정과 각 인증 프로필의 서비스 계정은 별개이며 둘 다 권한 부여가 필요합니다.

통합 호출자 역할이 더 이상 충분하지 않은 이유는 무엇인가요?

여전히 통합을 실행할 수 있습니다. 통합이 실행되는 서비스 계정으로 작동할 수 있도록 허용한 적은 없으며, 이는 실행이 가져오는 액세스 권한의 양을 결정합니다. roles/integrations.integrationAdmin, roles/integrations.integrationEditor, 또는 roles/integrations.integrationInvoker는 모두 iam.serviceAccounts.actAs를 부여하지 않으므로 별도의 권한 부여입니다.

통합은 동기식으로만 실행됩니다. 실행 서비스 계정이 필요한가요?

아니요. 동기식 실행에는 이미 ID(트리거한 사용자)가 있습니다. 통합에 실행 서비스 계정이 필요한지 확인을 참조하세요.

콘솔에 신고된 항목이 없습니다. 안전한가요?

꼭 그런 것은 아닙니다. 경고는 관찰된 실행에 따라 달라지므로 일정이 드문 통합 또는 최근에 아무도 트리거하지 않은 통합은 경고를 표시하지 않고도 조치가 필요할 수 있습니다. 조용한 콘솔을 안전하다고 읽는 대신 실행 서비스 계정이 필요한 통합을 살펴보세요.

다음 단계