SPIRE Upstream Authority pluggin의 등장과 JWT SVID 문제 해결

배경.
SPIRE에서는 Node Attestation과Workload Attestation 등 몇 가지 기능에 대해 pluggin 형식으로 임의로 교체할 수 있다.pluggin은 삽입식도 있고 다른 2진법으로 제공될 수도 있습니다.
참조: https://spiffe.io/docs/latest/spire/developing/extending/

2020년 12월 현재 최신spire버전은 0.1.2이지만 0.1.0에 발표될 때 Upstream Authority pluggin이라는 새로운pluggin인터페이스를 추가했다.
Upstream Authority pluggin은 기존의 UpstreamCA pluggin을 교체하기 위해 추가되었습니다.
이 대목은'KobeCon+Cloud Native Con North America 2020 Virtual'의 코-located 행사에서 개최되는'Production Identity Day: SPIFE+SPIRE hosted by CNCF'세션에서도 언급됐다.

SPIRE Project Updates: https://youtu.be/VJCso4FzM9U

원래 pluggin의 하나로 UpstreamCA pluggin의 인터페이스를 제공하였는데, 이는 SPIRE Server가 보유한 내부 CA를 기존의 외부 PKI와 합치기 위한 pluggin이다.상류CA의 선택에 따라 시행 방식도 다르다.예를 들어 SPIRE Server에서 발행하는 X.509 증명서(X.509 SVID)에 대해 Vault의 PKI Secret Engine를 상위 PKI Tree의 Leaf 증명서로 처리하려면 UpstreamCAvault pluggin을 사용합니다.
또한 SPIRE Server의 사양은 각 프로그램에 SVID 서명을 위한 기밀 키가 있으며 KeyManager pluggin이 관리합니다.빌딩의pluggin 제공disk과memory.

따라서 SPIRE는 SVID에서 X.509 인증서와 JWT 두 가지 형식을 지원하고 서로 다른 SPIRE Server에서 발행하는 SVID는 각각 다른 키로 서명한다.
X.509 인증서의 경우 UpstreamCA pluggin을 사용하여 각 SPIRE CA를 동일한 경로로 연결할 수 있습니다.인증서를 검증하는 측이 Upstream CA를 신뢰할 수 있다고 생각하면 서버마다 키가 다르더라도 인증서의 검증에 문제가 없을 것입니다.

다른 한편, JWT의 경우 여러 SPIRE Server가 서로 다른 키 서명을 사용하는 것이 문제입니다.이는 SPIRE의 규격에 따라 SVID는 SPIRE Server가 자체로 발행하고 JWT 자체는 트러스트체인을 통해 검증하는 메커니즘이 없으며 SPIRE Agent는 하나의 SPIRE Server에만 연결되어 있기 때문이다.그리고 UpstreamCA pluggin은 X.509 인증서의 구조를 위한 pluggin일 뿐 JWT를 고려하지 않았다고 말했다.

두 번째 SPIFFT Meetup Tokyo가'Charllenging Multiple SPIRE Servers'를 발표하면서 언급한 내용이다.관심 있으면 슬라이드나 유튜브에 올라온 동영상 파일을 보십시오.
SPIRE 커뮤니티에서 논의가 진행 중이며 JWT SVID 문제를 해결하기 위해 등장하는 것은 Upstream Authority pluggin이다.
UpstreamAuthority plugin
Upsstream Authority pluggin**에는 JWT 서명 검증 키를 배포하는 방법이 새로 추가되었습니다.

message PublishJWTKeyRequest {
    spire.common.PublicKey jwt_key = 1;
}

message PublishJWTKeyResponse {
    repeated spire.common.PublicKey upstream_jwt_keys = 1;
}

service UpstreamAuthority {
    ...
    rpc PublishJWTKey(PublishJWTKeyRequest) returns (stream PublishJWTKeyResponse);
    ...
}

자신이 발행한 JWT의 서명 검증 키를 Upstream Authority에 등록하면 Upstream Authority의 서명 검증 키가 응답으로 반환됩니다.SPIRE Server는 키를 업데이트할 때마다 Upstream Authority pluggin의 PublithJWTKey 메서드를 호출하여 새 키를 등록합니다.

단, 이렇게 하면 새 열쇠를 등록할 때만 최신 검증 키 묶음을 얻을 수 있기 때문에 정기적으로 검증 키 묶음을 받아야 한다.
예를 들어 Upstream Authority는 최신 인증서 키 집합을 가져오는 API를 제공합니다.plugen이 정기적으로 가져오는 방법과 pluggin이 정기적으로 Publith JWTKey를 호출하지만 Upstream Authority는 이미 등록된 키를 목록에 추가하지 않고 최신 인증서 키 집합을 되돌려줍니다.
현재 Publish JWTKey 방법을 실시하고 있는pluggin은 Upstream Authorityspirepluggin뿐입니다. 이것은 정기적으로 다른 검증 키를 받는 묶음으로 항상 모든 SPIRE Server가 다른 SPIRE Server에 등록할 수 있는 최신 검증 키의 구조가 됩니다.

이 새로운 방법의 추가를 통해 작업 부하가 어느 SPIRE Server에서 모든 SPIRE Server의 검증 키를 받을 수 있는지, 여러 대의 SPIRE를 구성하는 상황에서도 X.509 인증서, JWT 임의의 형식의 SVID를 처리할 수 있는지 큰 과제가 해제되었다.

업스트림 어트리지 플러그인의 등장으로 업스트림 CA 플러그인은 디프리캣드로 바뀌었다.현재 빌딩의 pluggin은 모두 Upstream Authority pluggin으로 옮겨졌다.
그러나 앞서 언급한 바와 같이 모든 Upstream Authority plugen이 JWT SVID를 처리할 수 있는 것은 아닙니다.JWT SVID를 처리하는 요구가 있으면 현재 유일하게 Publish JWTKey를 실시하는 Upstream Authorityspirepluggin을 사용하여 SPIRE를 구성해야 합니다.'Nested SPIRE'로 불리는 이 구성은 Upstream Authority로 움직이는 Upstream SPIRE Server와 이를 참조하는 Downs tream SPIRE Server로 구성된다.

내일 프로젝트는 실제로 Nested SPIRE를 구성하고 싶습니다.