Skip to main content

Deploy Datawiza Access Proxy with a Web App using Kubernetes

About 6 min

Deploy the Datawiza Access Proxy (DAP) with a Header-Based Web App using Azure Kubernetes Service (AKS) and enable SSO and Granular Access Control

Preview

In this tutorial, we will use Azure Kubernetes Service (AKS) to deploy the Datawiza Access Proxy (DAP) alongside our Header-Based App. After deploying the DAP, we will see how to enable SSO policies and granular access control. The IdP used in this example is Azure Active Directory, though you could easily substitute this process with another IdP, such as Okta.

Part I: Azure AD Configuration

You will need to register an OIDC application in the Azure AD management portal and obtain the following 3 values for this application:

  • Tenant ID
  • Application (client) ID
  • Client Secret

These values will later be used to set up our Application in the Datawiza Cloud Management Console (DCMC). Please follow IdP Configuration Guide: Microsoft Azure AD on how to obtain those keys/values.

Note: When configuring your application, you will have to skip Step 7 since we have not yet set up our Kuberntes cluster and do not have an External IP for our Redirect URL. We'll come back to this step later.

Part II: Create Application on Datawiza Cloud Management Console (DCMC)

We need to create a new deployment on the DCMC, which will contain our application. We'll generate a PROVISIONING_KEY and PROVISIONING_SECRET which will be needed when configuring AKS. This is in order for the DAP to get the latest configurations and policies from the DCMC.

Sign Into DCMC

  1. Login to the DCMCopen in new window.

DCMC login

Create New Deployment

  1. Click the orange button Getting started. Specify a Name and a Description. Click Save. New deploymentNew deployment

Create and Configure our Application

Configure our application with the following fields:

  • Name: AKS app
  • Public Domain: https://example.com:9772
    • Note: Since we haven't set up our Kubernetes cluster yet, we don't know what our External IP will be. We'll leave this field with a default value and update it later.
  • Listen Port: 9772
  • Upstream Server:
    • If deploying using standalone mode, we can make use of kubedns by giving http://header-based-app:3001 or by giving the ClusterIP of our Header-Based app.
    • If deploying using sidecar mode, we can use http://localhost:3001 since both containers are sitting within the same pod.
  • Click Next.

In this example, we are deploying the DAP in sidecar mode. !Step 4

IdP Configuration

  1. Choose Microsoft Azure Active Directory from the drop down menu.

Populate the fields of the form with the keys/values obtained from IdP Configuration Guide: Microsoft Azure AD. Choose Azure IdP Alternatively, you can use One Click Integration to configure the Azure. Choose Azure IdP

Note Down Provisioning Keys

Note down your PROVISIONING_KEY and PROVISIONING_SECRET. We will need these values later in our Kubernetes deployment.yaml file.

API keys

Assigning IdPs to our Applications

  1. Select the IdP Configuration tab. Make sure that you can see your application (AKS App) and that the Identity Provider is AZURE. If not, go ahead an Assign the IdP you just created to your application.

Assign IdP

Enabling SSL

  1. Select the Advanced tab from the menu. Select SSL tab and click Edit. Enable the SSL option and select Self-Signed for the Cert Type. Make sure to Save your changes. Enable SSLEnable SSL

Part III: Deploying the DAP using AKS

Deployment Modes

The DAP offers two deployment options--standalone mode and sidecar mode. Sidecar mode is when the DAP and our application are running in the same pod. Standalone mode is when the DAP is deployed in a different pod than where the application resides. We will go through both deployment options in this section.

Before we get started, make sure you have created a Kubernetes Service and added a Kubernetes Cluster. The sample cluster used here, aks-test, has 3 nodes. We will use the Azure Cloud Shell to interact with our cluster and to run kubectl.

Standalone Mode

In standalone mode, the DAP and the Header-Based app are each containers inside their own pod. Since they are in the same cluster (aks-test) but are in different pods, the DAP will proxy the incoming traffic to the Header-Based app via its Cluster IP.

Standalone mode

The following is an example deployment.yaml file. The DAP is given type: LoadBalancer in the spec section of its Service file in order for it to have an External IP.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: datawiza-access-broker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: datawiza-access-broker
  template:
    metadata:
      labels:
        app: datawiza-access-broker
    spec:
      containers:
      - name: datawiza-access-broker
        image: registry.gitlab.com/datawiza/access-broker
        imagePullPolicy: Always
        ports:
        - containerPort: 9772
        env:
        - name: PROVISIONING_KEY
          value: ##########################
        - name: PROVISIONING_SECRET
          value: ##########################
      imagePullSecrets:
      - name: cred
---
apiVersion: v1
kind: Service
metadata:
  name: datawiza-access-broker
spec:
  type: LoadBalancer
  ports:
  - port: 9772
  selector:
    app: datawiza-access-broker
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: header-based-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: header-based-app
  template:
    metadata:
      labels:
        app: header-based-app
    spec:
      containers:
      - name: header-based-app
        image: registry.gitlab.com/datawiza/header-based-app
        imagePullPolicy: Always
        ports:
        - containerPort: 3001
      imagePullSecrets:
      - name: cred
---
apiVersion: v1
kind: Service
metadata:
  name: header-based-app
spec:
  ports:
  - port: 3001
  selector:
    app: header-based-app

Since the DAP and the Header-Based app are not public docker images, you will need to login to our container registry. This is represented by the cred field in our deployment.yaml file under imagePullSecrets.

# cred: credential for DAP and Header-Based app
kubectl create secret docker-registry cred --docker-server=registry.gitlab.com --docker-username=datawiza-deploy-token --docker-password=##########################

If you don't have the appropriate deploy tokens, please contact info@datawiza.com.

After creating your credentials, apply your deployment.yaml file using kubectl:

kubectl apply -f deployment.yaml

Run watch kubectl get pods and check that STATUS is Running for each pod. Make sure they are not ImagePullBackOff or ErrImagePull. Note that there should be two pods with one container in each, since we are running in standalone mode.

Standalone pods

Run kubectl get svc to find the EXTERNAL-IP of the DAP.

Standalone svc

Important Step!

Once we have our External IP, we have to go back to Azure AD to fill in our Redirect URL field. Also, go back to the DCMC to populate the Public Domain field within our application.

  • Redirect URL on Azure AD: https://<EXTERNAL-IP>:9772/authorization-code/callback
  • Public Domain on DCMC: https://<EXTERNAL-IP>:9772

When visiting the DCMC, you should also see that the Status of your Deployment is Online. If you select the + icon, you can make sure the Access Proxy that is connected matched the pod of your Access Proxy in your Kubernetes cluster.

Sidecar Mode

In sidecar mode, the DAP and the Header-Based app are each containers within the same pod. The DAP will proxy the incoming traffic to the Header-Based app via localhost in the same pod.

Sidecar mode

The following is an example deployment.yaml file. The DAP is given type: LoadBalancer in the spec section of its Service file in order for it to have an External IP.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: datawiza-access-broker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: datawiza-access-broker
  template:
    metadata:
      labels:
        app: datawiza-access-broker
    spec:
      imagePullSecrets:
        - name: cred
      containers:
      - name: datawiza-access-broker
        image: registry.gitlab.com/datawiza/access-broker
        ports:
        - containerPort: 9772
        env:
        - name: PROVISIONING_KEY
          value: ##########################
        - name: PROVISIONING_SECRET
          value: ##########################
        imagePullPolicy: Always
      - name: header-based-app
        image: registry.gitlab.com/datawiza/header-based-app
        ports:
        - containerPort: 3001
        imagePullPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: datawiza-access-broker
spec:
  type: LoadBalancer
  ports:
  - port: 9772
  selector:
    app: datawiza-access-broker

Since the DAP and the Header-Based app are not public docker images, you will need to login to our container registry. There are two sets of credentials that need to be created (one for the DAP, another for the Header-Based app). These are represented by the regcred and newcred fields in our deployment.yaml file under imagePullSecrets.

# cred: credential for DAP and Header-Based app
kubectl create secret docker-registry cred --docker-server=registry.gitlab.com --docker-username=datawiza-deploy-token --docker-password=##########################

If you don't have the appropriate deploy tokens, please contact info@datawiza.com.

After creating your credentials, apply your deployment.yaml file using kubectl:

kubectl apply -f deployment.yaml

Run watch kubectl get pods and check that STATUS is Running for each pod. Make sure they are not ImagePullBackOff or ErrImagePull. Note that there should only be one pod with two containers, since we are in sidecar mode.

Sidecar pods

Run kubectl get svc to find the EXTERNAL-IP of the DAP.

Sidecar svc

Important Step!

Once we have our External IP, we have to go back to Azure AD to fill in our Redirect URL field. Also, go back to the DCMC to populate the Public Domain field within our application.

  • Redirect URL on Azure AD: https://<EXTERNAL-IP>:9772/authorization-code/callback
  • Public Domain on DCMC: https://<EXTERNAL-IP>:9772

When visiting the DCMC, you should also see that the Status of your Deployment is Online. If you select the + icon, you can make sure the Access Proxy that is connected to your Deployment matches the pod of your Access Proxy running in your Kubernetes cluster.

Visiting our External IP

When we now visit our External IP (in our sidecar example, https://52.179.117.133:9772), we will see a Warning: Potential Security Risk Ahead message. This is because we chose to use Self-Signed Certificates for our application. Once we accept the risks and continue, we should be prompted to sign in with Microsoft Azure. Our Header-Based app should have SSO enabled.

If you are seeing the Azure AD login page but are unable to login (Microsoft keeps asking for your username and password repeatedly), ensure that you have created a user for your AD domain. Logging in with the root account will not work. Your username should be in the form of user@your_domain.onmicrosoft.com. Note that if you are already logged into Azure AD in your browser, you may need to logout to see the login page.

Azure AD login

Part IV: Granular Access Control and Further Steps

Please refer to Step4: Pass User Attributes and Step5: Achieve Granular Access Control to interact further with the additional features provided by the Datatwiza Access Proxy.

Summary

In summary, we have seen how to deploy the DAP in a Kubernetes environment and implement SSO policies using both the sidecar and standalone modes. We also have the ability to create multiple applications within our singular Deployment, and can assign each of our apps a different IdP if we so choose.

You can also reach us on discordDiscord
Copyright © 2023 Datawiza Technologies Inc