API Gateway 인증

Yong Qian

November 25, 2022

Technology

API 게이트웨이에서의 인증 및 인가의 중요성

API 게이트웨이의 핵심 기능은 API 소비자와 API 제공자를 연결하는 것으로 요약할 수 있습니다.

실제로 익명 접근을 허용하는 몇몇 API를 제외하고, 제공자는 종종 소비자를 제한합니다: 자격을 갖춘 소비자만이 API에 접근할 수 있습니다. 또한 제공자는 서로 다른 소비자에 대해 동일한 접근 정책을 적용하지 않을 수 있습니다. 예를 들어, 소비자 A와 B 모두 /send_mail API에 접근할 수 있지만, 분당 호출 빈도는 다르게 계산되어야 할 수 있습니다.

위의 두 가지 점에서 볼 때, API 게이트웨이 수준에서 API 소비자의 신원을 식별하고 검증하는 것이 매우 중요합니다. 아래에서는 오픈소스 API 게이트웨이 Apache APISIX가 소비자 인증을 구현하는 방법과 기업에서 널리 채택된 인증 방법을 소개하고, APISIX의 사용자 인증 시스템이 다른 보안 기능과 결합하여 API 게이트웨이의 보안을 더욱 강화하는 방법을 설명하겠습니다.

api gateway authentication

Apache APISIX의 인증 및 인가

전통적인 HTTP 프록시는 요청 도메인 및 클라이언트 IP와 같은 대략적인 수단으로 요청자를 식별할 수 있지만, 이는 API 게이트웨이에는 충분하지 않습니다. 우리는 점점 더 복잡해지는 비즈니스 요구 사항을 해결하기 위해 더 정교한 인증 방법이 필요합니다. APISIX가 전통적인 프록시에 비해 가지는 주요 장점 중 하나는 유연한 플러그인 확장 기능입니다. 이는 사용자 인증을 위한 플러그인 컬렉션을 포함하며, 구현 방법에 따라 두 가지 범주로 나눌 수 있습니다:

  1. 외부 인증 서비스와의 인터페이스

external auth service

  1. APISIX가 설계한 Consumer 객체를 통한 내부 게이트웨이 인증

internal auth

이 두 가지 인증 방법을 순서대로 소개하겠습니다.

외부 인증 서비스와의 인터페이스

기업이 API 게이트웨이를 도입하기 전에, 시스템 내에 별도의 인증 서비스가 배포되어 있는 경우가 많습니다. 그렇다면 APISIX를 기존 인증 서비스와 어떻게 연동할 수 있을까요? APISIX는 다양한 외부 인증 서비스와 연동하여 인증을 완료할 수 있도록 하는 일련의 플러그인을 제공합니다.

예를 들어, openid-connect 플러그인을 사용하여 OIDC 프로토콜을 지원하는 모든 인증 서비스와 연동할 수 있습니다. 다음은 keycloak 서비스와 연동하는 샘플 구성입니다:

curl http://127.0.0.1:9180/apisix/admin/routes -H "X-Api-Key: your-API-key" -XPOST -d '
{
    "uri":"/*",
    "plugins":{
        "openid-connect":{
            "client_id":"apisix", // keycloak 클라이언트 생성 시 생성됨
            "client_secret":"d5c42c50-3e71-4bbe-aa9e-31083ab29da4",
            "discovery":"http://keycloak:8080/auth/realms/apisix_test_realm/.well-known/openid-configuration", // keycloak OpenID 엔드포인트
            "scope":"openid profile",
            "bearer_only":false,
            "realm":"apisix_test_realm",
            "introspection_endpoint_auth_method":"client_secret_post",
            "redirect_uri":"http://127.0.0.1:9080/"
        }
    },
    "upstream":{
        ...
    }
}'

내부 게이트웨이 인증

Consumer

consumer

다양한 소스의 요청이 API 게이트웨이에 도달하면, 게이트웨이는 이러한 호출자를 식별해야 합니다. Apache APISIX는 특정 유형의 서비스 호출자를 나타내기 위해 "Consumer" 개념을 제안했습니다.

Consumer 객체는 사용을 위해 인증 플러그인을 구성해야 합니다. 가장 간단한 key-auth 플러그인을 예로 들어보겠습니다:

$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "auth-jack"
        }
}'

위 구성은 요청이 지정된 키(auth-jack)를 포함할 때, 현재 요청이 Consumer - jack과 연결됨을 의미합니다. 보다시피, Consumer에 구성된 인증 플러그인은 지정된 인증 메커니즘 하에서의 신원 증명입니다. key-auth 플러그인에서 키는 소비자를 식별하는 증명이며, basic-auth 플러그인의 사용자 이름과 비밀번호와 유사합니다.

라우트에 인증 플러그인 구성

Consumer를 통해 증명 정보를 특정 소비자와 연결한 후, 해당 라우트에서도 인증 플러그인을 활성화해야 합니다:

$ curl http://127.0.0.1:9180/apisix/admin/routes/orders -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "uri": "/orders",
    "plugins": {
        "key-auth": {
            "header": "Authorization"
        }
    }
}'

위 구성은 /orders 라우트에서 key-auth 플러그인을 활성화하며, 인증 효과는 다음과 같습니다:

$ curl http://127.0.0.1:9080/orders -H 'Authorization: auth-jack' -i
HTTP/1.1 200 OK
...
$ curl http://127.0.0.1:9080/orders -H 'Authorization: wrong-key' -i
HTTP/1.1 401 Unauthorized
...
{"message":"Invalid API key in request"}

사용자의 요청이 이 라우트에 도달하면, APISIX는 Authorization 헤더를 통해 사용자가 제공한 키를 얻으려고 시도합니다. 키를 얻지 못하거나 얻은 키가 유효하지 않은 경우, 요청은 게이트웨이에 의해 직접 거부되어 업스트림 서비스를 보호합니다.

위의 두 가지 인증 방법에서 인증 플러그인이 전체 시스템의 핵심이며, 그 풍부함은 사용자가 API 게이트웨이를 선택하여 인증을 구현하는 데 중요한 요소입니다. 다음은 주요 인증 방법과 각각의 장단점을 참고할 수 있도록 정리한 것입니다.

주요 인증 방법

인증 및 인가는 컴퓨터 세계에 진입한 이래로 존재해 온 기본 메커니즘으로, 수년간의 반복을 통해 매우 다양한 분야로 발전했습니다. APISIX의 플러그인 메커니즘은 다양한 인증 방법을 구현하는 개발 비용을 크게 줄였습니다. 다음은 APISIX에서 이미 지원하는 주요 인증 방법 중 일부입니다:

Key Auth

Key Auth는 모든 인증 플러그인 중 가장 간단하지만, 실제 시나리오에서 풍부한 응용이 가능합니다. 예를 들어, 유료 소프트웨어의 라이선스, 오픈 API 플랫폼에서 개발자를 식별하는 토큰 등은 모두 Key Auth로 쉽게 구현할 수 있습니다. 또한 APISIX의 완전 동적 구성 및 할당 기능을 기반으로 키를 빠르게 생성 및 취소할 수 있으며, 실시간으로 적용됩니다.

Basic Auth

Basic Auth는 사용자 이름과 비밀번호를 기반으로 한 인증 방법으로, 웹 로그인 시나리오에서 자주 사용됩니다. 예를 들어, 웹사이트의 관리자 백엔드는 관리자 로그인 후 사용할 수 있으며, 여기서 Basic Auth를 사용하여 인증할 수 있습니다.

LDAP

LDAP(Lightweight Directory Access Protocol)는 X.500 표준을 기반으로 한 경량 파일 접근 프로토콜로, IP 프로토콜을 통해 분산 정보 디렉토리의 접근 제어 및 유지 관리를 제공합니다. LDAP를 사용하면 애플리케이션 및 운영 개발자가 세분화된 수준에서 사용자 리소스 접근을 제어할 수 있습니다. APISIX의 ldap-auth 플러그인을 사용하면 Microsoft의 Active Directory 또는 Linux 플랫폼용 OpenLDAP Server와 같은 LDAP 프로토콜을 구현한 플랫폼과 쉽게 연동하여 특정 라우트에 대한 Consumer 접근을 세밀하게 제어할 수 있습니다.

OIDC

OpenID는 분산 온라인 인증 시스템입니다. OpenID를 지원하는 사이트의 경우, 사용자는 사용자 이름 및 비밀번호와 같은 전통적인 인증 토큰을 기억할 필요가 없습니다. 대신 OpenID ID 제공자(IdP) 역할을 하는 웹사이트에 미리 등록하면, 해당 제공자와 연동된 모든 애플리케이션에 이 계정으로 로그인할 수 있습니다. 예를 들어, Google 또는 Facebook 서비스의 계정을 통해 우리 시스템의 사용자를 인증할 수 있습니다.

OIDC의 경우, APISIX는 openid-connect 플러그인을 제공하며, 이는 OIDC 프로토콜을 지원하는 인증 서비스와 연동할 수 있습니다.

Forward Auth

APISIX의 표준 인증 플러그인이 현재 요구 사항을 충족하지 않거나, 시스템 내에 전용 및 비표준 프로토콜 인증 서비스가 배포된 경우, forward-auth 플러그인을 사용할 수 있습니다. 이 플러그인을 사용하면 사용자 요청을 HTTP를 통해 인증 서비스로 전달하고, 인증 서비스가 비정상 상태(20x 이외의 오류 코드)로 응답할 경우 사용자 정의 오류를 반환하거나 사용자를 인증 페이지로 리디렉션할 수 있습니다.

forward-auth 플러그인의 힘을 통해 인증 및 인가 로직을 전용 비표준 프로토콜 외부 서비스로 매우 영리하게 전환할 수 있습니다.

인증 후 다른 플러그인과의 연동

사용자 인증은 APISIX로 API를 보호하는 첫 번째 단계일 뿐입니다. 인증 기능을 다른 보안 플러그인과 결합하면 게이트웨이의 보안 기능을 더욱 강화할 수 있습니다.

ACL（consumer-restriction）

복잡한 백엔드 시스템에서는 일부 API가 다른 API보다 더 높은 보안 제한을 가질 수 있습니다. 이러한 API는 익명 사용자를 차단할 뿐만 아니라 인증된 사용자도 제한해야 합니다. 예를 들어, 사용자 관리 API에 접근할 수 있는 사용자를 화이트리스트로 제한할 수 있습니다.

white list

이 경우, APISIX에서 제공하는 consumer-restriction 플러그인을 사용하여 접근 제어 메커니즘을 구현할 수 있습니다.

$ curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: your-API-key' -X POST -i -d '
{
    "uri": "/api/v1/users/admin",
    "plugins": {
        "key-auth": {},
        "consumer-restriction": {
            "whitelist": [
                "Rose",
                "Peter
            ]
        }
    },
    "upstream": {
        ...
    },
}'

위 라우트는 /api/v1/users/admin 라우트에 대해 key-auth 및 consumer-restriction 플러그인을 통해 키 인증을 요구하며, Rose와 Peter만 접근할 수 있도록 제한합니다.

Rate Limiting （limit-count）

앞서 Consumer에 인증 플러그인을 구성하여 사용자 증명을 소비자와 연결할 수 있다고 설명했습니다. 그러나 사실 APISIX Consumer 객체는 인증 플러그인뿐만 아니라 Route 및 Service와 같은 모든 플러그인을 마운트할 수 있습니다.

예를 들어, 실제 애플리케이션에서 속도 제한 정책은 종종 정적이지 않고 개인화되어 있습니다. 서비스 수준의 호출자마다 다른 API 속도 제한 정책을 요구하는 경우가 많습니다. 그러나 이러한 요구 사항은 라우트에 속도 제한 플러그인을 마운트하여 해결할 수 없습니다. 따라서 Consumer에 속도 제한 플러그인을 마운트하고 각 소비자에 대해 타겟팅된 속도 제한 정책을 지정해야 합니다.

$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack"
        },
        "limit-count": {
            "count": 200,
            "time_window": 60,
            "rejected_code": 503,
            "key": "$consumer_name",
        }
}'
$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "rose",
    "plugins": {
        "key-auth": {
            "key": "rose"
        },
        "limit-count": {
            "count": 1000,
            "time_window": 60,
            "rejected_code": 503,
            "key": "$consumer_name",
        }
}'

위 구성으로 jack과 rose에 대해 다른 속도 제한 정책을 지정했습니다. rose는 60초 동안 1000회의 요청 할당량을 가지며, jack은 200회만 할당됩니다.

요약

API 게이트웨이의 필수 기능인 인증 및 인가는 사용자가 API 게이트웨이를 선택할 때 고려하는 중요한 요소 중 하나입니다.

이 문서에서 소개한 오픈소스 게이트웨이 Apache APISIX는 주요 인증 방법을 모두 포함하고 있으며, 기업 사용자의 인증 및 인가 요구를 충족시킬 수 있습니다. APISIX는 또한 다음과 같은 장점을 가지고 있습니다:

  • 풍부한 기본 제공 인증 플러그인
  • 내장 및 외부 인증 방법 지원, 사용자가 자유롭게 선택 가능
  • 2차 개발 지원, 사용자 정의 인증 센터와 쉽게 연동 가능

이러한 이점은 기업이 게이트웨이 수준의 인증 및 인가를 더 쉽게 구현하고 API 보안을 강화하는 데 도움이 됩니다.

Apache APISIX에 대해 더 알아보세요. 문의 사항은 https://api7.ai/contact로 연락주세요.

Tags:
Authentication & Authorization
OIDC
API Gateway Concept