Security is always a concern. Microservices make some things easier to secure and somethings need to be paid attention to.
List of security issues to think about
- Network Layer of each service needs protection for exposed ports
- DNS, NTP are critical infrastructure resources when everything hinges on service discovery
- Each service requires transport layer security, request authentiaction and based on requirement additional authorization information
- Logs etc. required for audit trails need to be captured, stored and observed
- If services are geographically distributed, enabling TLS on them exposes the services to OSINT due to certification transparency logs
Network, Transport and Ports
Typically all services listen on TCP ports providing high level functionality wrapped in HTTP or RPC
In a traditional data center the defence in depth would start from the network layer itself. Means that whitelisted IP addresses could access certain services. But when containers are used for deploying the microservices a lot of this detail is lost in translation
AuthN, AuthZ and Access Token Pattern
Authentication will allow the microservice to choose whether to serve a request or not
Authorization will allow the microservice to choose whether to serve a request meant for a particular resource or not
Both of these are enabled by following the Access Token Pattern
Access Token Pattern continued
Under this JSON Web Token is a popular choice for mainly two reasons
- The identity of the requester is securely passed around
- Services can independently verify if the requestor is authorized to perform operations on it
Mostly used with a API Gateway, the main point of entry for clients to the microservice
Logs, obervability and monitoring
Every service will generate logs. For most workloads developers would need the ability to be able to read logs if they ever need to troubleshoot bugs. Any centralisation of such logs needs to be protected and has to be highly available. Since a lot of data will get generated there needs to be monitoring and alerting in place
Service to service security and secrets
Once we move past the whole idea that many microservices will be up and running, we reach a point where the service and the container running the service are one and the same thing for all intents and purposes. If at this point we believe that service to service communication needs to be protected with tokens some pre shared key needs to be baked into each container.
Whether it is a token or a certificate, we need to device a way to revoke, replace, refresh such tokens. For this to work well, the baking in needs to happen at the CI/CD level by including a secure vault like storage as offered by Hashicorp Vault or any of the cloud Key Management services.