예제 2: OPA 및 Rego를 사용한 다중 테넌트 액세스 제어 및 사용자 정의 RBAC

이 예제에서는 OPA 및 Rego를 사용하여 테넌트 사용자가 정의한 사용자 지정 역할이 있는 다중 테넌트 애플리케이션의 API에서 액세스 제어를 구현하는 방법을 보여줍니다. 또한 테넌트를 기반으로 액세스를 제한하는 방법을 보여줍니다. 이 모델은 OPA가 상위 수준 역할에서 제공되는 정보를 기반으로 세분화된 권한 결정을 내리는 방법을 보여줍니다.

테넌트의 역할은 OPA에 대한 액세스 결정을 내리는 데 사용되는 외부 데이터(RBAC 데이터)에 저장됩니다.

{
    "roles": {
        "tenant_a": {
            "all_access_role": ["viewData", "updateData"]
        },
        "tenant_b": {
            "update_data_role": ["updateData"],
            "view_data_role": ["viewData"]
        }
    }
}

테넌트 사용자가 정의한 이러한 역할은 테넌트 정의 역할을 권한 및 테넌트 자체에 매핑할 때 신뢰할 수 있는 소스 역할을 할 수 있는 외부 데이터 소스 또는 ID 제공업체(IdP)에 저장해야 합니다. 

이 예제에서는 OPA의 두 정책을 사용하여 권한 부여 결정을 내리고 이러한 정책이 테넌트 격리를 적용하는 방법을 살펴봅니다. 이러한 정책은 이전에 정의된 RBAC 데이터를 사용합니다.

default allowViewData = false
allowViewData = true {
    input.method == "GET"
    input.path = ["viewData", tenant_id]
    input.tenant_id == tenant_id
    role_permissions := data.roles[input.tenant_id][input.role][_]
    contains(role_permissions, "viewData")
}

이 규칙의 작동 방식을 표시하려면 다음 입력이 있는 OPA 쿼리를 고려하세요.

{
    "tenant_id": "tenant_a",
    "role": "all_access_role",
    "path": ["viewData", "tenant_a"],
    "method": "GET"
}

이 API 호출에 대한 권한 부여 결정은 RBAC 데이터, OPA 정책 및 OPA 쿼리 입력을 결합하여 다음과 같이 이루어집니다.

1. 의 사용자가에 대한 API 호출을 Tenant A 수행합니다/viewData/tenant_a.

2. 데이터 마이크로서비스는 호출을 수신하고 allowViewData 규칙을 쿼리하여 OPA 쿼리 입력 예제에 표시된 입력을 전달합니다.

3. OPA는 OPA 정책에서 쿼리된 규칙을 사용하여 제공된 입력을 평가합니다. 또한 OPA는 RBAC 데이터의 데이터를 사용하여 입력을 평가합니다. OPA는 다음을 수행합니다.

   1. API 호출에 사용되는 메서드가 인지 확인합니다GET.

   2. 요청된 경로가 인지 확인합니다viewData.

   3. 경로tenant_id의이 사용자와 input.tenant_id 연결된와 동일한지 확인합니다. 이렇게 하면 테넌트 격리가 유지됩니다. 역할이 같더라도 다른 테넌트는이 API 호출을 수행할 수 있는 권한을 부여받을 수 없습니다.

   4. 역할의 외부 데이터에서 역할 권한 목록을 가져와 변수에 할당합니다role_permissions. 이 목록은의 사용자와 연결된 테넌트 정의 역할을 사용하여 검색됩니다. input.role.

   5. 권한이 포함되어 role_permissions 있는지 확인합니다. viewData.

4. OPA는 데이터 마이크로서비스에 다음 결정을 반환합니다.

{
    "allowViewData": true
}

이 프로세스는 RBAC 및 테넌트 인식이 OPA로 권한 부여 결정을 내리는 데 어떻게 기여할 수 있는지 보여줍니다. 이 점을 추가로 설명하려면 다음 쿼리 입력을 /viewData/tenant_b 사용하여에 대한 API 호출을 고려하세요.

{
    "tenant_id": "tenant_b",
    "role": "view_data_role",
    "path": ["viewData", "tenant_b"],
    "method": "GET"
}

이 규칙은 역할이 다른 다른 테넌트에 대한 것이지만 OPA 쿼리 입력과 동일한 출력을 반환합니다. 이는이 호출이에 대한 /tenant_b 것이고 RBAC 데이터의 view_data_role에 여전히 연결된 viewData 권한이 있기 때문입니다. 에 대해 동일한 유형의 액세스 제어를 적용하려면 유사한 OPA 규칙을 사용할 /updateData수 있습니다.

default allowUpdateData = false
allowUpdateData = true {
    input.method == "POST"
    input.path = ["updateData", tenant_id]
    input.tenant_id == tenant_id
    role_permissions := data.roles[input.tenant_id][input.role][_]
    contains(role_permissions, "updateData")
}

이 규칙은 규칙과 기능적으로 동일allowViewData하지만 다른 경로 및 입력 방법을 확인합니다. 규칙은 여전히 테넌트 격리를 보장하고 테넌트 정의 역할이 API 호출자 권한을 부여하는지 확인합니다. 이를 적용하는 방법을 확인하려면에 대한 API 호출에 대해 다음 쿼리 입력을 검사합니다. /updateData/tenant_b

{
    "tenant_id": "tenant_b",
    "role": "view_data_role",
    "path": ["updateData", "tenant_b"],
    "method": "POST"
}

이 쿼리 입력은 allowUpdateData 규칙으로 평가될 때 다음 권한 부여 결정을 반환합니다.

{
    "allowUpdateData": false
}

이 호출은 승인되지 않습니다. API 호출자가 올바른와 연결되어 tenant_id 있고 승인된 방법을 사용하여 API를 호출하고 있지만는 테넌트 정의 input.role입니다view_data_role. view_data_role 에는 updateData 권한이 없으므로에 대한 호출/updateData은 승인되지 않습니다. 이 호출은이 있는 tenant_b 사용자에 대해 성공했을 것입니다update_data_role.