Shipa Blog

Latest updates on our products, plus helpful articles relating to Kubernetes, container security, microservices and more

Terraform meets AppOps

Terraform is the popular choice among teams

The growing adoption of microservices and Kubernetes gave rise to the need to efficiently manage, schedule, and control Kubernetes clusters, where tools like Terraform are helping many organizations address those challenges today.

Terraform is a popular choice among DevOps and Platform Engineering teams as engineers can use the tool to quickly spin up and edit environments directly from their CI/CD pipelines.

While these teams use Terraform to build a standardized cluster management process within their organization, the challenge now is how they can use Terraform as the tool to:

  • Help their development teams deploy their applications 
  • Implement controls on how these applications are deployed
  • Make it part of their overall internal developer platform (IDP) initiative and efforts

And that’s where Terraform comes up short for most teams.

Using Terraform to deploy applications

We often meet with teams who try giving developers Terraform templates to reduce complexity when deploying their applications on Kubernetes. Although a very valid initiative, we often see results and challenges such as:

  • The increasing number of new applications deployed adds complexity and time spent building and maintaining Terraform templates.
  • It creates an ever-increasing dependency on the DevOps or Platform Engineering team instead of enabling self-service for developers.
  • Implementing controls over a large number of applications is a challenge, and Terraform itself won’t make it easier.
  • Terraform does not support advanced deployment or rollout strategies. It’s an “all or nothing” type of operation.
  • Deploying the application is not the end. There needs to be an application operational model that developers can leverage to manage their apps post-deployment.

If you research user’s experiences with the Helm and Kubernetes provider for Terraform, you will quickly see that they don’t solve the pain points above well. Because of that, users end up limiting Terraform’s capabilities to infrastructure provisioning only.

The truth is, the challenges above do not remove the fact that you already have Terraform in place, so the question now is: How do you take Terraform one step further to provision apps, governance, and integrate into your Internal Developer Platform (IDP) strategy?

That’s where the Shipa provider for Terraform comes in.

Taking Terraform to a new level

Shipa integrates with Terraform to create an application operating model (AppOps), delivering a solid governance workflow and developer experience deploying, managing, securing, and supporting applications on Kubernetes.

Applying an application operating model (AppOps), you can establish a clear separation of concerns while improving the developer experience, increasing application governance, and plugging Terraform into your IDP strategy.

We can explore a few different use-cases that the Shipa provider for Terraform allows you to address and deliver value quickly:

Use case 1: Deploying Applications

Enabling developers to deploy applications quickly is often one of the critical requirements you must address when implementing Kubernetes.

Because of that, it’s not uncommon to see teams spending time helping developers build Terraform deployment templates for their applications. But what if you could give your developers a simple way to deploy applications by themselves and save DevOps and Platform engineering time?

Let’s see below how you can give your developers that capability through the Shipa provider:

terraform {
  required_providers {
    shipa = {
      version = "0.0.1"
      source = ""
provider "shipa" {}
resource "shipa_app" "app1" {
  app {
    name = "terraform-app"
    teamowner = "dev"
    framework = "dev-framework"
resource "shipa_app_env" "env1"
  app = "terraform-app"
  app_env {
    envs {
      name = "SHIPA_ENV1"
      value = "test-1"
resource "shipa_app_cname" "cname1" {
  app = "terraform-app"
  cname = ""
  encrypt = true
resource "shipa_app_deploy" "deploy1" {
  app = "terraform-app"
  deploy {
    image = ""

Using the example above, you create an application, assign a CNAME to it, and deploy it using an existing Docker image.

The exact spec defined above by the developer can be used to deploy across different Kubernetes clusters and Linux servers, which means your developer experience is not impacted by the underlying infrastructure you decide to use.

Also, all governance rules defined by the DevOps or Platform Engineering team will be automatically applied by the Shipa framework when the application is deployed.

Overall, the application specification model above is straightforward to be understood and leveraged by developers, allowing Terraform to be used by your development teams as part of your Internal Developer Platform (IDP)

Use case 2: Defining Policies

Although critical, defining policies and governance at scale on Kubernetes can quickly become a daunting and complex task, especially as you scale across different teams, applications, and requirements. 

Terraform combined with Shipa can enable you to quickly define governance rules across RBAC, resource consumption, registry control, network policy, and more. Let’s look at the example below:

terraform {
  required_providers {
    shipa = {
      version = "0.0.1"
      source = ""
provider "shipa" {}

resource "shipa_framework" "prod-framework" {
  framework {
    name = "production-services"
    resources {
      general {
        setup {
          public = false
          default = false
          provisioner = kubernetes
        security {
          disable_scan = true
          scan_platform_layers = false
          ignore_components = ["apt", "bash", "..."]          
          ignore_cves = ["CVE-2020-27350", "CVE-2011-3374", "..."]        
        app_quota {
          limit = "5"
        access {
          append = ["dev-team"]        
        plan {
          name = "production-plan"
        network_policy {
          ingress {
             policy_mode = "allow-custom-rules-only"
             custom_rules {
              id = "rule-name"
              enabled = true
              description = "rule description"
              allowed_apps = ["app1", "app2"]              
              ports {
                port = 8080
                protocol = "TCP"
          egress {
             policy_mode = "allow-all"
          disable_app_policies = "false"
        container_policy {
          allowed_hosts = ["", ""]

Unpacking what this definition means:

  • Provisioner: It defines if this framework will be bound to a Kubernetes cluster or Linux node 
  • Security: The application security scan level executed before and after application deployment and any vulnerabilities that should be treated as an exception.
  • Application Quota: Defines how much applications deployed through this framework can scale
  • Access: Controls which teams can deploy their applications using this framework
  • Plan: Implement limits to how much memory and CPU can be consumed by applications deployed through this framework.
  • Network Policy: Defines service to service communication policy for both ingress and egress. This section also allows you to enable users to customize the network policies for their specific applications post-deployment.
  • Container Policy: Limits the registries that can be used to pull images from when deploying applications, avoiding images from non-trusted repositories to be used.

Now, Terraform becomes a powerful tool to enable you to tackle security requirements for microservice applications.

This approach can also feed into your DevSecOps initiatives, given the fact the above definitions are easily understood by broader teams, rather than giving them complex, lengthy, and numerous Rego policies, for example.

Use case 3: Terraform part of your IDP

Further to application deployment and governance, Terraform should integrate into the overall IDP strategy.

Your teams should be equipped to continuously manage their applications or governance policies, closing the CI/CD and Operations loop.

Your teams should be able to easily integrate applications and alerts into the existing stack, have detail observability over applications and policies, have easy access to logs and audit reports, and more, which then allows you to build an end-to-end application operation model for your IDP.

Shipa for Kubernetes - observability

What’s Next?

You can find detailed information about the Shipa provider for Terraform here: Terraform (

We will soon be releasing additional content on how both developers and DevOps can address different scenarios, all the way from provisioning infrastructure to implementing policies and deploying applications.

Stay tuned!