Decouple PDP and PEP to Support Zero-trust Architecture on Oracle Cloud

To help reduce risk from constant threats, a zero-trust architecture should use a separate control plane for Policy Decision Point (PDP) and implement the Policy Enforcement Point (PEP) on a data plane. You can use Oracle Cloud services to support your zero-trust architecture and enhance access control on Oracle Cloud for your PDP and PEP implementation.

Oracle Cloud Infrastructure (OCI) provides a compelling set of security capabilities to protect mission-critical workloads and sensitive data. Oracle Cloud implements a zero-trust security model that is informed by the zero-trust architecture established by the National Institute of Standards and Technology (NIST). This model enables you to enforce a stringent security posture that requires verification from every user trying to gain access to systems, networks, and data.

You can integrate OCI Identity and Access Management and OCI API Gateway to achieve separation between the PDP and PEP.

Identity and Access Management (IAM)

Oracle Cloud provides an enterprise-class Identity-as-a-Service (IDaaS) platform called OCI Identity and Access Management. OCI Identity and Access Management uses identity domains to provision cloud identities, users, and secure applications. You can use OCI Identity and Access Management with Identity Domains as the PDP to allow or deny the access to various cloud resources or services by defining granular policies.

The identity platform serves as both the front door into cloud services, as well as a standalone identity-as-a-service (IDaaS) platform for both enterprise users and consumers. This platform provides key identity management capabilities for applications and services running in Oracle Cloud, third-party clouds, and your on-premises data centers. OCI Identity and Access Management offers authentication, single sign-on (SSO), and identity lifecycle management for Oracle Cloud and for Oracle and non-Oracle applications, whether they are SaaS, cloud-hosted, or on-premises. IAM also allows you to control what type of access a group of users have and to which specific cloud resources.

API Gateway

Oracle Cloud builds services with a security-first design approach. With this approach, services like the OCI API Gateway enable you to create data access policies that allow only authorized users or applications to access the data across the enterprise.

The OCI API Gateway service allows you to create governed HTTP/S interfaces (APIs) for multiple back ends including Oracle Cloud services such as OCI Load Balancing, OCI Functions, OCI Compute instances, and on-premises applications connected to the Oracle Cloud through a VPN or OCI FastConnect. OCI API Gateway provides policy enforcement features such as rate-limiting to HTTP/S endpoints, authentication with identity providers, and access to multiple RESTful services both in the cloud and on-premises.

OCI API Gateway ensures that the caller is authenticated so that the back ends connected to the gateway cannot be called anonymously. OCI API Gateway can also check the authorization and it allows you to add HTTP and HTTP/S URLs to a back-end service to grant those services front-end access with policy enforcement. The HTTP/S URLs you specify for the back-end service can be one of the following:

  • The URL of an Oracle Cloud service (for example, OCI Functions or OCI Object Storage)
  • The URL of a service in your own private or internal network that is connected to OCI through VPN or OCI FastConnect

Architecture

This architecture design describes the integration between OCI Identity and Access Management and OCI API Gateway. In this architecture, OCI API Gateway acts as PEP by enforcing the policies, and OCI Identity and Access Management acts as PDP by authorizing the token and granting access for authorized users. This integration leverages JWT or JSON Web token, also commonly referred to as Access Token. JWT is an open industry standard that allows you to integrate with other IAM systems.

The following diagram illustrates this reference architecture.

Description of zero-trust-pdp-pep-oci.png follows
Description of the illustration zero-trust-pdp-pep-oci.png

zero-trust-pdp-pep-oci-oracle.zip

The following steps explain the architecture authorization flow with OCI API Gateway and OCI Identity and Access Management:
  1. Generate Access Token

    The end user's client application uses the IAM API to generate a JWT access token from OCI Identity and Access Management (PDP).

  2. Call with Access Token (JWT)

    The JWT Access Token is sent to OCI API Gateway as part of the HTTP request header of every API call. Optionally, the token can contain scopes that are specifically defined for the resources.

  3. Policy Verification and JWT Validation with IAM

    The OCI API Gateway (PEP) calls the IAM Authorization API and passes the access token received from the client.

  4. Policy Decision

    The OCI Identity and Access Management service (PDP) evaluates the token and returns a decision to allow or deny.

  5. Grant Access to Backends

    The OCI API Gateway (PEP) grants or denies access to back-end services (such as Microservices running in Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE), OCI Functions, OCI Object Storage, or to a service endpoint exposed by an application running in VM) based on the outcome of the IAM policy decision.

  6. Response (200 OK / 403 Forbidden)

    The OCI API Gateway (PEP) returns the status 200 OK (allow) or 403 Forbidden (deny) back to the caller.

You can use the OCI Console or GUI and REST calls to configure the implementation of this integration.

The architecture has the following components:

  • API gateway

    OCI API Gateway service enables you to publish APIs with private endpoints that are accessible from within your network, and which you can expose to the public internet if required. The endpoints support API validation, request and response transformation, CORS, authentication and authorization, and request limiting.

  • Identity and Access Management (IAM)

    Oracle Cloud Infrastructure Identity and Access Management (IAM) is the access control plane for Oracle Cloud Infrastructure (OCI) and Oracle Cloud Applications. The IAM API and the user interface enable you to manage identity domains and the resources within the identity domain. Each OCI IAM identity domain represents a standalone identity and access management solution or a different user population.

    IAM enables you to control who can access your resources in OCI and the operations that they can perform on those resources.

  • Policy

    An Oracle Cloud Infrastructure Identity and Access Management policy specifies who can access which resources, and how. Access is granted at the group and compartment level, which means you can write a policy that gives a group a specific type of access within a specific compartment, or to the tenancy.

  • Container Engine for Kubernetes

    Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) is a fully managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. You specify the compute resources that your applications require, and Container Engine for Kubernetes provisions them on Oracle Cloud Infrastructure in an existing tenancy. Container Engine for Kubernetes uses Kubernetes to automate the deployment, scaling, and management of containerized applications across clusters of hosts.

  • Functions

    Oracle Cloud Infrastructure Functions is a fully managed, multitenant, highly scalable, on-demand, Functions-as-a-Service (FaaS) platform. It is powered by the Fn Project open source engine. Functions enable you to deploy your code, and either call it directly or trigger it in response to events. Oracle Functions uses Docker containers hosted in Oracle Cloud Infrastructure Registry.

  • Object storage

    Object storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store and then retrieve data directly from the internet or from within the cloud platform. You can seamlessly scale storage without experiencing any degradation in performance or service reliability. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.
  • Security

    Use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure (OCI) proactively. Oracle Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When misconfiguration or insecure activity is detected, Oracle Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.

    For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, OCI validates the operations against the policies in the security-zone recipe and denies operations that violate any of the policies.

  • Cloud Guard

    Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect OCI Object Storage buckets that have visibility set to public.

    Apply Oracle Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.

    You can also use the Managed List feature to apply certain configurations to detectors.

Considerations

Consider the following when implementing this reference architecture:

  • User Provisioning and Access Control

    When customers are granted access to data and backend services, how are they provisioned into Oracle Cloud Infrastructure Identity and Access Management (which authenticates them)? How are they de-provisioned when their access rights are to be revoked? These considerations arise as part of the wider discussion around how and to whom monetized data products are made available.

  • Performance

    Oracle Cloud Infrastructure API Gateway supports response caching by integrating with an external cache server (such as a Redis or KeyDB server), which helps avoid unnecessary load on back-end services. With cached responses, similar requests are completed by retrieving data from a response cache rather than sending the request to the backend service. This reduces the load on backend services, which helps improve performance and reduce costs.

    OCI API Gateway also caches Auth Tokens based on their time-to-live (TTL), reducing the load on the Identity Provider and improving performance.

  • Security

    Oracle Cloud Infrastructure (OCI) services use OCI Identity and Access Management policies such as allowing OCI API Gateway to invoke functions. OCI API Gateway can also control access using OAuth authentication and authorization. Authentication and authorization can be federated through OCI Identity and Access Management, which gives the OCI API Gateway the power to authenticate against a wide array of services and authentication setups.

  • High Availability

    Consider using a high availability option based on your deployment requirements and region. The options include distributing resources across multiple availability domains in a region and distributing resources across the fault domains within an availability domain. Fault domains provide the best resilience for workloads deployed within a single availability domain. For high availability in the application tier, deploy the application servers in different fault domains and use a load balancer to distribute client traffic across the application servers.

Acknowledgments

Author:

  • Subba Bhamidipati