Spring Boot에서 Key Vault 값을 Managed ID를 사용하여 읽습니다.

이번에는 Managed ID (관리 ID)에 관한 것입니다. Managed ID에 대해서는, 다음에 확실히 해설이 있습니다만, 간단하게 말해 버리면, 예를 들어, WebApps 로부터 SQL DB , 스토리지, Key Vault 등 다른 컴퍼넌트의 액세스에 패스워드등의 시크릿을 필요로 하지 않는 구조가 됩니다.

물론, WebApps에서 다른 Azure 리소스에 마음대로 액세스할 수 있는 것은 아니므로, Azure에서 해야 할 단계를 밟아 설정을 해 두어야 합니다. 설정은 포털 외에도 Azure CLI와 같은 명령줄 도구에서도 가능합니다.

# WebApps + Key Vault의 예
앞의 기사의 계속이라고 하는 것은 아니지만, 전제로 하는 환경은, Spring Boot + WebApps/Key Vault 로 시험해 보고 싶습니다.

# WebApps에서 설정
포털에서 확인하면 WebApps에는 "ID"라는 관리 항목이 있습니다. Managed ID를 사용하려면 여기에서 이 기능을 선택합니다.

이 기능을 켜면 어떤 일이 발생하는지 Azure AD에서 이 WebApps에 연결된 서비스 보안 주체라는 자격 증명을 몰래 만들 수 있습니다. WebApps 측의 설정은 이것뿐입니다. 이 때 표시되는 객체 ID (클라이언트 ID)는 나중에 필요하므로 메모해 둡니다. 또한 서비스 주체의 이름은 WebApps의 이름과 동일합니다. 나중에 액세스 권한을 설정하는 곳에서 사용합니다.

# Key Vault에서 설정
Key Vault에는 키, 비밀, 인증서의 세 가지 유형을 저장할 수 있습니다. 이른바 구성 설정값과 같은 키 밸류형의 것은 비밀에 저장합니다. 다음의 클래스를 준비했을 때, kvconfig.messsage를 설정하지 않으면 안됩니다만, Key Vault 에서는 「닷」을 사용할 수 있으므로, kvconfig-message로 대용합니다.

@Configuration
@ConfigurationProperties("kvconfig")
public class KvConfig {
    private String message;


    public String getMessage() {
        return this.message;
    }
    public void setMessage(String message) {
        this.message = message;
    }
}

비밀 만들기를 선택하고 라는 hirakegema값을 정의합니다.

그런 다음 이 Key Vault에 대한 사용 권한을 설정합니다. 액세스 정책을 열고 정책을 추가합니다. 키, 비밀, 인증서에 대해 각각 CRUD + List와 같은 권한 설정을 할 수 있습니다. 여기에서는 비밀의 읽기 권한이 필요하므로 읽기와 목록을 부여합니다 (목록에 대한 액세스 권한이 없으면 실패하므로주의). 권한 부여는 최저로 하고 낭비하게 편집 권한등을 주는 것은 그만둡시다.

프린시펄의 선택은 WebApps의 이름을 지정하면 같은 이름의 서비스 프린시펄을 지정할 수 있습니다.

# Spring Boot 앱 설정
종속성 azure-spring-boot-starter-keyvault-secrets을 설정합니다.

    <dependency>
      <groupId>cohttp://m.azure.spring</groupId>
      <artifactId>azure-spring-boot-starter-keyvault-secrets</artifactId>
    </dependency>

application.properties에는 다음 정보가 필요합니다.

임차인 ID
Key Vault URL
클라이언트 ID(Web Apps에서 Managed ID를 켤 때 표시되는 GUID)
azure.keyvault.enabled=true
azure.keyvault.client-id=ManagedIDのオブジェクトID
azure.keyvault.tenant-id=Azure AD のテナントID
azure.keyvault.uri=https://xxxxxxx.vault.azure.net/
컨트롤러 클래스는 구성 클래스를 DI하고 표시하기만 하면 됩니다.

@RestController
public class KvController {
    private KvConfig config;

    public KvController(KvConfig config) {
        this.config = config;
    }
    @GetMapping("kv")
    public String getMessage() {
        return config.getMessage();
    }
}

# 배포
배포한 엔드포인트에 curl 로 API를 두드려 봅시다. hirakegoma가 표시되면 제대로 작동하고 있습니다. 이제 Key Vault에 액세스하기 위해 더 이상 키를 관리할 필요가 없습니다.

$ curl https://config-sample-1620013095057.azurewebsites.net/kv

# 잘 동작하지 않으면
제대로 작동하지 않으면 대체 설정이 실패하고 Spring Boot를 시작할 때 예외가 발생하는 경우가 많습니다. 나도 여러 번 해냈다. 이 경우 App Service에서 문제 진단 및 해결 메뉴를 열고 Application Log를 참조하면 시작 시 예외를 볼 수 있으므로 참고하십시오.

# 로컬 환경에서 사용하려는 경우
.NET 에서는 Visual Studio 자신이 인증한 정보를 사용해 Key Vault 에 액세스 해 줍니다만, Java 의 이 시나리오의 경우는, Azure CLI 의 인증 정보등을 마음대로 사용해 주지 않습니다.

이 경우 수동으로 서비스 보안 주체를 만들고 Key Vault 액세스 권한을 설정해야 합니다. Azure CLI는 다음 명령으로 만들 수 있습니다. 작성한 서비스 프린시펄은, 전술한 Key Vault 의 설정으로 액세스권을 설정할 수 있습니다.

az ad sp create-for-rbac --name xxxxxxxxx

명령을 실행하면 응용 프로그램 ID (클라인 및 ID)와 암호가 표시되므로 각각으로 설정 client-id합니다 client-key.

azure.keyvault.enabled=true
azure.keyvault.client-id=ManagedIDClientID
azure.keyvault.tenant-id=Azure AD tenantID
azure.keyvault.uri=https://xxxxxxx.vault.azure.net/
azure.keyvault.client-key=클라이언트key

이것으로 로컬 실행할 수 있다고 생각합니다.

# 요약
이번에는 먼저 WebApps에 배포한 예를 설명했지만 로컬 환경에서 하는 편이 간단하다고 생각합니다. 예기치 않은 설정 실수로 시간을 허물거나 하기 때문에 예외 메시지는 제대로 읽어보자