Skip to content

GitHub Actions Blog Series: Deploying with Microsoft AKS

GitHub Actions Blog Series: Deploying with Microsoft AKS

In my last blog post, we discussed the need for businesses to adopt distributed development and delivery models in order to bring value to their customers. With the advent of distributed organizations, companies have had to adapt to new ways of both developing and making products available to their consumers. Cloud technologies have come to the forefront in providing solutions that organizations can leverage in order to meet and drive consumer demand.

As companies continuously evolve through their cloud journeys, the need to streamline and scale automation workflows grows exponentially due the increasing number of applications and speed needed to meet consumer demand. Orchestration tools have thus become a hot topic across countless organizations requiring this type of automation. It started with on premise tools such as Jenkins and has now evolved to a more distributed cloud-centric model with products like GitHub Actions.

However with distributed applications comes a broader, and more complex threat landscape. This is why businesses have been searching for ways to automate and embed secure coding into their development workflows to ensure that costly vulnerabilities are not deployed into production. 

For our next installment of our GitHub Action blog series, I will go over an ultra-quick way to get started with incorporating application security into your existing developer onboarding via GitHub Actions and Contrast Security, using Azure Kubernetes Service (AKS) as the deploy target.


This step-by-step guide assumes you will be instrumenting Contrast Security with a containerized Java application that will be deployed to an Azure Kubernetes Service (AKS) PaaS Environment.

In order to work with the Contrast Security AKS GitHub Action, you will need the following in place:

  • An AKS cluster
  • A GitHub account
  • Contrast Security License
  • Contrast Security API Connection Details
  • Azure Service Details

If you do not have a paid license for a Contrast Security agent, you can visit the Contrast Security website and register to use the Contrast Security Community Edition, which is free of charge.

Further details can be found in the Documentation section of this blog.


Let’s get started by creating two repository secrets for our Contrast Security and Azure credentials named `CONRAST_CREDS_FILE` and `AZURE_CREDS_FILE` respectively.

Note - The repository secrets will need to be in JSON format.

The contents of the CONTRAST_CREDS_FILE contain details necessary for the Contrast Agent to communicate with the central Contrast Security Team Server:

  • contrast_api_url
  • contrast_api_username
  • contrast_api_api_key
  • contrast_api_service_key
  • contrast_agent_java_standalone_app_name
  • contrast_application_version

The AZURE_CREDS_FILE repository secret contains the following Azure resource details necessary to interact with the AKS Service:

  • azure_application_id
  • azure_tenant_id
  • azure_client_secret
  • Azure_subscription_id - the subscription used for the AKS Service
  • Azure_resource_group_name - resource group the cluster is under
  • Azure_region - region where the cluster is deployed
  • Azure_container_registry - URL used for the container registry

Next, we will paste the following workflow YAML and create a new file in the location `.github/workflows/main.yml`. This YAML is a basic workflow that will pull the specified github repository code locally onto the GitHub Action Runner. Once the code is pulled locally, the Contrast Security AKS GitHub Action will build and deploy a containerized PetClinic Java application with a Contrast Security Agent baked inside. The sample repository can be found here and the location of the workflow YAML is under the `workflow` directory.

name: Build and Deploy Java app to Azure Kubernetes Service

      - main


  IMAGE_NAME_TAG: 'aks-petclinic-testing:contrast-demo-4'
  APPLICATION_MANIFEST: '/example/kubernetes/petclinic.yaml'
  APPLICATION_DOCKERFILE: '/example/docker/Dockerfile'
  CLUSTER_NAME: 'aks-testing-ga'
  APPLICATION_ARTIFACT: '/example/docker/spring-petclinic-1.5.1.jar'


    name: Build and Deploy
    runs-on: ubuntu-latest
    - name: Checkout
      uses: actions/checkout@v2
    - name: Contrast Security Azure Kubernetes Service Build-Deploy
      uses: admiralappsec/aks-github-action@main
      id: contrast-build-deploy
        application-manifest: $
        application-dockerfile: $
        application-output-image-name-tag: $
        cluster-name: $
        contrast-security-credentials-file: $
        azure-credentials-file: $
        application-artifact: $

The workflow file above will trigger on all commits to the `main` branch. Looking at the inputs associated with the GitHub Action, you’ll need to make sure the following are passed:

  • Application-manifest - location of the kubernetes manifest
  • Application-dockerfile - location of the dockerfile
  • Application-output-image-name-tag - name of the resulting container image with Contrast baked inside
  • Cluster-name - name of the AKS cluster
  • Contrast-security-credentials-file - location of the Contrast Security credentials file
  • Azure-credentials-file - location of the Azure credentials file
  • Application-artifact - artifacts associated with the docker build (dockerfile needs)

Commit this file and go to the ‘Actions’ tab and watch the action work!

Note - the GitHub Actions setting must be set to ‘allow’ on the repository itself, and this can be found under the ‘Settings’ tab.

The action should complete within 2-3 minutes. When completed, open the job and towards the end of the STDOUT, you will see links to your deployed service. Click the link. 

You should see the application up and running.

Navigate to the Contrast Security UI and you will see the application’s security posture start to populate the screen.

What’s Next

Now that we’re up and running using the Contrast Security Platform, we can begin to leverage all the telemetry provided by looking into various aspects of our application which may hurt our bottom line. Remember, security is not limited to networking aspects. Having access to an application means that any vulnerabilities found within the application can be potentially exploited for malicious use.

By incorporating application security into your existing workflows, your organization ensures that your customers are safe to interact with your products where they don’t have to worry about dangers lurking from within vulnerable code bases.  

For information on how organizations start to incorporate application security into their workflows day one using Contrast Security and Azure Kubernetes Service (AKS), refer to the link here.


Example Contrast Security Credential File:

    "contrast_api_username": "xxx",
    "contrast_api_api_key": "xxx",
    "contrast_api_service_key": "xxx",
    "contrast_agent_java_standalone_app_name": "xxx",
    "contrast_application_version": "xxx"

Example Azure Credential File:

    "azure_application_id": "xxx",
    "azure_tenant_id": "xxx",
    "azure_client_secret": "xxx",
    "azure_subscription_id": "xxx",
    "azure_resource_group_name": "xxx",
    "azure_region": "xxx",
    "azure_container_registry": "xxx"

Note - The Service Principal will need enough permissions to build, commit, pull, and deploy a container image to AKS

Documentation can be found at these locations:


Mark Tomcza, Sr. Alliance Solutions Architect, Contrast Security

Mark Tomcza, Sr. Alliance Solutions Architect, Contrast Security

Mark Tomcza is a Sr. Alliance Solutions Architect with Contrast Security and has been in the technology field for over 10 years, predominately focused on modern and future distributed technology implementations. Mark has a background in full stack software development with extensive experience around containers and microservices. He has helped companies all over the world modernize their software delivery and transition into full scale digital transformations.