Part 2: Simplify Security in Kubernetes with Keycloak and Dapr: A Comprehensive Integration Guide

This post is a continuation of Part 1: Simplify Security in Kubernetes with Keycloak and Dapr: A Comprehensive Integration Guide.

This part will explore another Oauth2 Client Credentials middleware component of Dapr for the same step we had in Part 1. We will only replace the middleware.http.oauth2 with middleware.http.oauth2clientcredentials

We will create a new oauth2clientcred.yaml with content similar to oauth2 config with additional differences of headerName and endpointParamsQuery

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: oauth2
spec:
  type: middleware.http.oauth2clientcredentials
  version: v1
  metadata:
  - name: clientId
    value: "dapr-demo"
  - name: clientSecret
    value: "<secret>"
  - name: scopes
    value: "openid profile"
  - name: authURL
    value: "http://<keycloak-server>/realms/demo/protocol/openid-connect/auth"
  - name: tokenURL
    value: "http://<keycloak-server>/realms/demo/protocol/openid-connect/token"
  - name: redirectURL
    value: "<Kube cluster IP>"
  - name: headerName
    value: "authorization"
  - name: endpointParamsQuery
    value: "state=randomtext"

Update the Pipeline.yaml with HTTP handlers type to `middleware.http.oauth2clientcredentials`

kind: Configuration
metadata:
  name: pipeline
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"
  httpPipeline:
    handlers:
    - type: middleware.http.oauth2clientcredentials
      name: oauth2    

We can deploy oauth2 client credentials and pipeline

kubectl apply -f oauth2clientcred.yaml
kubectl apply -f pipeline.yaml

We roll out the existing deployments to enforce quick updates on the existing configuration

kubectl rollout restart deployment/goechoapp
kubectl rollout restart deployment/dapr-operator -n dapr-system

Now if we open the Kind Cluster IP Address and invoke the goechoapp

http://172.18.0.2/v1.0/invoke/goechoapp/method/echo?text=hello

You will see a difference, the access token is generated, but we can access this page without the Keycloak authorization flow.

Echo App responds with an access token

We can try sending a POST request without any authorization header

curl 'http://172.18.0.2/v1.0/invoke/goechoapp/method/echo?text=hello' \
--header 'Content-Type: application/json' \
--header 'Cookie: gosessionsid=VVdCWmJad2JNcGdBbEdnbVlYeFFpU3RRaXZkT0hpZnE=' \
--data '{
    "tasdas":"adsad",
    "asd":"asd",
    "sad":"sad"
}'

You see in the response with a valid access_token from Echo API.

{
    "access_token": "Bearer eyJhbGciOiJ...",
    "query_param": "hello",
    "body": {
        "asd": "asd",
        "sad": "sad",
        "tasdas": "adsad"
    }
}

In the case of the Oauth2 Client credential grant, the middleware sends a Client Credential grant request to Keycloak and retrieves an access token as the response. Dapr component sidecar injects the access token as an authorization header (headerName) into the application. In this case, Echo API will get the request with an authorization header injected with a token. Because the Echo API returns an authorization header in the response.

Conclusion

Oauth2 Client credential grant is useful for Services to Service communication cases where one service needs to send an access token as an authorization header to another service protected by the Keycloak.

Thank you for reading the article. If you like this post, give it a Cheer!!!

Follow the Collection: Keycloak for learning more…