I'm working on building a web application using the microservice architecture pattern in a set of docker containers and I'm wondering about the importance of securing the communication between the application and the microservices.

The application and microservices will be linked together in a cluster using the --link option and the microservices will not expose any ports. Communication between the application and microservices will be via HTTP. The application will expose port 80 only.

I've thought about what might happen if the application is compromised - it seems to me that if that happens, the details of any calls made to the microservice APIs will be in the hands of the attacker (including any secret keys, if implemented - see the scheme discussed below), so they'll have access to any data that can be obtained through those API calls, but they won't have access to the database or any other resources that are used exclusively by the microservices. But this is true regardless of whether the API calls are authenticated by the method given above or not.

How secure is this? Do I need to add an additional layer of authentication to the API calls?

I'm considering this scheme for authentication: Designing a Secure REST (Web) API without OAuth

Basically, the idea is that the application and the service have a shared secret which is used to encrypt the message contents in order to determine if the message comes from an authorized source and if it has been tampered with. At present, the APIs will be available only to the application, although at some point in the future it might be helpful to make some microservice APIs available to other applications, potentially not running in docker containers, and I know that a robust authentication scheme will be required at that point - is the scheme discussed above adequate?

1 Answer 1


From the docker documentation on container linking, it's possible to see that the standard setup for links is to create an internal network on the docker host which is used by the containers to talk to each other.

This network isn't exposed off-host by default so from that perspective it should be secure from network based attackers (i.e. no ports or services are accessible over the network so nothing to attack).

If an attacker gets access to the docker host, well the security of the containers is likely in trouble anyway with or without linking, depending on the privilege level the attacker can get, as with access to a privileged account on the docker host all bets are off.

The other likely attack scenario is where the attacker gets access to the externally facing part of your containerized application. Here there again isn't much downside to having used links without additional security as once they have access to the front-end application server, they're likely to get the credentials needed to access the back-end services as those will be present on the front-end server.

One note of caution would be that if you design relying on container linking security, you may run into issues if you later scale up your solution to split components of the application onto different VMs or indeed different physical hosts, as you would then potentially be exposing those services to untrusted networks.

In summary I'd say that container linking should be considered a relatively secure means of inter-container communication.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .