Configure Secured Access or Unpublish Ports for some Services

[VincenzoFerme]

Services:

• Consul:
  • Still TODO: remove exposed /ui and secure it
• Experiments-Manager:
  • Still TODO (with Kong): remove 8070 and expose 8080
• Faban:
  • Still TODO: remove 9980 at some point. Currently we should enable access with credentials because we leave it open to access the Faban UI: http://faban.org/1.3/docs/guide/config/security.html
• Cassandra:
  • Still TODO: remove 9160 OR secure it. Currently we are going to secure it and at some point t we'll have a service to access data and we'll remove the exposed port
• Kafka:
  • Still TODO: secure it
• Minio:
  • Still TODO: secure it

Notes:

-Swarm:

• Currently the Docker daemon of the SUT server included in a swarm are only exposed on a local network of the servers (References for what we did: https://docs.docker.com/engine/quickstart/, https://github.com/docker/docker/issues/4766#issuecomment-48376821). In real environment we should setup TLS connections.

[VincenzoFerme]

We need to decide how to handle secured access to the services and between the services. Some thoughts on this:

• We define users in the test-manager, and currently this service acts as the entrypoint of benchflow. We need to add user based authentication (e.g., using https://github.com/dropwizard-bundles/dropwizard-api-key-bundle or https://github.com/wdawson/dropwizard-auth-example).
• We need to implement an api gateway in the test-manager so that we can control the access of the users to the APIs, and redirect the calls to the other services. For now this is fine and we do not need more complex and dedicated solutions as for example https://getkong.org.
• Some of the APIs have to be exposed to the users, some of them are instead only available among the services. For this we need to control the access with solutions like: https://github.com/dropwizard-bundles/dropwizard-api-key-bundle. We use APIs for the services to communicate when queue are not suitable, as described in https://www.programmableweb.com/news/why-messaging-queues-suck/analysis/2017/02/13
• We then have some services (e.g., Cassandra) that are used internally by BenchFlow services, but that we might want to expose to developers. For this we should rely on security mechanism provided by the services themselves.

An example of API that is private is the trial API currently exposed by the test manager: https://github.com/benchflow/benchflow/blob/devel/benchflow-test-manager/application/src/main/java/cloud/benchflow/testmanager/resources/BenchFlowTrialResource.java

[jeppe-style]

In dropwizard there is already functionality for authentication. Could we not use that?

Each service could then have its own user and password and in that way authenticate.