Cloudentity MicroPerimeter™ Security supports the following functionality:
- Service identification
- Strong service to service authentication with X.509 certificates
- Channel and request/message level security
- API security
- Micro-segmentation between services
- Permissions/Consent at the service
- Identity claims injection to a service
- Visibility and tracing into multi-service transactions
- Tamper-Proof Audit
- Transparent dry run mode
Let’s dive into each of these topics
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. 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.
By default, the MicroPerimeter™ 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.
- When authorized, Proxy forwards the request to the target microservice.
- When unauthorized, Proxy returns
- 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.
By default, the MicroPerimeter™ Security injects a service fingerprint signed using the X.509 certificate that is assigned to the target microservice as a custom an HTTP header.
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™ Security 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™ Security 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™ Security 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™ 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 (millisecond) at the MicroPerimeter™ Security 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 MicroPerimeter™ Dashboard.
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™ Security fully supports OpenTracing standard and makes it easier for existing services to comply with the standard.