서비스 계정을 사용하여 타사 애플리케이션의 VMware Cloud Director 액세스를 자동화할 수 있습니다.
공유
VMware Cloud Director 10.4.1부터는 사용자가 볼 수 있는 서비스 계정 정보를 제한하려는 경우 특정 역할에 제한된 서비스 계정 보기 권한만 부여하면 됩니다. 제한된 서비스 계정 보기 권한이 있는 사용자가 서비스 계정에 대해 GET 요청을 하면 응답에서 서비스 계정의 softwareId, softwareVersion, uri, status가 null로 표시됩니다.
구현
VMware Cloud Director에 대한 자동화된 액세스를 제공하기 위해 서비스 계정은 API 토큰을 사용합니다. 서비스 계정은 API 기반 액세스 전용입니다. 서비스 계정에 액세스 권한을 부여하면 인증된 클라이언트 애플리케이션은 즉시 사용하기 위한 해당 API 토큰(OAuth 새로 고침 토큰임) 및 첫 번째 VMware Cloud Director 세션을 나타내는 액세스 토큰을 수신합니다. 애플리케이션은 VMware Cloud Director로 인증하는 데 API 토큰이 필요합니다. 액세스 토큰은 애플리케이션이 서비스 계정을 사용하여 API 요청을 수행하는 데 사용하는 VMware Cloud Director 세션 토큰(JWT 토큰)입니다. 애플리케이션에 대한 서비스 계정은 API 토큰을 사용하므로 VMware Cloud Director의 사용자 API 토큰과 동일한 제한 사항이 있습니다.
서비스 계정에는 "서비스 계정 권한 부여 요청"을 사용하여 액세스 권한이 부여됩니다. 이렇게 하면 토큰을 사용해야 하는 애플리케이션만 토큰에 대한 유일한 액세스 권한을 가지며 토큰을 사용할 수 있습니다. 다른 행위자는 토큰에 액세스할 수 없습니다. 관리자로 서비스 계정에 대한 액세스를 관리합니다. 그러나 관리자도 액세스 권한을 부여하는 실제 토큰에 대한 액세스 권한이 없습니다. VMware Cloud Director는 서비스 계정에만 토큰을 제공합니다. 이를 위해 VMware Cloud Director는 잘 알려진 표준에 의존합니다. 사용자 및 토큰을 부여하는 애플리케이션이 부여 및 토큰 전송 중에 동기화되도록 하기 위해, 애플리케이션의 사용자 코드를 알고 있는 경우에만 API 토큰 부여 프로세스를 시작할 수 있습니다.
사용자 API 토큰과 달리 서비스 계정에 부여된 API 토큰은 RFC 6749 섹션 6에 따라 모든 용도에서 순환합니다. 사용되지 않은 서비스 계정 API 토큰은 해지하지 않는 한 만료되지 않습니다.
서비스 계정에는 하나의 역할만 있을 수 있습니다. OAuth 준수 API에서 역할은 범위 필드를 통해 역할 이름과 함께 URL 인코딩 URN(Uniform Resource Name)으로 전달됩니다. URN 형식은 urn:vcloud:role:[roleName]입니다. URN 인코딩을 설명하는 RFC 8141을 참조하십시오.
| 상태 | 설명 |
|---|---|
| 만든 날짜 | 계정은 생성 후 초기 상태에 있습니다. |
| 요청됨 | 요청자가 디바이스 권한 부여 요청을 사용하여 시작한 액세스에 대한 하나 이상의 미결 요청이 있습니다. |
| 부여됨 | 관리자가 미결 요청을 승인했으며 서비스 계정 폴링 및 API 토큰 가져오기를 기다리고 있습니다. |
| 활성 | 서비스 계정이 API 토큰을 가져왔으며 토큰을 사용하여 VMware Cloud Director에 액세스할 수 있습니다. |
제한 사항
서비스 계정 사용은 타사 애플리케이션에 목적이 있으므로 서비스 계정에는 몇 가지 제한 사항이 있습니다.
- 사용자 관리 작업 수행
- API 토큰 생성
- 다른 서비스 계정 관리
- 사용자
- 그룹
- 역할
- 글로벌 역할
- 권한 번들
- 토큰: 관리
- 토큰: 모두 관리
다중 사이트
VMware Cloud Director 10.4.1부터 서비스 계정은 다중 사이트 기능을 사용하여 지리적으로 분산된 여러 VMware Cloud Director 설치 또는 서버 그룹과 해당 조직을 단일 엔티티로 관리하고 모니터링할 수 있습니다. 자세한 내용은 다중 사이트 배포 구성 및 관리를 참조하십시오. 서비스 계정이 인증된 조직이 아닌 다른 조직에 요청을 수행하는 경우에는 연결된 조직에 서비스 계정이 존재하고 이름과 소프트웨어 ID가 동일한지 확인합니다. 또한 요청을 이행해야 하는 조직의 이름을 지정하는 X-VMWARE-VCLOUD-AUTH-CONTEXT 헤더를 포함해야 합니다. "VMware Cloud Director API 프로그래밍 가이드" 에서 다중 사이트 배포를 구성하고 관리하는 방법에 대한 정보를 참조하십시오.
VMware Cloud Director Service Provider Admin Portal을 사용하여 서비스 계정 만들기
Service Provider Admin Portal을 사용하여 VMware Cloud Director에 자동으로 액세스하기 위한 계정을 생성할 수 있습니다.
프로시저
결과
Created 상태로 나타납니다.
예
VMware Cloud Director API를 사용하여 서비스 계정을 생성할 수도 있습니다. API 요청은 사용자 API 토큰 생성과 동일한 API 끝점을 사용하지만 software_id 필드가 있으면 서비스 계정을 생성하려는 의도를 나타냅니다.
POST /oauth/provider/register
Accept:application/json
Content-Type:application/json
Authorization:Bearer eyJhbGciOiJSUzI...7g7rA
Body: {
"client_name": "exampleServiceAccount",
"software_id": "bc2528fd-35c4-44e5-a55d-62e5c4bd9c99",
"scope": "urn:vcloud:role:System%20Administrator",
"client_uri": "https://www.companyname.com",
"software_version": "1.0"
}
{
"client_name": "exampleServiceAccount",
"client_id": "734e3845-1573-4f07-9b6c-b493c9042187",
"grant_types": [
"urn:ietf:params:oauth:grant-type:device_code"
],
"token_endpoint_auth_method": "none",
"client_uri": "https://www.company_name.com",
"software_id": "bc2528fd-35c4-44e5-a55d-62e5c4bd9c99",
"software_version": "1.0",
"scope": "urn:vcloud:role:System%20Administrator"
}
다음에 수행할 작업
VMware Cloud Director Service Provider Admin Portal을 사용하여 서비스 계정에 액세스 권한 부여
서비스 계정을 생성하고 애플리케이션이 액세스 토큰을 받기 위한 권한 부여를 요청한 후 VMware Cloud Director Service Provider Admin Portal을 사용하여 토큰을 부여할 수 있습니다.
Created로 다시 변경되며 절차를 다시 시작해야 합니다.
사전 요구 사항
- Service Provider Admin Portal의 서비스 계정 세부 정보에서 클라이언트 ID를 복사합니다.
- 계정을 요청한 애플리케이션이 https://site.cloud.example.com/oauth/provider/device_authorization API 끝점에 대해 OAuth 2.0 Device Authorization Grant RFC 준수 요청을 수행하는지 확인합니다. 디바이스 권한 부여 요청에 대한 자세한 내용은 RFC 8628 섹션 3.1을 참조하십시오.
키 값 client_IDGenerated_Client_ID애플리케이션이 액세스를 요청하면 Service Provider Admin Portal의 서비스 계정 상태가
Requested로 변경됩니다. 애플리케이션은 디바이스 코드, 사용자 코드 및 몇 가지 추가 정보를 수신합니다.샘플 요청:POST /oauth/provider/device_authorization Accept:application/json Content-Type: application/x-www-form-urlencoded Body: client_id=734e3845-1573-4f07-9b6c-b493c9042187
샘플 응답:{ "device_code": "tkhZ0uoUMy5xgjJqRJblIq3-g44xy2Ms6TEpv3Z_fKw", "user_code": "3VL8-SQVJ", "verification_uri": "https://[VCD]/provider/administration/access-control/service-accounts", "expires_in": 3600, "interval": 60 }디바이스는 RFC에 따라 위의 응답(초)
/oauth/provider/token에 지정된 빈도로 폴링해야 합니다. 디바이스는 VMware Cloud Director에서 토큰을 수신하거나 요청 시간이 초과될 때까지 디바이스 코드를 사용해야 합니다.샘플 요청:POST: /oauth/provider/token Accept:application/json Content-Type: application/x-www-form-urlencoded Body: client_id= 734e3845-1573-4f07-9b6c-b493c9042187&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code&device_code=tkhZ0uoUMy5xgjJqRJblIq3-g44xy2Ms6TEpv3Z_fKw
부여 전 샘플 응답:{ "error": "authorization_pending", "error_description": "Device authorization request pending", "error_uri": null, "minorErrorCode": "authorization_pending", "message": "Device authorization request pending", "stackTrace": null }부여 후 샘플 응답:{ "access_token": "eyJhbGciOiJSU…HqJaDud1sVA", "token_type": "Bearer", "expires_in": 2592000, "refresh_token": "SsybukUed8SBP2p1AaFiGJhrntQNWZVX" }액세스 요청을 확인하거나 거부하지 않으면 사용자 코드가 시간 초과됩니다. 시간 초과 기간은 디바이스 권한 부여 요청에 대한 응답에 나타납니다.
애플리케이션과 관리자가 서로에 해당하는 디바이스 코드와 사용자 코드를 사용하는 경우에만 VMware Cloud Director가 애플리케이션에 기본 API 토큰을 부여합니다.
- 애플리케이션에서 사용자 코드를 가져옵니다. 4단계에서 코드를 입력해야 합니다.
프로시저
결과
서비스 요청 상태가 Granted로 변경됩니다. VMware Cloud Director는 서비스 계정에 연결된 애플리케이션에 API 토큰의 형태로 기본 API 토큰을 부여합니다. RFC에 필요한 대로 응답에 포함되며 서비스 계정에서 즉시 사용하기 위한 사용자 세션을 나타내는 OAuth 액세스 토큰입니다. 애플리케이션이 OAuth 액세스 토큰을 즉시 사용하지 않는 경우 구성된 유휴 세션 시간 초과에 따라 세션이 시간 초과됩니다. 또한 서비스 계정이 명시적으로 로그아웃될 수 있으며 보안상의 이유뿐만 아니라 서비스 계정에 대한 좋은 테스트 실행을 제공하여 VMware Cloud Director에 API 호출을 수행하는 것이 좋습니다. 애플리케이션이 API 토큰을 가져오면 상태가 Active로 변경됩니다.
다음에 수행할 작업
- 할당된 서비스 계정 역할, 소프트웨어 ID, 소프트웨어 버전, 클라이언트 URI 또는 할당량 제한을 변경하려면 서비스 계정을 선택하고 서비스 계정 편집을 클릭합니다. 변경 사항은 다음 토큰 새로 고침 시 적용됩니다.
- 부여된 API 토큰이 유효하지 않게 되도록 서비스 계정 액세스를 해지하려면 취소를 클릭합니다. VMware Cloud Director는 모든 활성 세션을 종료합니다. API 토큰을 해지해도 서비스 계정은 삭제되지 않지만 계정 상태가
Created로 변경됩니다. 애플리케이션이 이미 다시 액세스를 요청한 경우 서비스 계정의 상태가Requested로 변경됩니다. 다시 한 번 절차에 따라 계정이Active가 되도록 서비스 계정에 액세스 권한을 부여해야 합니다.
