Protecting Microservices on PaaS

PaaS platforms provide a container mechanism for building microservices based application. Each of the microservice is an application in itself in the context of the PaaS platform. The applications on PaaS platform typically (by default) have routes/URL associated with it which is exposed over the internet (or intranet in case of Private PaaS).

For a front end application it is desirable to have a URL access to the application from the internet (or intranet) but not for all of the microservices that are hosted on the PaaS. In the pictorial above, the web application need to access services #1/#2 but it would not be desirable for anybody from outside to be able to access these services. Out of the box on PaaS all of the microservices and the web application are exposed over a URL associated with the PaaS application.

In this article I will go over some of the options available on CloudFoundry/Bluemix to address the issue discussed above. Depending on your specific scenario you may chose to use the right option.

PS: For PaaS platforms other than CloudFoundry/Bluemix I suggest you check the specific features or services available on the platform to address this issue.

Option#1         Use Messaging instead of HTTP protocol

Instead of exponsing the microservice over REST/HTTPs expose it using messaging. Here is a recipe:

  1. Create an instance of the messaging service such as MessageHub or MQLight
  2. Microservice implementation will bind to the messaging service instance
  3. Microservice implementation will listen to the incoming messages and reply-back to the response queue
  4. Microservice implementation will be deployed with the cf push --no-route option so that a route will not be created for it

Consumer of the microservice will send the request as a MQ message instead of REST/HTTPS and receive back a message in the response topic/queue. 

Pros:

  • Better scaling
  • Not accessible from outside the PaaS platform
  • Inherent service discovery mechanism

Cons:

  • Complexity of the provider and consumer code
  • Cost of the messaging service instance

 

Read more MQ Light

Read more Message Hub / Kafka

 

Option#2               Use Bluemix SSO Service

The microservices and the application may be  protected by leveraging the Bluemix SSO ServiceHere is the recipe:

  1. Create an instance of the SSO service
  2. Configure the service instance for appropriate Auth provider (SAML/LDAP, Social, Cloud directory)
  3. Secure the application components
    • microservices and the front end application
    • or just the microservices in which case the consumer application may need to do more work

Pros:

  • Simplicity of the solution
  • Well known service endpoints available out of the box

Cons:

  • Consumer of the service will need to set the call header
  • Costly in terms of the SSO service usage

Read more

Option#3         Use Virtual machine (or Containers) & Service Discovery instead of PaaS

 

In the IaaS model it is not an issue to restrict the access to microservices, as the developer is in control of defining the network (in other words endpoints/url) configurations. A separate subnet may be created to add the microservices which need to have a restricted access (like a database server). Here is a recipe for IaaS:

  1. Create a server (or server group) - do not assign a public IP address to it. The server IP will not be accessible from outside the Bluemix space
  2. Create an instance of the Bluemix Service Discovery
      Ps: This service is in Beta as of March 7th, 2016
  3. Bind your microservices to the Service disovery instance and code as per the Service Discovery specifications 
  4. Deploy your microservices code on the server
  5. Consumer application(s) will bind to the same instance of the Service Discovery
    • ​​Get the microservice endpoint for the service
    • Make a call to the microservice endpoint

Pros:

  • Most secure option
  • Higher levels of scaling

Cons:

  • More moving parts & effort
  • Some implementation of proxy will be needed for access from outside the Bluemix space
  • Cost of the servers on IaaS > Cost of the app on PaaS

Read more

Option#4         Use Bluemix API Management for creating proxies

 

You may use the Bluemix API service for protecting your microservices. The API gateway pattern is a common pattern recommended by the microservices experts for the following reasons:

  • Policy based service management 
  • Security management
  • Visibility & Analytics
  • Service endpoint / Discovery

These aspects do not directly solve the issue discussed above. In other words you may create a proxy for your microservice and apply the policies but the consumer may simply bypass it and call your microservice directly. One way to address the issue is depicted below. In this schematic the proxy is created on the API management platform that takes care of providing basic auth credentials for the microservice. The consumer executes the microservice interface via the API management service instance where an appropriate security and QOS policy may be applied e.g., here the service endpoint requires the consumer to provide the client key and security, it can easily be switched to OAuth or other poilicies as needed.

 

 

    Pros:

    • Provides better control on the consumption of microservices
    • Straightforward service discovery

    Cons:

    • May be an over kill e.g., policy management is not needed as consumption is expected only from the known consumers
    • Cost of the API service instance
    • Does not solve the issue directly - proxy needs to be coded and maintained

    Option#5         Security implementation in the microservices application

    In this solution option, microservices will be responsible for implementing some form of basic authentication. An appropriate library may be used for this purpose based on the choice of platform e.g., Node based microservice may use passport & middleware package, Java based implementation of microservice may leverage the Jax-RS/Interceptor and annotations to achieve the desired result. At a highlevel the implementation will look like the pictorial below:

     

    • A cloud foundry user provided services will be created with the {"secret" : "set any secret"}
    • The microservice application and the consumer application will be bound to the same instance of the UPS
    • Flow:
      1. ​​Consumer will read the UPS and set the HTTP Header (X-YOUR-DEFINED-AUTH-HEADER) to the secret
      2. Microservice will receive the payload and header
      3. Microservice reads the secret from the UPS
      4. Microservice - filter or middleware will reject the service call (with HTTP code 405) if the value provided in header does not match with the secret retrieved from the UPS

    Pros:

    • Simple to implement
    • Simple to manage & cost effective
    • Quite secure - the org admin will be the only one knowing the secret :-)

    Cons:

    • Intrusive as authentication is part of the application code
    • Consumer outside the Clodfoundry Org/Space will need to know the secret

     

    Please note that this one of the ways to cook this recipe, there are multiple ways to achieve it. 

    JAVA Jax-RS Sample code available in GitHub

     

    Comments

    Thanks for a good post on this, I look at the github code, however it seems that all the logic of protection is probably in acloudfancloudutils-01.jar. is there a way to share the source code of this. Also do you have similar code that are using spring-security