Modern applications rely on authorizing user's access to their application. One of the best practice is to perform a OAuth2 authorization for the endpoint exposed by an application. These applications when broken down into smaller micro-services expose many endpoints as such, protecting all of them becomes a continuous and tedious job. A general pattern is to embed a OAuth2 client/library into each micro service to help protect these exposed endpoints. If these micro-services are being written in different languages, it adds additional complexity of keeping all libraries to its latest approved version and vulnerability free.
In this blog, we will look at a sidecar pattern which would help achieve the above stated drawbacks/overhead and additionally provide a uniformity among all your micro-services with respect to protecting endpoint with OAuth2 workflow. This pattern demonstrates how can you configure the application sidecar to generate and validate the minted JWT for each micro service without a single line of code change in your application in an easy maintainable fashion.
In a cloud native world, a sidecar is a well known pattern where functionalities of an application are segregated into a separate process to provide isolation and encapsulation. Important point here to note is that it is assumed that the sidecar and the application are residing in an encapsulated environment which is trusted. Thus, all the communications between an application and a sidecar are trusted.
This provides an opportunity to offload the authorization and authentication with the sidecar. The sidecar will let the incoming connection pass through the application only after a successful authorization and authentication. This pattern greatly helps a polyglot application.
For establishing the pattern, we will have an unprotected hello-world application with envoyproxy as the choice of sidecar. Envoy will be configured to protect the application.
The sidecar will be configured for:
1. Log in to the Linux machine
2. Write a hello world application which you want to protect. This can be written in your favorite language no restriction.
a. Open a new terminal.
mkdir -p /tmp/123 ; cd /tmp/123; echo "$HOSTNAME" > index.html ; python3 -m http.server --bind 127.0.0.1 8001
3. For IDA server, we are going to use Okta as our Identity server. Its very easy to setup. a. If you don’t have an Okta account, go ahead and create one. Once you have signed up, go through the following steps:
b. Make a note of the below inputs needed to setup the envoy sidecar
4. Envoyproxy binary: Pick the latest binary for your machine. Use func-e to download and install the binary.
a. Get basic understanding on envoy filters and their usage. We are going to use the below filters in this example:
b. Envoy static configuration: This is a bootstrap file used by envoy binary to load its configuration. Copy paste the content into a file and save as 'envoy.yml'.
- name: token
inline_string: <Your token secret here>
- name: hmac
inline_string: <Your token secret here>
- name: envoy.filters.network.http_connection_manager
- name: upstream
- name: envoy.filters.http.oauth2
client_id: <client id>
- name: envoy.filters.http.jwt_authn
- name: envoy.filters.http.router
- name: upstream-service
- name: oauth
c. Edit the envoy.yml and fill the missing configuration items. They are marked with <> brackets.
d. Start the envoy binary. It will start listening on localhost:8000
envoy -c envoy.yml
5. Open a browser on the VM and hit 'localhost:8000'
a. you would reach envoy proxy
b. envoy should redirect you to Okta server which will ask you to authenticate yourself. In case you are already logged in, this step will happen automatically and it will not prompt you.
c. upon successful authentication, control will be passed to the back-end application and application will display its content on the browser.
You can now try to extend the above example by
This setup can be very easily replicated in a Kubernetes platform where envoy and application container can reside in a pod.