# Deploy the DAB 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 Broker (DAB) alongside our Header-Based App. After deploying the DAB, 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 DAB to get the latest configurations and policies from the DCMC.

# Sign Into DCMC

  1. Login to the DCMC.

DCMC login

# Create New Deployment

  1. Click the orange button Get started. Specify a Name and a Description. Click Save.

New deployment

# Provisioning Keys

  1. Create your set of provisioning keys. This enables the DCMC to verify the DAB's authenticity. Specify a Key Name and set the Expires field to be 1 month later.

Provisioning Key

# 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

# 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.
  • 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.
    • See Deployment Modes in Part III: Deploying the DAB using AKS for more information on the difference between standalone and sidecar mode.
  • Default Action: Allow
  • Select Create.

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

# 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 SSL tab from the menu. Enable the SSL option and select Self-Signed for the Cert Type. Make sure to Save your changes.

Enable SSL


# Part III: Deploying the DAB using AKS

# Deployment Modes

The DAB offers two deployment options--standalone mode and sidecar mode. Sidecar mode is when the DAB and our application are running in the same pod. Standalone mode is when the DAB 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 DAB 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 DAB 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 DAB 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 DAB 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 DAB 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 DAB.

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 Broker that is connected matched the pod of your Access Broker in your Kubernetes cluster.


# Sidecar Mode

In sidecar mode, the DAB and the Header-Based app are each containers within the same pod. The DAB 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 DAB 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 DAB 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 DAB, 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 DAB 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 DAB.

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 Broker that is connected to your Deployment matches the pod of your Access Broker 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 Certificiates 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 Broker.


# Summary

In summary, we have seen how to deploy the DAB 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.