Microservices Security landscape

Editor's Notes

1. References : https://www.pingidentity.com/en/company/blog/posts/2019/jwt-security-nobody-talks-about.html https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3 https://medium.com/@darutk/understanding-id-token-5f83f50fa02e Tools : https://jwt.io/
2. JWT Header : The gateway can sign the JWT so that receivers can validate the signature for identity verification How to pass valid JWT to the backend ? 1. The gateway can have number of identity values in the ‘aud’ claim, these identity values are pre-agreed identifies of services that intended to use the JWT token. 2. The above approach assumed that G/W pre-assumed all the down-stream microservices in the particular flow, instead of this it’s possible to use Token Exchange with a STS to get a new token for target service. When passing a JWT token generated by the G/W from one service to another ( not the G/W to a service, G/W -> Service A -> Service B) , the sending service can sign the JWT; if signed receiving service can verify the identity of sending service otherwise receiving service can’t verify the identify of sending service, it only can verify end-user context based on G/W signature verification. ( in this case it use nested JWT) How this works when these two services from 2 trust domains 1. Service-A present it’s current token received from GW to STS of A-domain and request a token which audience set to STS of B-Domain, then contact STS or domain-B with this new token and request another token to access service-B 2. Service-A present it’s current token received from GW to STS of A-domain and request a token which audience set to G/W of B-Domain, then call the service-B via G/W of domain-B with this token
3. In practice, most of the cases self-issues JWT is used over TLS where JWT provides authentication while TLS provides confidentiality and integrity.
4. In practice, most of the cases self-issues JWT is used over TLS where JWT provides authentication while TLS provides confidentiality and integrity.
5. In practice, most of the cases self-issues JWT is used over TLS where JWT provides authentication while TLS provides confidentiality and integrity.
6. This JWT use case is known as self-issued JWT, note that this can be only used to authenticate identity of the sending service, this can bot be the best method to pass end-user context to another service unless there is great level of trust (usually within same trust domain ) among services. One of the following approaches best suite for these use cases… 1. The better approach is use the singed JWT token received from the G/W as the source and create a nested JWT by signing with calling services private key so that receiving service can verify both the end-user identity and sending service’s identity, in case there is no token from G/W sending service can get a token from a STS for signing. 2. Use mTLS for service authentication and use pass JWT from G/W for end-user identity 3. Use mTLS for service authentication and get a token from a STS to pass in the other service.
7. https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#2-spiffe-identity
8. -The SPIFFE ID of the signing authority SHOULD reside in the trust domain in which it is authoritative, and SHOULD NOT have a path component. The SVID of the signing authority then forms the basis of trust for a given trust domain. Chaining of trust, if desired, can be achieved by signing the authority’s SVID with the private key of a foreign trust domain’s authority. In the event that trust is not being chained, then the authority’s SVID is self-signed. REF : https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#3-spiffe-verifiable-identity-document https://github.com/spiffe/spiffe/tree/master/standards https://gist.github.com/Pushpalanka/b70d5057154eb3c34d651e6a4d8f46ee
9. https://spiffe.io/spire/overview/#all-about-the-server an AWS Instance Identity Document to the server.
10. https://spiffe.io/spire/overview/#all-about-the-server https://www.youtube.com/watch?v=ikmxZdZRTio&t=426s
11. https://spiffe.io/spire/overview/#all-about-the-server https://www.slideshare.net/QAware/building-trust-between-modern-distributed-systems-with-spiffe-88969318
12. Istio tunnels service-to-service communication through the client side and server side Envoy proxies. For a client to call a server with mutual TLS authentication Istio re-routes the outbound traffic from a client to the client’s local sidecar Envoy. The client side Envoy starts a mutual TLS handshake with the server side Envoy. During the handshake, the client side Envoy also does a secure naming check to verify that the service account presented in the server certificate is authorized to run the target service. The client side Envoy and the server side Envoy establish a mutual TLS connection, and Istio forwards the traffic from the client side Envoy to the server side Envoy. After authorization, the server side Envoy forwards the traffic to the server service through local TCP connections.
13. By default, Citadel generates self-signed root certificate and key, and uses them to sign the workload certificates. Citadel can also use the operator-specified certificate and key to sign workload certificates. Citadel watches the Kubernetes API server, creates a SPIFFE certificate and key pair for each of the existing and new service accounts then Citadel stores the certificate and key pairs as Kubernetes secrets. When you create a pod, Kubernetes mounts the certificate and key pair to the pod according to its service account via Kubernetes secret volume. Citadel watches the lifetime of each certificate, and automatically rotates the certificates by rewriting the Kubernetes secrets. Pilot generates the secure naming information, which defines what service account or accounts can run a certain service. Pilot then passes the secure naming information to the sidecar Envoy. Problems: Private key is generated by Citadel not that secure Key provisioning can happen over a network Keys are stored in Pod file system so process can see Certificates/Keys are loaded from file system to memory so each key rotation result into reload at Envoy proxy
14. 1. Citadel creates a gRPC service to take CSR requests. 2. Envoy sends a certificate and key request via Envoy secret discovery service (SDS) API. 3. Upon receiving the SDS request, the node agent creates the private key and CSR before sending the CSR with its credentials to Citadel for signing. 4. Citadel validates the credentials carried in the CSR and signs the CSR to generate the certificate. 5. The node agent sends the certificate received from Citadel and the private key to Envoy via the Envoy SDS API. 6. The above CSR process repeats periodically for certificate and key rotation. Envoy to node-agent communication via Unix Socket Certificates/Keys are directly loaded into memory - secure and effective (no longer require reloading) Private key generation happen at node-agent locally Less bound with Kubernetes REF: https://www.youtube.com/watch?v=pKN4x4uXswU https://www.cncf.io/blog/2019/04/25/simplifying-microservices-security-with-a-service-mesh/ https://istio.io/docs/concepts/security/ https://cilium.io/blog/2018/08/07/istio-10-cilium/ https://istio.io/docs/tasks/security/authn-policy/ https://www.youtube.com/watch?v=Sx2luXC3kSU&t=2722s https://www.youtube.com/watch?v=eOI2aM9P7-c&t=2461s https://www.youtube.com/watch?v=GnjwaTcNKK4&t=185s https://www.youtube.com/watch?v=NiiZOszksGU https://www.youtube.com/watch?v=QlQyqCaTOh0
15. “docker swarm init” - Docker designates itself as a manager node. By default, the manager node generates a new self-signed root Certificate Authority (CA) along with a key pair, which are used to secure communications with other nodes that join the swarm. However, it is possible to provide external CA as well that can be cooperate level or public CA. The manager node also generates two tokens to use when you join additional nodes to the swarm: one worker token and one manager token. Each token includes the digest of the root CA’s certificate and a randomly generated secret. When a node joins the swarm, the joining node uses the digest to validate the root CA certificate from the remote manager and generate key pairs then submit CSR. The remote manager uses the secret to ensure the joining node is an approved node. Each time a new node joins the swarm, the manager issues a certificate to the node. The certificate contains a randomly generated node ID to identify the node under the certificate common name (CN) and the role under the organizational unit (OU). The node ID serves as the cryptographically secure node identity for the lifetime of the node in the current swarm. REF: https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ https://www.infoq.com/presentations/tls-swarm-pki/ https://www.youtube.com/watch?v=apma_C24W58