Creating and Enforcing Organization-Wide Policies With Octopus Platform Hub

One of the many challenges with adopting platform engineering is turning tribal knowledge into a standard that can be shared across multiple teams.

Prior to the rise of what we now know as platform engineering, teams often had a set of standards defined before a service could be released into production or staging. This could be “80% test coverage” or “encryption at rest” if you stored any kind of data. 

While we can all agree that teams are as unique as the software they build, how do we ensure that these agreed-upon best standards are enforced across teams without slowing them down? 

In this hands-on demo, we will walk through how to use the new Platform Hub from Octopus Deploy to create reusable workflows for your teams, as well as create governance for compliance using policies. 

Why Platform Hub?

For years, whenever the topic of Platform Engineering came up, our instinct was: “Let’s build our own platform.”

But building from scratch often means reinventing the wheel, burning months of engineering effort, and still leaving developers with a fragmented experience. We’ve seen this over the years. 

So instead of endless YAML and half-integrated tools, you get a central hub where developers can self-serve infrastructure, discover golden paths, and move from idea to production safely and quickly.

You may ask, is Platform Hub a ready-made platform? The short answer is NO. 

Platform teams still own the platform, but with structure to scale without the overhead of building and maintaining internal tooling.

With connected templates, enforceable policies, and centralized governance, Platform Hub helps Platform teams define how software gets delivered across environments and teams, while giving developers the autonomy to move fast, safely.

Core concepts of Platform Hub 

The Octopus Platform Hub introduces two new concepts that are central to powering its reusable workflows. 

Process Templates. 

Process templates are complete, reusable deployment workflows that live in Platform Hub. A good way to think about them are blueprints for how software gets deployed across your environment.

Long-time Octopus deploy users might notice that this sounds a lot like Step templates, while step templates are individual building blocks (like "run security scan" or "send notification"), process templates are the entire deployment pipeline. 

Instead of each team assembling their own deployment process from scratch, inevitably creating 15 different versions of "deploy a microservice”  you define it once in Platform Hub.

Policies

Policies in Octopus deploy are rules written in Rego that run before every deployment. Unlike process templates, which define how to deploy, policies define what must be true for a deployment to proceed.

They answer questions like Is this project using an approved Process Template? Does this deployment have the required security scans? Policies run automatically. If a deployment violates a policy, it stops before any resources are touched.

Demo overview 

For this demonstration, you will be deploying a Helm chart to an external Kubernetes cluster via Octopus. While not the most flashy demo in the world, the real magic is the process around it, which involves governance using Octopus policies and not having to stitch together a hundred lines of yaml to get your deployment to work. 

The deployment itself is fully reproducible, powered by Octopus process templates. 

Demo prerequisites 

To follow along with the demo, you will need the following: 

• An Octopus Deploy account. You can sign up for a free account here.
• Access to a Kubernetes cluster. Civo Kubernetes was used in this demo; however, any other managed provider is fine. 
• A fork of this repository containing sample code that would be used for this demo.

Step 1: Creating an Octopus project 

In Octopus, Projects house individual applications; for this demo, you will need to create a new one. To do this, log back in to the dashboard and follow the steps in the screencast below.

The above screencast creates a Kubernetes project named “Invoicer” and selects “Git Repository” as where to store all its configurations. For this demo you will manage the K8s project with Helm.

As part of the setup process, you will need to connect your Octopus Deploy account to GitHub, which you will be prompted to do as soon as you create the project. 

Step 2: Connect your Kubernetes cluster to Octopus  

With a project created, you will need to connect your Kubernetes cluster. Octopus manages this using deployment targets, which could also be a virtual machine or a cloud provider; however, this demo will be Kubernetes-focused.  

Octopus interacts with your cluster via an agent that is installed using Helm. This agent is connected to your account and can be tied to a single or multiple projects.

Head back to the project you created earlier and follow the steps in the screencast to connect your Kubernetes cluster.

To continue following along with this demo, remember to run the output helm commands to connect to your cluster. 

Create a process template 

Navigate to Process Templates in Platform Hub and select  “Add Process Template”

Give the process template a NAME and an optional DESCRIPTION

On the screen right after you should see a search bar in the top left

Select the and configure the steps below

Once complete, hit commit  to save

‍

Step 3: Writing a Platform Hub policy 

Policies in Octopus are written using a domain-specific language called Rego. If that sounds familiar, it's likely because it is the same language Open Policy Agent uses. For a policy to take effect, it needs to be placed under .octopus/policies directory and saved with a .ocl extension. If you forked the example repository, you should have one already. 

Breaking down the policy 

Within the repository, there should be a single policy named securitychecks. The basic idea here is that no deployment should pass without using a process template. As mentioned earlier, at a high level, process templates allow you to bake in repeatable steps to make a deployment happen, so if you have security scans that need to happen before a prod release, you can bake it into a process template. 
‍

name = "Use correct process templates"
description = "enforce process templates for compliance"


scope {
    rego = <<-EOT
        package securitychecks 
        default evaluate := false
        evaluate := true if {
            input.Environment.Name == "Development"
            input.Project.Name == "Invoicers"
        }
    EOT
}


conditions {
    rego = <<-EOT
        package securitychecks
        default result := {"allowed": false}
        result := {"allowed": true} if {
            some step in input.Steps
            step.Source.Type == "Process Template"
        }
    EOT
}

Every process template begins with a name and description to ensure you can differentiate between them. Next is the scope , which defines where and when a policy should apply. In the example above, the scope ensures the rule only triggers for the Development environment and the Invoicer project.

With a scope defined, you need a condition. Conditions describe what must be true for a release to pass. They usually reference the steps inside a deployment and check whether required actions are present.

In the example policy, the condition is defined like this:

result := {"allowed": true} if {
    some step in input.Steps
    step.Source.Type == "Process Template"
}

‍

• result is mandatory; every condition must return a value named result. This object decides whether the deployment is allowed ({"allowed": true}) or blocked ({"allowed": false}).
• step.Source.Type == "Process Template" ensures the step isn’t just any task, but specifically a process template. 

Step 4: Making it all work 

With a policy in place and a deployment target configured, it is time to see if it gets enforced. Remember, the idea here is to ensure teams configure deployments correctly, which involves using a process template. As such, if the policy blocks a deployment, that will be considered a success. 

Head back to your Octopus account and follow the steps in the screencast below:

In the screencast above, the key parts to note are the use of a single step, which is the deployment of a Helm chart, with a target tag specified alongside the chart directory. If you forked the repository, this should be located in the batch-invoice folder. 

A few seconds before your deployment runs, you should be hit with an error message like this: 

You might have also noticed that Octopus runs the policy checks before the deployments begin. This ensures that in any environment, your deployments stay compliant.  

To rectify this, you will need to use the process template created earlier as shown in the screencast below:

Shifting left with compliance 

Moving fast without making security look like an afterthought is a challenge for many teams. In the cloud-native world, we have had large success making deployments repeatable through the use of containers and tools like Helm. However, compliance at scale is a different story.

In this article, we covered some of the challenges that have arisen alongside platform engineering, how Octopus Deploy is filling in this gap, and how to use the new policy feature to help you ensure your deployments are compliant at scale.

If you liked this and would like to learn more, here are some ideas:

The Octopus Deploy team has put together a series of comprehensive YouTube videos on Platform Hub. Check them out:

• An introduction to Platform Hub - Continuous Delivery Office Hours
• Platform Hub: a first preview
• Deploy on Friday, Ep. 109 -- Platform Hub is here!

Love or hate, DORA metrics are useful for understanding DevOps success within your organization, learn how to extract that from Octopus Deploy here.

‍