Cloudentity MicroPerimeter™ Security

Cloudentity MicroPerimeter™ Security provides a ubiquitous security layer that allows an organization to create global security and visibility rules that are enforced locally at the application/service/API perimeter regardless of where that service is hosted: serverless, containerized, online/offline, multi-cloud, legacy, smart thing, etc. This provides visibility and security enforcement rules that only allow identified and authorized services/clients/users to access the service while denying everything else in a simple and scalable manner. Cloudentity protects the service from the inside at the service itself and out to the compute edge by encapsulating all services with the Cloudentity MicroPerimeter security plane. Effectively creating the first transactional Zero Trust Ecosystem where every entity in a transaction can authenticate every other entity coupled with intelligent risk-based authorization for service specific permissions & consent.

Introduction

The Cloudentity MicroPerimeter™ Security Plane is a platform that secures legacy applications, microservices, APIs, workloads and smart devices in hybrid-cloud environments. Traditional security requires large, complex gateways or firewalls on the edge of the network; losing visibility between services (East/West traffic) and failing to provide unique identities for zero trust networks to every instance of every service. Cloudentity’s MicroPerimeter™ Security Plane provides service-to-service identity, API security and fine-grained authorization for the protected services by sitting as close to the service as possible. The MicroPerimeter™ encapsulates the protected service; securing intra-service communication and communication with legacy applications by providing an native layer of security and visibility to the applications themselves. To secure the communications it utilizes a robust tamper-proof identity for services by enforcing extensive service validation and couples that with robust authorization capabilities that include coarse grained micro-segmentation and fine-grained user permissions/consent.

The MicroPerimeter API & Microservice security platform is comprised of two components.

The Edge gateway which handles standards-based token translation plus authentication for requestor/user-to-service transactions and for workloads. It provides each microservice in a MicroPerimeter™ trust-domain with the verifiable requestor and service identity context for that transaction. This combination of user and service identity allows for comprehensive transactional security controls at the endpoint level and traceability for every step of a multi-service transaction. In addition, developers can utilize the verifiable user context within their microservices, avoiding the difficulties of implementing Oauth flows while leveraging the user identity context from any standards based Identity or authentication provider.
The MicroPerimeter Sidecar which provides a localized Policy decision and policy enforcement point for each service. The Cloudentity MicroPerimeter™ sidecar gets automatically installed alongside each microservice container or legacy application. The Sidecar makes it possible to deploy code without requiring any changes to the microservice itself and is independent of the programming language and architecture the services are implemented in.

The MicroPerimeter™ Security Sidecar:

manages signing/verification of keys,
manages policy synchronization and,
Performs authentication, authorization of all incoming requests,
Provides visibility via Tamper-Proof audit of all identity data (user, service and device) and clients in the transaction.
Generates security tokens and inspection of outgoing traffic.

Note

The token signing & verification, policy enforcement and authorization policy decisions are completely stateless and leveraged as part of the microservice. Thus, it introduces minimal latency (less than 1ms in most cases), is extremely lightweight (sub 10Mb) and extraordinarily scalable (10,000+ conn/sec/instance)

These pieces work together to create the Cloudentity security plane that can co-exist with and augment the existing microservice data and control planes. It bridges the Identity, API security and microservice security worlds. Providing the capability to leverage the cloud in anyyou’re your business sees fit and providing distributed security that can provide distributed applications with the PII visibility and security controls wherever required.

Architecture

Cloudentity MicroPerimeter™ Security Plane allows organizations to create robust, secure Zero Trust ecosystems for Users, Services and Things.

MicroPerimeter Edge - an Ingress/Egress API Gateway running on the virtual edge of the Security Perimeter.
MicroPerimeter Sidecar - local Zero Trust and Authorization Policy decision point that is collocated with the protected service or smart device.
MicroPerimeter CA - Certificate Authority that provides certificates and private keys used for service fingerprints, client/device context distribution and optional mTLS.
MicroPerimeter Configuration Management - platform specific configuration distribution and management used to deliver and manage security rules and Authorization policies
MicroPerimeter Operator - responsible for injection of the sidecars operation of the Cloudentity MicroPerimeter Security Zero Trust Ecosystem.
MicroPerimeter Security Pane - Localized Dashboard and administration tool instance for MicroPerimeter Security trust domain.

Cloudentity’s MicroPerimeter™ Security Plane is platform agnostic and portable. Allowing you to span leverage Zero Trust Networking across multiple environments, platforms and even smart things.

MicroPerimeter™ Security establishes Zero Trust Protection between all of the enabled services without modification of your code or applications.

Note	To enable full user/client and service context visibility for the EAST/WEST traffic the protected microservices are required to support OpenTracing standard or propagate header based request correlation ids.

Supported Platforms

Kubernetes

Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. Out of the box Kubernetes doesn’t provide advanced capabilities for Microservices security and authorization.

Adding MicroPerimeter Security to your Kubernetes deployments allows you to create new or join existing Zero Trust Networks with multilevel authorization based on client and identity context.

Supported versions:

Kubernetes 1.10
Kubernetes 1.11

Docker and Docker Compose

Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Docker Compose is a tool for defining and running multi-container Docker applications.

The Compose file configures your application’s services. Then, using a single command, all the services from your configuration are created and started.

Docker compose is useful in development or single node deployments of your multi container applications. Adding Cloudentity MicroPerimeter Security as part of your docker-compose enables security and authorization for your services.

Supported and certified versions:

docker-compose 1.2x
docker-compose 1.1x

Smart devices

The small memory footprint of the MicroPerimeter™ Sidecar (~10MB) allows embedding as part of smart IoT devices.

Enabling the MicroPerimeter™ Sidecar on these devices will:

provide identity to your devices based on a secure private key
make the smart device a fully qualified member of your Zero Trust Network, which will protect both ingress and egress traffic at the smart device as well as enforcing advanced authorization.

Device requirements:

ARM Linux based OS with ability to run executable processes and iptables support
ARM based CPU (tested on ARMv7 and ARMv8 CPU families)
~20MB available RAM
~40MB available HDD

Supported Protocols

HTTP

Cloudentity MicroPerimeter Security Plane provides full support for the HTTP1.0, HTTP1.1 and HTTP2.0 on all platforms. It provides visibility and protection of all HTTP based traffic including but not limited to REST based APIs.

gRPC

Partial support only on Kubernetes Platform utilizing Envoy as MicroProxy.

Support for other platforms coming soon…

How does it work?

The Cloudentity MicroPerimeter™ Security Plane was created to offload complex API security, logging and identity related tasks from the development teams of cloud-native and legacy applications. This relieves the software team from the burden of securing software as it talks to other software regardless of service or deployment type.

Overview

Cloudentity MicroPerimeter™ Security:

allows developers to focus on the creation of business features
gives SecDevOps engineers ability to make security part of the CD pipeline
Provides security practitioners measures to control access to services and governance for PII data
Provides CISO’s immutable policies that protect applications from threats while providing adherence to PII based regulations.

This performs as transparently as possible and doesn’t require developers, SecDevOps, or security practitioners to have deep knowledge about the internals of MicroPerimeter™ Security plane technology.

Cloudentity MicroPerimeter™ Security supports the following functionality:

Service Identification
PKI based service to service authentication with X.509 certificates
Service to service communication
Channel security
API security
Micro-segmentation between services
Permissions/Consent at the service
Identity claims injection
Visibility and tracing into multi-service transactions
Tamper-Proof Audit
Dry run mode

Let’s dive into each of these topics

Service Identification

It all starts with identity

This section describes how each service is assigned a unique identity with the Microperimeter and how identifiers are used within the Microperimeter to provide unparalleled security and visibility for clients that are accessing protected APIs and services.

The Cloudentity Microperimeter is the technology allowing each microservice to obtain its own verifiable identity.
Identity is essential for building Zero-trust networks as it allows every entity in the transaction to authenticate and remove any possibility of anonymity.
Identity is a pre-requisite for authentication, authorization, secure audit, traceability.

What identifiers do services use?

The MicroPerimeter™ leverages SPIFFE ID compliant identifiers as part of the broader SPIFFE standard. The SPIFEE standard aims to be a common standard for service identification. It recognizes services as a separate entity type in the Internet and allows each of them to be identified uniquely.

The Microperimeter allows software talk to other software securely. The service identities are essential for providing secure borderless communication between software running on heterogenous environments that may not be sharing the same locale or operation teams.

The Microperimeter service identifier follows the SPIFEE scheme that mirrors the dns hostname scheme. It is composed of trust domains and the hierarchical path uniquely identifying each service and service instance within that domain.

spiffe://trust domain/path

Each trust domain has a signing authority associated with it. Whenever the service identifier is issued it is signed by the corresponding signing authority. Each identity can be subsequently validated within the trust domain.

For example, the trust domain may be a kubernetes cluster instance owned by an individual organizational branch or it can encompass the entire business. When the Microperimeter Security Plane is running on a protected cluster it delivers all of the necessary components to automate issuing, validating and assigning identifiers transparently for any service running within that domain.

Here’s a sample identifier:

Cloudentity Mircroperimeter Sample SpiffeID on Kubernetes Cluster

The example identifier above is an identifier issued for a service running on a kubernetes cluster with the Microperimeter™ installed, thus the path is kubernetes specific, although the usage scenarios are not Kuberenetes specific. Kubernetes defines the namespace in which the service is deployed and the service account with the context of the running service and how it corresponds to the service name.

Kubernetes is an advanced container orchestration platform that has a concept of namespaces and requires services to be run by service accounts recognized across the cluster. It doesn’t typically apply to traditional standalone services running on servers or IoT devices. The Microperimeter is not constrained only to kubernetes hence it supports identifiers specific to other software architectures within federated trust domains.

The MicroPerimeter™ is not constrained only to kubernetes — it supports other identifiers specific to other platforms which also act as trust domains. For example, a non-containerized service protected by the Microperimeter running by a customer specific orchestrator (e.g. scripts) may look like this:

spiffe://us-west.legacy-services.cloudentity.com/service-type/transfers-service/ver/3.0.1/ins/23d3

The above identifier contains only available information for this environment that is required to uniquely identify a service within that environment (trust domain).

In the case of IoT devices, the identifier can contain UUIDs and specifics about the device to provide a complete identity of the device. These devices/things can also join zero trust networks through the utilization of the Microperimeter and participate in the commensurate authentication and authorization of other entities in that Zero Trust Network based on its assigned identity. :

spiffe://lighting.iot.cloudentity.com/device-type/light-controller/ver/1.3.423/ins/c4fa9fc4-9660-4cd1-b5d6-007d28a12591

How are services assigned their identity ?

A service itself is not involved in the process of obtaining identity and isn’t required to be aware of its identity during its instantiation. The Microperimeter components themselves assign the identity to a protected service and manages its certificate request and storage.

The identity assignment process differs depending on the target platforms, however the high-level flow is virtually the same. The diagram below illustrates that process.

microperimeter identity assignment process

The process requires the introduction of a few key Microperimeter concepts that secure the transaction through identity, authentication and authorization i.e.:

1. The Security Sidecar is a Microperimeter component that creates a separate process that runs in parallel to the protected service (in the same pod or on the same server). A simple way of thinking about it is a butler who answers the door to your service. In this step it offloads the service from having to manage TLS, mTLS, certificate renewal and assigning an identity to the service.
2. A Microperimeter Orchestrator Extension integrates the Microperimeter with an orchestrator (e.g. k8s, terraform scripts, etc.). It is responsible for triggering the process of setting up the microservice identity.
Vault is an auxiliary MicroPerimeter component. It acts as a signing authority for the trust domain. It is used to generate the individual X.509 certificate-private key pairs for service identities.

The process on the diagram above is initiated with the external call initiating the microservice deployment (step 1). This call can be triggered by a CD pipeline, API or directly on the command line (calling e.g. kubectl apply on k8s). Before the actual microservice deployment begins the orchestrator extension is triggered. Its objective is to inject and run the Security Sidecar that will be entitled to register this microservice’s identity with the CA (steps 2-7). The Security Sidecar when run, immediately registers the microservice’s unique identifier using credentials passed in its configuration (steps 8-10). The Security Sidecar stores the identifier and the private key in memory. The one-time credentials passed to the Security Sidecar can’t be used to register any other instances of the same or other services.

The MicroPerimeter™ Orchestrator Extension implementation strategy differs depending on the platform.

For Kubernetes it is the MutatingAdmissionWebhook that injects the Security Sidecar into the microservice pod.
For the non-containerized applications it is simply a script that remotely invokes the pre-generated script on the server where microservice is installed. The local script optionally installs the sidecar on the server using deb/rpm package and passes it the appropriate parameters.
For IoT devices either the above non-containerized strategy can be used, or the device management platform can configure the microperimeter directly.

Strong service to service authentication

Each service or workload is secured by the Cloudentity MicroPerimeter™ Sidecar. Each ingress and egress request goes through the secure proxy before it reaches its target or leaves the processing domain of the service. NOTE: Cloudentity MicroPerimeter™ Sidecar can act as a lightweight http proxy and it can integrate with existing service mesh proxies like envoy to function as a service mesh specific security and authorization provider.

Each incoming request is validated and each outgoing request is transformed to inject the cryptographically secured service fingerprint.

Note	The service fingerprint is calculated and injected on a per request basis. Each fingerprint has a configurable TTL and it is bound to the request through a secure mTLS based communication channel. This approach was designed to mitigate man-in-the-middle and replay attacks.

Incoming request flow

Incoming request hits a Sidecar.
Security Sidecar validates a request.
Security Sidecar looks for a policy rule that matches given request.
Security Sidecar validates policies for given request.

Note

By default, the Sidecar checks if incoming service fingerprint and identity context are valid and signed using the key that was issued by the Certificate Authority.
Proxy evaluates validation result.
1. When authorized, Proxy forwards the request to the target microservice.
2. When unauthorized, Proxy returns 401 HTTP status.

Outgoing request

Outgoing request is also evaluated by the MicroPerimeter.
Microperimeter transforms the request to inject the security context and fingerprints.
Microperimeter executes a chain of Http Request Transformers.

Note

By default, the Microperimeter injects a service fingerprint signed using the X.509 certificate that is assigned to the target microservice as a custom an HTTP header.

Channel security

Security of the communication channel between the services is achieved via 2 way TLS (mTLS) between services participating in the communication.

Note

In two-way TLS authentication, client and server-side certificates are involved to harden the authentication process. Just like a server certificate, a client certificate contains basic information about the client’s identity(SPIFFE ID), its public key and the digital signature of a CA on this certificate verifies that this information is authentic. The client certificate is signed by the central CA that secures the Trust Domain for the Cloudentity MicroPerimeter deployment.

The MicroPerimeter Sidecars securely distribute and bootstrap X.509 certificates. Thus, enabling the mutual TLS is a seamless process that doesn’t require the traditional overhead of service specific key management. The key bootstrapping, distribution of private keys and epheremal key rotation occurs behind the scenes and doesn’t require any administrative or developer oversight. In addition, the keys are frequently rotated and generated on a per instance basis with a direct binding to that instance, protecting against MiM and impersonation attacks.

API security and Authorization

Cloudentity MicroPerimeter™ Sidecar can act both as a local policy enforcement point (PEP) as well as the localized policy decision point(PDP) coupled with centralized Policy Management. As such the MicroPerimeter™ acts as an extension of the Cloudentity TrUST and Authorization engine which provides comprehensive policy management ranging from coarse-grained micro-segmentation to mid-grained RBAC/ABAC/PBAC to fine-grained permissions/consent policy administration. When the TrUST engine is coupled with the MicroPerimeter™ it provides distributed authorization policy decisions and enforcement with centralized policy management.

Cloudentity provides comprehensive authorization for Users, Services and Things using a combination of controls including

Attribute Based Access Controls (ABAC)
Role-Based Access Control (RBAC)
Advanced Risk Based Authorization Capabilities (RADAC)

Cloudentity access policies allow for the modeling of complex decision trees and provide flexible and adaptive authentication and authorization flows and the ability to mitigate risk transactions in real time. Policy is applied at the Service/API endpoint level: as close to the protected workload/service as possible. This allows for very granular intelligent risk-based access policies to be applied to protected resources regardless of where they exist, meaning high-value resources (e.g. a financial microservice) in a VPC may require lower transactional trust levels than a low value transaction (e.g. accessing public wiki) on a publicly available website.

By utilizing the built-in MicroPerimeter™ Security Dashboard or integrating directly with the Cloudentity APIs, it is painless to integrate the DevOps pipeline or to manually update and configure security policies at an API level for any protected service.

The policy definition is expressed as a JSON file and can be managed via APIs. This allows any policy to be used in the exact same manner regardless of whether the developer is building the app on localhost or its instantiation in production. Security policies are code and enforceable regardless of where the application is hosted. DevOps integration as well as the easy to use drag and drop admin UI ensures policy changes can be instituted quickly and effectively through the centralized management interface and propagated out to the distributed application.

This example verifies whether the request is coming from the financial service and whether the application that made the call to the API gateway on user’s behalf has been given consent by this user to access PII resources. That is, a certain scope and by that whether a user has assigned the permission and granted it to the application. In addition, there is a verification and mitigation of any potential threats within the inspected transaction. The client, device and/or service risk are available for evaluation and mitigation with in the transaction. The policies are designed to perform the entire policy validation with limited processing time (sub millisecond) at the microperimeter policy decision and enforcement point.

When creating policies administrators can chose from a rich set of validation options and logical operators to craft policies at the root, business unit, or application level.

The policy decisions and current status of services protection is immediately visible on the analytics Dashboard.

Tracing

Microservices and Service Meshes provide a powerful architecture, but not without its own challenges, especially with regards to debugging and observing distributed transactions across complex networks — simply because there are no in-memory calls or stack traces to facilitate this capability.

This is where OpenTracing comes into picture. Via distributed tracing it provides a solution for describing and tracking cross-process and cross-service transactions.

Cloudentity MicroPerimeter fully supports OpenTracing standard and makes it easier for existing services to comply with the standard.

Note	In the example above the request was rejected on card-service because the user does not have list_cards scope.