[csp]Hierarchy Architecure & API/API Gateway

안녕하세요. GCP 환경 내 프로젝트의 계정 생성 및 리소스 권한 설정 등 정책 관련 부분을 알아보며 GCP와 AWS의 계층 구조와 API 및 API Gateway 등 관련 내용에 대해 간단히 정리한 글입니다.

IAM

1. GCP

• ID 및 액세스 관리는 GCP와 같은 클라우드 인프라 환경에서 가장 중요한 보안 제어 중 하나입니다 . 리소스의 프로비저닝, 디프로비저닝 및 조작을 포함하여 수행되는 거의 모든 작업이 API 호출이므로 악의적인 행위자가 환경에 침투하기 위해 필요한 모든 권한은 잘못된 ID에 대한 잘못된 바인딩 또는 손상된 ID입니다. 이런 이유로 사람과 서비스를 포함한 모든 ID에 대해 항상 최소 권한을 유지해야 합니다.[참고]

illustration of the objects relevant to IAM in GCP

• GCP IAM은 위 그림과 같이 Identity와 Role 간의 바인딩을 통해 이뤄집니다.
• 여러 멤버 존재(사용자 계정, 서비스 계정, 그룹, 도메인)와 여러 권한(basic/pre defined/custom role)을 바인딩해줍니다.

2. AWS

• 지난 블로그 글 참고 : [aws] IAM & Organizations

— AWS IAM 서비스 블로그 글 중,

“AWS API를 호출할 때마다 IAM을 호출하여 권한을 확인해야 하기 때문에 IAM 팀은 처음부터 가용성과 확장성에 초점을 맞췄습니다. 2011년에는 “호출자가 할 수 있을까?” 싶었던 기능은 초당 수천 개의 요청을 처리했습니다. 현재 새로운 서비스가 계속 등장하고 AWS 고객 기반이 계속 증가함에 따라 이 기능은 전 세계적으로 초당 4억 건이 넘는 API 호출을 처리합니다.”

Hierarchy Architecure

1. GCP

• GCP Organization 리소스는 조직(예: 회사)을 나타내며, Google Cloud 리소스 계층 구조의 루트 노드입니다(있는 경우). 조직 리소스는 폴더 및 프로젝트 리소스의 계층적 상위 항목입니다. 조직 리소스에 적용된 IAM 액세스 제어 정책은 조직의 모든 리소스에 대한 계층 구조 전체에 적용됩니다.

GCP Resource hierarchy

• 프로젝트는 <APP_NAME>-development, <APP_NAME>-staging, <APP_NAME>-production과 같은 애플리케이션의 동일한 배포(예: 개발/테스트/스테이징/프로덕션)와 관련된 리소스를 관리하는 데 사용되는 atomic container입니다. 또한 청구 계정 과 일대일 관계가 있으므로 리소스의 기본 청구 단위이기도 합니다 .

Resource Hierarchy in GCP, Source: Google

Identities

• Google Cloud ID 는 “사용자 및 그룹을 중앙에서 관리하는 IDaaS(Identity as a Service) 솔루션”입니다. 기본적으로 사용자 및 그룹 개체를 생성하고 MFA(보안 요소) 및 애플리케이션 액세스와 같은 매개 변수를 관리하는 ID 공급자(IdP)입니다. 편의상 이 서비스를 Google Cloud ID라고 부르지만 Google Workspace라고 알고 있을 수도 있습니다.

Google Workspace 사용자

• Google Workspace에서 조직의 사용자 개체를 관리합니다. 사용자는 이메일로 고유하게 식별되며 MFA 및 애플리케이션 액세스와 같은 정책을 설정하는 데 유용한 조직 단위 (OU) 로 나뉩니다 . 그러나 OU는 Google 리소스에 대한 IAM 액세스 관리와 관련이 없습니다.

Google 그룹스

• GCP 리소스에 대한 사용자 액세스를 관리하는 관련 메커니즘은 Google 그룹스입니다. Google 그룹스 는 전통적 으로 메일링 리스트를 위한 솔루션으로 시작했고(여전히 이 목적으로 자주 사용됨) 이메일 계정으로 고유하게 식별됩니다.

GCP의 서비스 계정

• 서비스 계정은 GCP에서 매우 중요한 용도로 사용되는 프록시 ID 유형입니다. 프록시 ID의 의미는 리소스와 같은 다른 엔터티가 이를 사용하여 다른 리소스에 액세스할 수 있음을 의미합니다.
• GCP 내에서 동작하는 application이나 VM이 특정 리소스에 대해 api call을 사용자 대신에 날려야하는 경우가 있는데 이때 필요합니다.
• IAM 정책은 누가 어떤 리소스에 어떤 권한을 갖는지 정의하는 것으로 정책은 도메인, 폴더, 프로젝트에 연결 가능하며 API로 연결됩니다.
• 도메인/폴더/프로젝트 경우, resource manager로 관리합니다.

GCP Resource Manager

• Google Cloud는 조직, 프로젝트와 같이 다른 Google Cloud 리소스를 그룹화하고 계층별로 구성할 수 있는 컨테이너 리소스를 제공합니다. 이러한 계층별 조직을 사용하면 액세스 제어 및 구성 설정과 같은 리소스의 일반 측면을 관리할 수 있습니다. Resource Manager API를 사용하면 이러한 컨테이너 리소스를 프로그래매틱 방식으로 관리할 수 있습니다.
• 참고 : GCP Resource Manager API

2. AWS

AWS Organizations는 여러 AWS 계정을 생성하고 중앙에서 관리하는 조직 으로 통합할 수 있는 계정 관리 서비스입니다. AWS Organizations에는 비즈니스의 예산, 보안 및 규정 준수 요구 사항을 더 잘 충족할 수 있는 계정 관리 및 통합 결제 기능이 포함되어 있습니다. 조직의 관리자는 조직에 계정을 만들고 기존 계정을 조직에 초대할 수 있습니다.

AWS Organizations 용어 및 개념

고객은 일반적으로 단일 AWS 계정과 여러 사용자를 사용했지만 여러 사업부 및 워크로드를 수용하기 위해 AWS Organizations 및 여러 계정을 사용하도록 권장합니다.

API Gateway

위에서도 언급했듯 Public Cloud 환경 내 리소스의 프로비저닝, 디프로비저닝 및 조작을 포함하여 수행되는 거의 모든 작업이 API 호출로 이뤄집니다.

• API는 한 애플리케이션이 다른 애플리케이션의 기능이나 데이터를 쉽게 사용할 수 있게 하는 인터페이스입니다.
• GCP API gateway : API 게이트웨이를 사용하면 서비스 구현에 관계없이 모든 서비스 간에 일관적인 잘 정의된 REST API를 통해 백엔드 서비스에 대해 보안 액세스를 제공할 수 있습니다. [gcp api gateway docs]
• Amazon API Gateway : Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스입니다. API는 애플리케이션이 백엔드 서비스의 데이터, 비즈니스 로직 또는 기능에 액세스할 수 있는 “정문” 역할을 합니다. API Gateway를 사용하면 실시간 양방향 통신 애플리케이션이 가능하도록 하는 RESTful API 및 WebSocket API를 작성할 수 있습니다. API Gateway는 컨테이너식 서버리스 워크로드 및 웹 애플리케이션을 지원합니다. [AWS API gateway]
• Nginx API Gateway : 최고의 고성능 경량 리버스 프록시 및 로드 밸런서인 NGINX는 API 트래픽을 처리하는 데 필요한 고급 HTTP 처리 기능을 갖추고 있습니다. 따라서 NGINX는 API Gateway를 구축하는 데 이상적인 플랫폼입니다.[Nginx API gateway]

위와 같이 API Gateway에서는 Rest, WebSocket/HTTP API 등 통신의 방향성에 맞게 단방향인지, 양방향인지에 따라 처리해주게됩니다.

보통 클라이언트가 서버에 요청을 보낼 때 Rest API를 사용하게 되고 클라이언트와 서버가 서로 요청을 주고 받는 실시간성이 중요한 경우 WebSocket/HTTP API를 사용하게됩니다.

Rest API

REST API 사용 목적

• REST API는 Stateless 통신을 지원하기 위해 존재합니다. 이러한 통신에는 지속적인 데이터 전달 이 필요하지 않습니다 . 데이터는 웹 애플리케이션에서 필요할 때만 요청됩니다. REST의 기능을 자판기의 기능과 비교할 수 있습니다. 자판기는 요청하지 않는 한 상품을 제공하지 않습니다. 명령을 받았을 때만 작동합니다.

WebSocket in action

Websocket 사용 목적

• 광범위하게 WebSocket은 애플리케이션이 지속적이거나 중단 없는 데이터 전달을 요구할 때 사용됩니다. 예를 들어 채팅 애플리케이션은 항상 앱을 수신해야 합니다. 최종 사용자가 앱을 열지 않더라도 메시지는 전달되어야 합니다. WebSocket만이 이러한 지속적인 통신을 가능하게 할 수 있습니다. 중단 없는 데이터 전달에서 REST를 사용하면 자원이 많이 소모되는 반면 WebSocket은 작업을 단순화합니다.

클라이언트-마이크로 서비스 간 직접 통신 대신 API 게이트웨이를 고려하는 이유(참고 MS docs)

• 마이크로 서비스 아키텍처에서 클라이언트 앱은 일반적으로 둘 이상의 마이크로 서비스에서 제공하는 기능을 사용해야 합니다. 해당 사용이 직접 실행되는 경우 클라이언트는 마이크로 서비스 엔드포인트에 대한 여러 호출을 처리해야 합니다.

Q) 애플리케이션이 개선되고 새 마이크로 서비스가 도입되었거나 기존 마이크로 서비스가 업데이트되면 어떻게 되나요?

A) 애플리케이션에 여러 마이크로 서비스가 있는 경우 클라이언트 앱에서 많은 엔드포인트를 처리하는 것은 큰 문제일 수 있습니다. 클라이언트 앱은 해당 내부 엔드포인트에 결합되므로 나중에 마이크로 서비스가 개선되면 클라이언트 앱에 큰 영향을 줄 수 있습니다. 따라서 중간 수준 또는 간접 참조 계층(게이트웨이)을 포함하면 마이크로 서비스 기반 애플리케이션의 경우 편리할 수 있습니다.

• 여러 클라이언트 앱이 있는 대규모 또는 복잡한 마이크로 서비스 기반 애플리케이션을 디자인하고 빌드하는 경우 API 게이트웨이가 고려할 좋은 방법일 수 있습니다.

사용자 지정 서비스로 구현된 API 게이트웨이 사용

API 게이트웨이 패턴과 클라이언트-마이크로 서비스 간 직접 통신 - .NET

 

blog migration project

written in 2022.11.27

https://medium.com/techblog-hayleyshim/csp-hierarchy-architecure-api-b69c57a729cc