How are services assigned their identity?
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™ Security 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 the process.
The process requires the introduction of a few key MicroPerimeter™ Security concepts that secure the transaction through identity, authentication, and authorization i.e.:
- The Security Sidecar is a MicroPerimeter™ Security 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.
- A MicroPerimeter™ Orchestrator Extension integrates the MicroPerimeter™ Security with an orchestrator (e.g. kubernetes, terraform scripts, etc.). It is responsible for triggering the process of setting up the microservice identity.
- Vault is an auxiliary MicroPerimeter™ Security 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. Thanks to the configuration of a vault with the intermediate/root CA, all certificates issued by it are part of the chain of trust.
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 kubernetes). Before the actual microservice deployment begins the orchestrator extension is triggered. Its objective is to inject and run the MicroPerimeter™ Security Sidecar that will be entitled to register this microservice’s identity with the CA (steps 2-7). The MicroPerimeter™ Security Sidecar when run, immediately registers the microservice’s unique identifier using credentials passed in its configuration (steps 8-10).
The MicroPerimeter™ Security Sidecar stores the identifier and the private key in memory. The one-time credentials passed to the MicroPerimeter™ 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
MutatingAdmissionWebhookthat 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
rpmpackage 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™ Security directly.