Organizations are developing and deploying distributed services across the hybrid cloud and are facing four major issues which we will be addressing in this two-part series.
- Bridging traditional and cloud-native API services with an identity-centric security and request routing
- Standardized approach for authorization and sensitive privacy data security in cloud-first organizations
- Meeting compliance standards for authorization and privacy during the transition to cloud-first services
- Declarative API access control, DevSecOps model for simplifying the developer usage of identity, authorization and delivery
Identity-centric security and request routing for hybrid cloud servicesThe first step for addressing security, authorization and privacy in hybrid cloud infrastructures is updating the notion of identity. Forward-looking organizations are moving past the “futureproof & modernization” marketing strategies of legacy identity providers and realizing the underlying data model of user-centric identity platforms wasn’t designed for the cloud-native world. Thus, step one is to envelop the traditional user-centric IAM products into a model that creates identities for every entity: user, service, device & data.
The new baseline provides the ability for every service, user, persona and device to assume its own unique identity and manage access for those identities in a singular Identity & Authorization Control Plane. Accomplishing this drastically simplifies and standardizes other infrastructure issues like service discovery, service registry and secret storage for organizations leveraging platform agnostic multi-cloud architecture.
Most companies approach the process of modernizing legacy application and Identity platforms with cloud-native microservices in a gradual lift and shift process
The following diagram details how the Authorization Control Plane applies consistent identity, authorization and audit across traditional and microservice based services; immutably maintaining API security, data level permissions/consent and GDPR/CCPA/NYDFS compliance on any workload during the application decomposition and microservice adoption process.
Authorization Control Plane and HashiCorp Consul The journey starts by creating service identities for microservices and legacy-apps using Consul and Cloudentity's Authorization Control Plane (ACP). This prepares apps by adding service identity, instrumentation, inspection and declarative authorization to the workload.
Creating a declarative security layer that provides granular endpoint level access control by externalizing authorization for networking, securing communication channel via TLS, delivering standards based (FIDO/OAuth/OIDC) Authentication and privacy based data attribute authorization in a very lightweight package (<10Mb) with sub millisecond latency.
Step One Vault & MicroPerimeter™ -- Bootstrap the service identityIn order to properly apply identity and microservice specific authorization/audit policies the MicroPerimeter™ generates a secure identity through Vault for the application. To avoid code changes, the service itself is not involved in the process of obtaining identity nor is it required to be aware of its identity. The MicroPerimeter™/Vault work together to assign the SPIFFE compliant identity to a protected service and manages its certificate request and storage.
The identity assignment process differs slightly depending on the service architecture, although the high-level flow is virtually the same. The diagram below illustrates the process.
More details on the Vault & Cloudentity integration can be found here: https://docs.microperimeter.cloudentity.com/concepts/microperimeter_security/functionality/identity_bootstrapping/
The key generated per application instance provided by Vault is used for several aspects of MicroPerimeter™ functionality including:
- Cryptographically enforce identity of the service based on SPIFFE ID
- Secure mTLS communication utilizing TLS v1.3
- Digital Signature of the audit/access logs
- Signing of the service and identity context fingerprints used for declarative authorization and PII permissions/consent evaluation
Step Two: Consul and Declarative Authorization provide the interconnect
Once a service (micro or traditional) has a Vault assigned SPIFFE identity, its far easier to properly configure that service with the relevant networking, authorization, authentication and audit policies from Consul. This is a fundamental reconsideration of how to address coarse and fine grained authorization with a design that allows for both policies and policy decision points to be distributed to the edge of the service enhancing performance, security and latency.
Authorization policies are crafted in a centralized policy administration point with delegated administration to provide inheritable drag-and-drop Policy creation. The User Interface allows linking of different policy types together while creating authorization as code. Consul acts as the storage and distribution mechanism for these policies ensuring they are multi-cloud available. This promotes the move from the static approve/deny authorization paradigm of the last few decades and into a very dynamic and fluid authorization flows utilizing run-time attributes and temporal relationships for authorization decisions externalized from the service.
Declarative Authorization: Immutable Policies as CodeThe key to authorization in a multi-cloud world, comes directly out of the immutable services playbook. Authorization in a microservices world could no longer be modeled after the traditional monolithic Web access management (WAM) or API Gateway approach of applying authorization at defined ingress points. Authorization has been forced to mature in two major ways. First, authorization must be performed at both the ingress AND egress of the service itself. Secondly, authorization must be provided as Immutable code in the same way Infrastructure is in a cloud-native world.
The example below is a real-world example of the Consul distributed polices for the distributed policy decision points. The example shows how Networking, Oauth and Identity, fine grained attribute based and consent evaluation, for PII data access policies provide the security nexus; allowing transactions to be evaluated at the distributed edge of the service instead of in a centralized gateway.
Consul stores all of these authorization policy types as code, allowing developers to utilize the same security policies during development, sample the app using canary routing and then deploy into production - all distributed via the Consul control plane to the workload. Immutable distributed security attached to the distributed API endpoint.
Policies Attached to the service’s API endpoint
Policies Defined in Consul
When authorization policies are tied to workloads and endpoints, Identity and API access control remains consistent from development to the final push into production. The security teams are able to define and create policies centrally through the UI and then development teams inherit those policies during the DevOps process. In doing so, security teams gain visibility and centralized management and Developers automatically adhere to corporate policies for PII privacy data management, Authentication, Authorization and Audit.
With Distributed enforcement, API endpoints are protected by the policies regardless of the application type (legacy vs microservices), hosting location (public cloud, private cloud, datacenter) or where they are instantiated.
Figure 1: Visual design.
Figure 2: JSON representation
Combining the service identity with consul based declarative configuration for authorization and access policies enables the creation of the next generation of DevSecOps pipeline. That can be utilized to fully automate authentication, authorization, access control, as well as API publishing rules in your IT infrastructure.
Join us next week for the second part in this blog series. Using Vault and ACP to analyze Privacy Data, Secret management and API governance into the Hybrid-cloud ecosystem.