AuthN/AuthZ using sidecar proxies on Kubernetes

This demo contains the following components:

• A resource server running on port 80
• A sidecar proxy running on port 8000, in the same pod as the resource-server

The sidecar proxy intercepts all calls to the resource server and runs authN/authZ checks against them. If incoming calls pass these checks, they are forwarded to the resource-server. Otherwise, a 403 Forbidden reply is sent back.

Running the demo

Pre-requisites

• Install and configure Minikube
• Install Kubectl

Testing

• Switch to the Kubernetes namespace where the demo application should be deployed.
• Navigate to the /deploy-config directory.
• Run the deploy-minikube.sh script to deploy the demo.
• Run minikube service list to get the external base url of the deployed service.
• Try the API methods described below, with authorized and unauthorized users.

API

The resource server allows reads and writes using the /data API. The URLs are:

Read Data

curl -X GET "${BASE_URL}/data?key=${KEY}" -H "Authorization: ${USERNAME}"

Response:

{
  "<KEY>": "<VALUE>"
}

Write Data

curl -X POST "${BASE_URL}/data?key=${KEY}&value=${VALUE}" -H "Authorization: ${USERNAME}"

Response:

{
  "<KEY>": "<VALUE>"
}

Permissions

Username	Read Data	Write Data
alice	yes	no
bob	yes	yes
chuck	no	no

Further exploration

• Make the AuthN/AuthZ proxy configurable and independent of the resource server
• Use lightweight servers/frameworks for the AuthN/AuthZ proxy for performance
• Add trusted issuer check and external authorization checks
• Other use cases: auditing, tracing

References

• Kubernetes - Pods - Resource sharing and communication
• Kubernetes - Cluster Networking
• Implementing a reverse proxy server in Kubernetes using the sidecar
• Hand-crafting a sidecar proxy and demystifying Istio