마이크로 서비스 용 공개 키 저장소를 만드는 방법은 무엇입니까?

Question

나는 docker 환경에서 일련의 마이크로 서비스를 구현했다. 그리고이 서비스들 각각은 JWT 토큰을 사용하여 서로 통신합니다. 서비스 A는 B에게

1. 서비스 및 A에 서비스를 호출 할 때, 자신의 개인 키를 사용하여 토큰에 서명하고 B에게
2. 서비스 B를 서비스에 전달, 공개 키 저장소에서 ServiceA의 공개 키를 가져오고 토큰을 확인

공개/개인 키 생성 프로세스는 마이크로 서비스 자체에 의해 수행되고 공개 키 저장소에 공개 키를 전달합니다. 그래서 공개 키 저장소가 할 가지고있는 유일한 것은,

1. 스토어 공개 키가 서비스로 보낼 수는
2. 는 내가 뭘 하겠어 것은 비슷합니다 요청

의 서비스에 올바른 공개 키를 보내기 이 다이어그램에 표시된 내용으로 공개 키 저장이 종류의 표준 구현 https://www.youtube.com/watch?v=dBdZrw2pPvc&t=462s있다

그래서 내 문제가있다 :

나는에서 위의 이미지를 가지고? 그렇다면 그들은 무엇입니까?

Answer 1

보안이 중요하지 않은 경우 :

• 레디 스 : https://redis.io/
• 영사 : https://www.consul.io/
• Etcd : https://coreos.com/etcd
• 사육사 :

보안이 중요한 경우 https://zookeeper.apache.org/ :

,

• 볼트 : https://www.vaultproject.io/
• 유색인 : https://www.conjur.com/
• Thycotic : https://thycotic.com/
• 도커 비밀 : https://docs.docker.com/engine/swarm/secrets/

은 솔직히 무리 더 많은 옵션이 있지만이는 가장 유명한 중 일부와 개발자 커뮤니티에서 확인할 수 있습니다.

Answer 2

공개 : 나는 Conjur의 CTO입니다.

이

1. 서비스 및 A의 컨테이너가 시작 :
   워크 플로를 생각해 보자.
2. 새 키 쌍을 생성합니다.
3. 공개 키를 공개 키 저장소에 제출합니다.
4. 공개 키 저장소는 공개 키를받습니다.
5. 공개 키 저장소는 수신 한 공개 키를 ID "service-a"와 연관시킵니다.
6. 서비스 A는
7. 서비스 B가 서비스 A.
8. 키 저장소 공용 키 (들)를 제공의 공지 된 공개 키 (들)에 대한 키를 저장 요청 서비스 B.에 대한 요청을 서명.
9. 서비스 B는 서명이 키 중 하나와 일치하는지 확인합니다.
   • 스토어 부정 조작 방지 방법으로 공개 키 :

공개 키 저장소는 확인을해야합니다.

각 공개 키를 위조 방지 방식으로 서비스 ID에 연결합니다.

관리자가 키 저장소를 조작 할 수있는 방법을 제공합니다 (예 : 사용하지 않은 컨테이너의 유도 키).

발생한 모든 사항에 대한 감사 기록을 보관하십시오.

하지만 또 다른 비트가 꽤 있습니다. 단계 (5)에서, 키 스토어가 서비스 A에 대한 키를 수신하면, 키가 실제로는 가짜로부터가 아니라 서비스 A로부터 오는 것인지를 검증 할 필요가있다. 즉, 요청을 인증해야합니다.

이 작업 방법은 인프라 세부 정보에 따라 다릅니다. Raw Docker를 사용하는 경우 (Kubernetes와 반대), 서버의 에이전트를 사용하여 컨테이너의 IP 주소를 시스템의 컨테이너 목록 (docker ps)과 연관시킬 수 있습니다. 그러면 서비스의 신원을 알려주는 컨테이너의 이미지가 표시됩니다.

이 문제에 대한 많은 미묘함이 있으며 솔루션은 각 컨테이너 환경에 따라 약간 다릅니다.