Skip to content

GitHub Actions Blog Series, Part 2: Deploying with Amazon EKS

GitHub Actions Blog Series, Part 2: Deploying with Amazon EKS

Over the past few years, we’ve seen almost every company that runs software change their strategies to include some type of cloud technology to support their workloads. A distributed world requires some type of distributed cloud availability to support availability of those workloads across the world. Many businesses have dubbed their organizational shift towards a distributed development and delivery model as their ‘Cloud Journey’ or, more broadly, their ‘Digital Transformation’. 

With a distributed way of work, there comes a need to orchestrate and scale application workloads with as much speed and consistency as possible. This is where GitHub Actions comes into play. Using GitHub Actions, organizations are able to achieve a balance between speedy automation, distributed availability, and minimal overhead at scale by leveraging codified templates made available and consumed via an application’s GitHub source code repository. 

However, imminent and widespread code vulnerabilities such as the recent Log4Shell zero-day have caused many organizations to reevaluate how they can protect their digital assets from bad actors, and deliver secure code without impeding developers. With limited security expertise available, businesses have realized that the most scalable approach is to embed security into existing development workflows - including ones tailored for cloud-native environments.  

For part two of our ongoing GitHub Action blog series, we’ll be detailing how to get started with incorporating security into your existing developer onboarding via GitHub Actions and Contrast Security, using Amazon Elastic Kubernetes Service (EKS) as the deployment mechanism.


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

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

  • An EKS cluster
  • A GitHub account
  • Contrast Security License
  • Contrast Security API Connection Details
  • Amazon 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 Amazon credentials named `CONRAST_CREDS_FILE` and `AWS_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 AWS_CREDS_FILE repository secret contains the following Amazon resource details necessary to interact with the EKS Service:

  • aws_access_key_id
  • aws_secret_access_key
  • aws_region - region where the cluster is deployed
  • aws_container_registry - URL used for the container registry

Note - Traditional access key for authentication is used, the github action is being currently updated for token auth.

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 EKS 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 Amazon Elastic Kubernetes Service

      - main
  IMAGE_NAME_TAG: 'eks-petclinic-testing:contrast-demo-1'
  APPLICATION_MANIFEST: '/example/kubernetes/petclinic.yaml'
  APPLICATION_DOCKERFILE: '/example/docker/Dockerfile'
  CLUSTER_NAME: 'eks-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 Amazon Elastic Kubernetes Service Build-Deploy
       uses: Contrast-Security-OSS/integration-eks-github-action@main
       id: contrast-build-deploy
        application-manifest: $
        application-dockerfile: $
        application-output-image-name-tag: $
        cluster-name: $
        contrast-security-credentials-file: $
        aws-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 EKS cluster
  • Contrast-security-credentials-file - location of the Contrast Security credentials file
  • AWS-credentials-file - location of the AWS 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 lend itself to malicious exploitation. 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. It is in your organization’s best interest to ensure that your products are safe to be consumed by your customers by incorporating aspects of application security into your delivery value stream.

For information on how organizations start to incorporate application security into their workflows day one using Contrast Security and EKS, refer to the link here and visit 


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 AWS Credential File:
  "aws_access_key_id": "xxx",
  "aws_secret_access_key": "xxx",
  "aws_region": "xxx",
  "aws_container_registry": "xxx"

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.