태그 보관물: microservices

microservices

마이크로 서비스는 사용자 여야합니까? 방법은 무엇입니까? 우리가 논의한

우리는 마이크로 서비스 아키텍처에서 사용자에게 권한을 부여하는 가장 좋은 방법을 결정하려고 노력하고 있으며 마이크로 서비스는 제한된 권한을 갖습니다. 우리 아키텍처는 중앙 인증 서비스를 사용하여 JWT 토큰 발행을 처리합니다.

우리는 다음과 같은 요구 사항이 있습니다.

  1. 사용자는 특정 역할을 수행하도록 제한되어야합니다. 예를 들어, 사용자는 자신이 소유 한 컨텐츠 만 작성 / 수정 / 읽을 수 있어야합니다.

  2. 마이크로 서비스는 필요한 권한으로 만 제한해야합니다. 예를 들어 다른 서비스에서 데이터를 읽기만하면되는 마이크로 서비스는 해당 서비스에 데이터를 쓰는 것이 명시 적으로 금지되어야합니다.

예를 들어, 사용자가 이미지 저장소 서비스에 사진을 업로드 할 수있는 시스템이 있다고 가정합니다. 위치에 자동으로 태그를 지정하는 태그 지정 서비스가 있습니다. 사용자는 자신의 사진 만 CRUD 할 수 있습니다. 태깅 서비스는 이미지 저장소 서비스에서 이미지를 읽을 수 있지만 수정 / 삭제할 수 없습니다.

JWT 토큰을 사용하여 위를 달성하는 좋은 방법은 무엇입니까? 우리가 논의한 몇 가지 솔루션은 다음과 같습니다.

  1. 이미지 저장소 서비스는 2 개의 API를 제공합니다. 하나는 외부에서 사용 가능하고 (사용자에게 CRUD 액세스 권한을 제공) 하나는 내부적으로 사용 가능합니다 (내부 읽기 전용 액세스 제공). 융통성이없는 것 같습니다-다른 내부 서비스가 모든 이미지 (예 : 명시 적 이미지를 자동으로 삭제하는)에 대한 읽기 / 쓰기 액세스가 필요한 경우 어떻게해야합니까?

  2. 사용자의 JWT에서 두 가지 권한을 설정했습니다. 하나는 CRUD_OwnImages이고 다른 하나는 READ_ForAnalysis입니다. 태깅 서비스는 사용자에게 READ_ForAnalysis 권한이 있는지 확인하고, 그렇다면 적절한 요청을합니다. 사용자 자신의 이미지에서 CRUD 작업을 위해 CRUD_OwnImages가 있는지 확인하는 또 다른 마이크로 서비스가 있습니다. 이로 인해 각 마이크로 서비스에 대한 책임이 사용자에게 필요한 조치로 제한됩니다. 이미지 저장소는이 접근 방식으로 각 마이크로 서비스를 제한 할 방법이 없으므로 잠재적으로 결함이 있고 오류가 발생하기 쉽습니다.

  3. READ_ForAnalysis를 권한으로 사용하여 태그 지정 마이크로 서비스에 자체 사용자를 제공합니다. 그런 다음 태깅 서비스가 이미지 저장소에서 이미지를 요청하면 해당 이미지에 액세스 할 수는 있지만 이미지를 수정할 수는 없습니다. 사용자의 사용자에게는 CRUD_OwnImages 권한 만 있으므로 프런트 엔드에서 자신의 이미지 만 검색하고 액세스 할 수 있습니다. 다른 서비스가 모든 데이터에 CRUD를 필요로하는 경우 CRUD_AllData 또는 이와 유사한 것을 제공 할 수 있습니다. 우리는 각 서비스가 현재 여러 데이터에 복제되는 논리가 아닌 자체 데이터에 대한 책임이 있기 때문에이 접근 방식을 좋아하지만, 서비스에 사용자 권한과 마이크로 서비스 권한이 모두 필요한 경우 어떻게해야합니까? 두 개의 JWT 토큰 (사용자 및 마이크로 서비스 모두)을 안전하게 보낼 수 있습니까? 권한을 안전하게 결합하여 전송할 수있는 방법이 있습니까? 예 :

사용자 정보가 더 다운 스트림 (2 개 또는 3 개의 마이크로 서비스) 떨어져 필요할 경우 문제가 악화됩니다. 우리는 필요한 조치로 자신을 제한하고 명시 적으로 표현하지 않는 것이 개별 마이크로 서비스에 달려 있다고 가정합니까?



답변

일반적으로 가능한 많은 작업을 실제 사람과 연결해야합니다. 사람들이 올바르게 인증하도록하고 일관된 단일 인증 전략을 추진하며 응집력있는 감사 추적을 제공하는 데 중요한 부분입니다.

그리고 일반적으로 마이크로 서비스에 대한 세 가지 종류의 시나리오가 있습니다.

1. 사용자가 들어 와서 사진을 업로드하고 태그를 지정해야합니다. 큰. 사진 서비스는 JWT를 따라 태깅 서비스로 전달할 수 있으며 (또는 의존 방향에 따라 그 반대도 가능) 하위 작업을 수행 할 권한이없는 사용자는 적절한 조치를 취합니다 (태그없이 사진을 업로드 할 수 있음) , 아마도 오류를 반환하거나 다른 것).

2. 사용자가 들어 와서 사진을 업로드하며 태그가 필요하지만 지금은 아닙니다. 멋있는. 이제 정상적으로 사진을 처리합니다. 나중에 태깅이 발생하면 (이벤트 / 메시지 처리, CQRS 스타일 명령 처리, 일부 주기적 작업 처리 등) 태깅 서비스는 사용자를 가장 한 다음 (공인 비밀을 사용하여 인증에서 사용자 정의 JWT를 요청함으로써) 원래 요청자를 대신하여 하위 작업 (모든 권한 및 제한) 이 방법에는 문제가 발생하지 않으면 사용자에게 오류를 제공하기 어려운 비동기 작업의 일반적인 문제가 있지만 교차 서비스 작업에이 패턴을 사용하는 경우 이미 해결 한 것입니다.

3. 일부 하위 시스템은 사용자의 상황을 벗어난 작업을 수행해야합니다. 오래된 이미지를 보관하는 야간 작업이있을 수 있습니다. 태그를 통합해야 할 수도 있습니다 …이 경우, 각 액터마다 권한이 제한되고 감사 내역에 대한 고유 한 ID를 가진 자체 의사 사용자가 필요합니다.

사용할 시나리오는 시나리오, 요구 사항 및 위험 허용 범위에 따라 다릅니다. 물론 이것들은 불완전한 광범위한 스트로크 일반화입니다.

그러나 일반적으로 마이크로 서비스 자체는 가능한 경우 사용자가 아니어야합니다.


답변