DevNet Associate (DEVASC) v1.0Application Deployment and SecurityHard
A team is deploying a new service to a Kubernetes cluster. This service needs to communicate with another existing service within the same cluster. They want to ensure that all communication between these services is encrypted by default without requiring application-level changes or manual certificate management for each service. Which Kubernetes-native solution or approach best facilitates this requirement?
- AManually deploying TLS certificates to each service's pod.
- BConfiguring network policies to encrypt traffic.
- CUsing Kubernetes Secrets to store encryption keys for application-level encryption.
- DImplementing a service mesh with mTLS enabled.
Show answer & explanationAnswer & explanation
Correct answer: D. Implementing a service mesh with mTLS enabled.
A service mesh (e.g., Istio, Linkerd) with mTLS (mutual TLS) enabled automatically encrypts all service-to-service communication within the mesh, without requiring changes to the application code or manual certificate management, directly addressing the scenario's requirements.
Why the other options are wrong
- A. Manually deploying certificates involves significant operational overhead and is what the team wants to avoid.
- B. Network policies control traffic flow but do not encrypt the traffic itself.
- C. This is for application-level encryption, requiring changes to each application, which the team wants to avoid.
Service Mesh (mTLS)
An infrastructure layer for handling service-to-service communication in a microservices architecture. When configured with mTLS, it automatically encrypts and authenticates all traffic between services without requiring changes to the application code.
- Automates service-to-service encryption (mTLS).
- Manages traffic, observability, security.
- Transparent to application code.
Memory trick: Mesh encrypts automatically, policies filter traffic, secrets store keys.