DEV Community: Denis Rendler

OpenTofu's advanced features like workspaces, modules, and data transformations enable efficient infrastructure management through better organization and code reusability.

Denis Rendler — Thu, 19 Dec 2024 12:30:17 +0000

OpenTofu - Infrastructure configuration management

Denis Rendler ・ Dec 16 '24

OpenTofu - Infrastructure configuration management

Denis Rendler — Mon, 16 Dec 2024 10:21:00 +0000

OpenTofu is a great tool for managing infrastructure and in this notes series I am going to share a few tips I found useful as I find myself using it for more than just infrastructure management.

Workspace Management

OpenTofu workspaces provide a mechanism for managing multiple environments of your infrastructure using the same OpenTofu code files.
By default, OpenTofu operates in a 'default' workspace, but you can create additional workspaces to maintain separate states for different deployments.

Think of it this way: when you write OpenTofu code to manage your resources, that code is like a blueprint.
Workspaces allow you to use that same blueprint to manage multiple "instances" of your infrastructure, each with its own state file that tracks what's been managed.

This is particularly valuable for scenarios like:

developing and testing new OpenTofu code in isolation and avoid disrupting production systems
managing infrastructure in different regions just by using different variable files (ie. using different encryption keys)
or to separate different projects that require deploying similar infrastructure (ie. deploying the same app for multiple clients)

OpenTofu's operations are marked in a state file which it's like a ledger that keeps track of all resources OpenTofu manages.
When you run OpenTofu commands, it first checks this state file to understand what exists and what needs to change.
After making changes, OpenTofu updates the state file to reflect the new reality of the managed resources.

While all this state management happens automatically in the default workspace, creating additional workspaces provides a way to maintain separate states for independent operations, all while using the same OpenTofu code. This approach provides isolation without requiring duplicated code or complicated workflows.

Let's take as example using OpenTofu to manage a MikroTik RouterOS configuration.

The resources file would look like this:

# main.tf
...
########## configure VLANs
resource "routeros_interface_vlan" "interface_vlan" {
  for_each = var.vlans

  interface = each.value.interface
  name      = each.value.name
  vlan_id   = each.value.vlan_id
}
########## end configure VLANs

While the code remais the same, the variables would be different between environments, like this:

for testing environment or for developing the OpenTofu code we would have this:

# env/testing.tfvars
vlans = {
  "VNET_TEST_1" = {
    interface = "ether1"
    name      = "VNET_TEST_1"
    vlan_id   = 10
  }
  "VNET_TEST_2" = {
    interface = "ether2"
    name      = "VNET_TEST_2"
    vlan_id   = 11
  }
}

while for the production systems the variables would look similar to this:

# env/production.tfvars
vlans = {
  "PRIVNET" = {
    interface = "ether1"
    name      = "PRIVNET"
    vlan_id   = 100
  }
  "DMZ" = {
    interface = "ether2"
    name      = "DMZ"
    vlan_id   = 101
  }
}

Creating the different workspaces requires using the workspace comamnd:

$ tofu workspace new testing # where testing is the workspace name

Then simply issue an apply command using the testing variables:

$ tofu plan -out=plan.out -var-file=env/$(tofu workspace show).tfvars
$ tofu apply plan.out

If the testing processes are successful the new RouterOS config can be easily applied by simply switching to the production workspace and issueing the exact same commands.

When using workspaces, it's important to parameterize your OpenTofu configuration to handle differences between environments.
Use OpenTofu variables to define values that may change across workspaces. This allows you to maintain a single source of truth while still customizing each environment as needed.

In this way you can safely develop and test your OpenTofu code in isolation and "promote" the code to production just by using a different variables file.

Organize Your Modules Like a Pro

As OpenTofu codebases grow, managing infrastructure code can become a challenge, especially when the same resource blocks are used across multiple files and projects.

This is where OpenTofu modules come in handy – they're reusable building blocks that encapsulate groups of resource blocks dedicated to specific tasks, making the infrastructure code easier to maintain and consistent.

When organizing modules, it's helpful to group them based on functionality or architectural components – for example, separate modules for networking, compute, and storage components.

This modular approach will reduce code duplication while making the OpenTofu code more readable and maintainable.

Root and child modules

An OpenTofu module is basically a directory containing OpenTofu files. Interestingly, every OpenTofu project is itself a module - which is called the "root module". This root module includes all resources and variables defined in the .tf and .tfvars files of the main OpenTofu code.

For OpenTofu, the concept of modules is recursive - meaning that any module can call other modules which are known as "child modules" for the root module. These child modules can even be reused multiple times within the same module code. Think of it like nesting building blocks, where each block (module) can contain other blocks to complete a task.

When using a module block in the OpenTofu code to reference another module, OpenTofu will include all the resources defined in that module as part of the current OpenTofu code.

Using this approach the code can be organized hierarchically and efficiently while drastically lowering the number of bugs and improving code quality and reusability.

Module sharing

There are several ways to share modules, the more common ones being:

local paths - where the modules are stored in a folder inside the main OpenTofu project
module registry - a remote registry for distributing modules as well as providers
Git - any accessible Git repository can be used as a module (ie. Github, Gitlab, etc.)

Building a module

To create a module start by creating a new folder and add the following files:

netbox-customization
├── LICENSE.md
├── README.md
├── example
│   └── data.tfvars
├── main.tf
├── outputs.tf
└── variables.tf

There are no constraints on the file names within an OpenTofu module. You can use any file name with a .tf or .tfvars extension, and OpenTofu will process all files in a directory, irrespective of their names. The order in which files are named doesn't matter either since OpenTofu loads all files and combines them into a single configuration.

However, there are common conventions that I recommend to be followed:

main.tf - primary configuration file
variables.tf - variable declarations
outputs.tf - output declarations
LICENSE.md and README.md - license and readme documentation
example/ - folder containing example of usages and variables

That said, there are still a few important points to note:

files must have the .tf extension (or .tf.json for JSON format)
override files must end in _override.tf or _override.tf.json
files beginning with . or _ are ignored
variables file have the .tfvars extension (or .tfvars.json for JSON format)
files ending in .auto.tfvars or .auto.tfvars.json are automatically loaded by OpenTofu to populate variable values without explicitly specifying variable files on the command line

While it's not mandatory, using consistent file names across modules helps fellow colleagues understand the code faster.

# main.tf
...
resource "netbox_custom_field_choice_set" "custom_field_choices" {
  for_each = var.custom_field_choices

  name                 = each.value.name
  extra_choices        = local.custom_field_choices[each.key].choices
  description          = try(each.value.description, null)
  order_alphabetically = try(each.value.order_alphabetically, false)
}

# variables.tf
variable "custom_field_choices" {
  description = "Map of custom field choice sets"
  type = map(object({
    name                 = string
    choices              = list(string)
    description          = optional(string)
    order_alphabetically = optional(bool)
  }))
  default = {}
}

Using the module

as a local module:

# environments/dev/main.tf
module "vpc" {
  source = "./modules/netbox-customization"

  custom_field_choices = customizations.custom_field_choices
 ...
}

as a Git stored module:

# environments/dev/main.tf
module "vpc" {
  source = "github.com/rendler-denis/tf-mod-netbox//netbox-customization"

  custom_field_choices = customizations.custom_field_choices
  ...
}

Notice the double slashes in the path - that is not a typo. It is needed when the module is residing in a subfolder inside a Git repository.

Now, to download and prepare the module inside the workspace run the following command:

$ tofu init

Dynamic Configuration with Data Sources

Data sources in OpenTofu allows querying and fetching information from existing infrastructure or external services, making this data available for use in the OpenTofu code during runtime.

Unlike resources that create and manage infrastructure, data sources are read-only and provide a way to reference existing resources, whether they're managed by OpenTofu or not. For example, OpenTofu can use data sources to look up an existing VPC, query an IPAM system for the first available IP etc.

The key advantage of data sources is that they enable dynamic and flexible infrastructure configurations. Instead of hardcoding values that might change over time (like subnet IDs), data sources can be used to automatically fetch the most current information. This approach reduces maintenance overhead, prevents errors from outdated values, and allows OpenTofu code to adapt to changes in the infrastructure automatically.

Let's look at an example:

# Query existing VPC
data "aws_vpc" "existing" {
  tags = {
    Environment = OpenTofu.workspace
  }
}

# Query available AZs
data "aws_availability_zones" "available" {
  state = "available"
}

# Create subnets dynamically
resource "aws_subnet" "private" {
  count             = length(data.aws_availability_zones.available.names)
  vpc_id            = data.aws_vpc.existing.id
  cidr_block        = cidrsubnet(data.aws_vpc.existing.cidr_block, 4, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "private-subnet-${count.index + 1}"
    Type = "private"
  }
}

Efficient Data Handling with Data-Only Modules

Data-only modules in OpenTofu are specialized modules that focus solely on computing and providing data without creating any actual infrastructure resources. They serve as a way to encapsulate complex data transformations, lookups, or business logic that can be reused across different parts of OpenTofu project code.

Using this concept, modules that manage infrastructure can remain single purpose, decupled and overall easier to maintain and share. It also reduces the execution times because calculations or data retrieval is done only once and the data can be reused by all code being executed during runtime.

Let's quickly look at an example data-only module from my Netbox modules.

The definition for the data-only module remains the same:

the folder structure

netbox-data-org
├── LICENSE.md
├── README.md
├── main.tf
├── outputs.tf
└── variables.tf

the module code

# main.tf

data "netbox_site" "sites" {
  for_each = toset(var.sites)
  name     = each.value
}

data "netbox_tenant" "tenants" {
    for_each = toset(var.tenants)
    name     = each.value
}
...


# variables.tf
variable "sites" {
  description = "List of site names to retrieve from Netbox"
  type        = list(string)
  default     = []
}

variable "tenants" {
  description = "List of tenant names to retrieve from Netbox"
  type        = list(string)
  default     = []
}
...


# outputs.tf
output "sites_map" {
  description = "Map of site names to their IDs"
  value       = {
    for name, site in data.netbox_site.sites : name => site.id
  }
}

output "tenants_map" {
  description = "Map of tenant names to their IDs"
  value       = {
    for name, tenant in data.netbox_tenant.tenants : name => tenant.id
  }
}
....

using the data-only module in a root module

# main.tf - the main OpenTofu project file (ie. the root module)
module "netbox-org-data" {
  source = "./lib/netbox/netbox-data-org"

  sites       = data.sites
  tenants     = data.tenants
  ...
}

# using the fetched data
module "netbox-racks" {
  source = "./lib/netbox/netbox-racks"

  depends_on = [module.netbox-org, module.netbox-org-data]

  ...

  site_id_map     = module.netbox-org-data.sites_map
  tenant_id_map   = module.netbox-org-data.tenants_map
}

# using the same data in other modules
module "netbox-devices" {
  source = "./lib/netbox/netbox-devices"

  depends_on = [module.netbox-org, module.netbox-org-data]

  ...

  site_id_map     = module.netbox-org-data.sites_map
  tenant_id_map   = module.netbox-org-data.tenants_map
}

To access data from a data-only module, simply reference its outputs using the standard module output syntax: module.[module_name].[output_name]. This follows the same pattern you'd use to reference outputs from any other type of module.

The depends_on is not really necessary, but it does make the dependency explicit for other users.

Final thoughts

The combination of OpenTofu's workspaces, modules, and data-only modules creates a robust foundation for maintainable, scalable, and efficient infrastructure code. Workspaces provide the necessary isolation for testing and development, modules reduce code duplication and improve reusability, and data-only modules offer a clean approach to handling complex data operations.

While these concepts can introduce additional complexity, mastering them will help create more robust infrastructure-as-code. These tools represent essential components in the modern infrastructure management toolkit, whether applied to small deployments or large-scale infrastructure projects.

P.S.: The concepts discussed in this note are also applicable to any Terraform code. For brevity, I only mentioned OpenTofu, but feel free to apply these principles to your Terraform projects as well.

Keeping secrets from your pipelines

Denis Rendler — Thu, 21 Mar 2024 16:15:54 +0000

In this article, I invite you to explore a solution I developed that leverages the Keeper Secrets Manager SDK to provide a REST API for retrieving credentials from the Keeper Enterprise Password Manager platform.

In a Continuous Integration/Continuous Deployment (CI/CD) environment, the automation of building, testing, and deployment of applications requires access to various secrets, such as API keys, database passwords, and credentials for third-party services. And although CI/CD platforms offer some sort of secrets management functionality, maintaining these secrets is still a pain point for teams.

Leveraging the Keeper Secrets Manager SDK

One of the problems that I faced using Keeper Secrets Manager, the CI/CD app for Keeper Enterprise Password Manager, is that I needed to install it on each run of the pipelines. Further complicating things, when using Docker agents, which resets the build environment even between stages, the installation process can be cumbersome because images were to minimalistic and lacked dependencies which I had to track down before being able to install the app itself. I ended up creating custom base images for the Gitlab runners, but when colleagues needed to use their own images they were forced to revert to the install process and we ended up in the same dependency hell.

Luckily, the Keeper team provides several SDKs, one of which is for Go. As such, I came up with the idea of building a Go app that would expose a REST endpoint, and using the Keeper Secrets Manager SDK I could connect to the Keeper Enterprise Password Manager to retrieve the secrets.
The idea opened up several usage scenarios, one of which is adding the app as a service container to the Gitlab runners that will be available to be queried without the need to install anything else. Just provide it the KSM_CONFIG data, either as an environment variable in the container or pass it through a request header, and it will connect to the correct Keeper Enterprise Password Manager vault.

Prerequisites

Unfortunately, at the time of writing, Keeper Secrets Manager is available only for Business accounts.
To configure a Keeper Secrets Manager application to access your Keeper Enterprise Password Manager secrets, you can follow the excellent tutorial on the Keeper's website: https://docs.keeper.io/secrets-manager/secrets-manager/quick-start-guide

KSM-Api wrapper

To begin using my project, the first step is cloning the Github repository onto your local machine:

git clone https://github.com/Hexagonal-Software/ksm-api.git

Since the project is developed in Go, you'll need to download its dependencies after cloning:

cd ksm-api
go mod download

You have the option to run the application by building it as an executable or packaging it in a Docker image. I am using it as a standalone daemon on servers where I ran build pipelines directly on the machine, and use a Docker image where the build environment uses Docker agents. In a later section I will provide a configuration for running it as a service container for Gitlab runners.

The project includes multiple Make commands to streamline the build process.

For creating a Docker image with the KSM-Api executable use:

make release-docker OPTS="--platform=linux/amd64" REPO="denisrendler/kms-api"

When the release-docker command completes you can find the image in your local Docker instance. Note that the image will be tagged with the latest code tag retrieve from the Git repository, which is 0.1.0 at the time of this writing. This is added automatically by the make command.

To run the app in a Docker container, you must configure the KSM_CONFIG data as an environment variable when creating the container:

export KSM_CONF="W2FkZCB5b3UgYmFzZTY0IGVuY29kZWQgS2VlcGVyIGFwcGxpY2F0aW9uIGNvbmZpZyBkYXRhIGhlcmVdCg=="

docker run --name=ksm-api -ti -p 8086:8086 -e "KSM_CONFIG=${KSM_CONF}" denisrendler/ksm-api:0.1.0

With the provided KSM_CONFIG data, you can access any secrets managed by the Keeper Secrets Manager using a simple curl request:

curl --globoff 'ksm-api:8086/api/v1/secret/<record UID or name>/<field OR custom_filed>/<field name>'

Additionally, you can pass the KSM_CONFIG data as a request header:

export KSM_DATA="W2FkZCB5b3UgYmFzZTY0IGVuY29kZWQgS2VlcGVyIGFwcGxpY2F0aW9uIGNvbmZpZyBkYXRhIGhlcmVdCg=="

curl -H "KSM_CONFIG: ${KSM_DATA}" --globoff 'ksm-api:8086/api/v1/secret/<record UID or name>/<field OR custom_filed>/<field name>'

The path parameters mirror those used by the Keeper Secrets Manager app's secret notation subcommand, as described in the following table:

Parameter	Description	Example
record UID or name	The UID or the name of the secret. I recommend using the name because it makes it easier when switching between environments.	oxhtLx9qrQIzeSXBtvQj2Q my_keeper_secret
field or custom_field	Use `field` if the data you want to retrieve is part of the secret's type, ie. password when it is a login or host[hostName] when it is a server type. Use `custom_field` when the data is stored inside a field type that is not part of the secret's template, ie. the field was added using the `Add Custom Field` button.	field
field name	The field name you want to retrieve.	password host[hostName] host[port]

Configure KSM-Api as a Gitlab service container

The easiest way to have the service container always available is to edit your runner configuration and add the following lines:

[[runners.docker.services]]
   name = "denisrendler/kms-api:0.1.0"
   alias = "ksm-api"

Now, define a KSM_CONFIG environment variable and add your base64 config data. Make sure to uncheck the Protect variable checkbox to make the variable available to all pipelines.
By default, Gitlab will not automatically pass user defined environment variables to service containers. To pass your KSM_CONFIG data from the CI/CD variable, you must explicitly define it in your .gitlab-ci.yml:

variables:
  KSM_CONFIG: ${KSM_CONFIG}

That is it! Whenever you need to retrieve a secret you can use a curl request to get it.

Design decisions

There are a couple of design decisions that you need to be aware of:

the application does not handle TLS connections since it is build to be run in a limited environment on a local system or containerised environment. This way the app avoids issues with requests not handling self-signed certificates.
error messages are only available in the logs as a precaution to avoid dumping sensitive information in CI/CD logs.
since this is an external application, CI/CD platforms might not obfuscate or otherwise hide sensitive information if dumped into the logs. Also, you will need to take care of workspace cleanup after running the pipeline if you dump to disk information like SSH keys.

If you find a use case where these decisions might have a bigger impact, open an issue on the Github repository and we can take it into account to add new functionality.

Contributing

The project started from an idea I had to resolve a pain point I encountered. But, if you feel that further functionality can bring more value to the app I am open to suggestions and even code contributions.
Just open a new issue or pull request on the Github repository and let's discuss it.
Bug reports are also welcomed.

Wrapping up...

While Keeper Enterprise Password Manager is a great password manager with an excellent zero-knowledge architecture, for me one of the more tedious aspects of managing CI/CD pipelines has been to maintain the Keeper Secrets Manager (KSM) app installation, a process that not only introduced potential points of failure but it has also deterred adoption for many of my colleagues.
My project addresses this pain point by integrating seamlessly with Keeper Enterprise Password Manager through the Keeper Secrets Manager SDK, and using it as a service container it eliminates the need for repetitive installations. It offers a streamlined, secure way to manage and access secrets across the pipelines, significantly reducing build times and enhancing the security and reliability of CI/CD processes. This solution not only simplifies the developer's workflow but also ensures that your secrets are always managed efficiently and securely.

Designing Security Workflows using Gitlab CI Templates

Denis Rendler — Wed, 21 Feb 2024 09:32:47 +0000

The modern software development lifecycle is comprised of multiple stages, among them are installing of dependencies, building applications from source code, and running testing tools on the application - steps that can be found even in the smallest web applications. But repeating these steps after every commit can quickly become tedious and cumbersome for teams.

That is why I believe that concepts like Continuous Integration (CI) and Continuous Delivery (CD) are fundamental practices in modern software development and aim to streamline and automate the process of delivering code changes.
The CI process involves the automatic integration of code from multiple contributors and typically includes the steps for automating builds and running tests to ensure that new code changes do not break or disrupt the existing codebase. Continuous Delivery extends this automation to ensure that the code changes are automatically prepared and ready to be deployed to a production environment. This means that at any given time, the software is in a deployable state, allowing teams to release new changes to customers quickly and safely. Together, CI/CD enables more efficient and reliable software development cycles, promoting rapid releases while maintaining high quality and stability.

In recent years, as the focus on cybersecurity has grown, a new approach known as DevSecOps has gained momentum. This methodology builds on the CI/CD pipelines workflows by incorporating security tools that conduct Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). This integration offers rapid feedback, enabling teams to identify and address known vulnerabilities before they are merged into the codebase.

Overview of GitLab CI/CD

GitLab, an open-source DevOps platform, has introduced the DevOps practices through a human-friendly language known as YAML. By utilizing predefined and intuitive tags, we can design complex workflows for our projects. However, I've often discover that as a project grows, so does the complexity of its GitLab pipeline YAML file. Managing a single file becomes challenging, and modifications frequently resulted in conflicts.

To tackle this issue, I leveraged the capabilities of the YAML language, such as aliases and anchors, to reduce code redundancy. Additionally, I've sometimes moved instructions from GitLab's CI/CD configuration file to scripted commands or created custom Docker images which contained the necessary tools allowing me to reduce often repeatable tasks. One other effective method was to create Gitlab reusable pipeline templates and afterwards just include them in my projects.

Creating Pipeline Templates for Security Tools

All the code I am using in this guide implementation can be found in my public repository: https://github.com/httpsec-eu/gitlab-security-templates

Pre-requisites:

To perform the steps describe in the guide you will need access to a Gitlab instance to create two repositories: one repository will be used for authoring the templates and the second repository will be used to showcase the usage of the templates. If you don't have an on-premise Gitlab instance you can easily create a free account on Gitlab.com at: https://gitlab.com/users/sign_in
Additionally, you will need a Docker runner registered to the repository with the code in order to run the demo pipeline.

Configuring the templates repository

A GitLab template is a YAML document that may define an entire pipeline or specific tasks to be integrated into additional pipelines, with the distinction largely lying in the content of the template itself. In this guide, I'll demonstrate how to create a pipeline designed to be added to existing pipelines, introducing a security tool named Syft which generates a project's components list, also known as an SBOM.

When setting up a template repository, I often use the following organizational structure:

├── docs
│   └── sbom.md
├── templates
│   └── sbom.yml
├── LICENSE.md
└── README.md

This format helps me keep the documentation and any relevant information quickly available which improves the usability and user experience.

After creating the folder structure, let's add the job code. Below is the code I am using for this guide - which can also be found in templates-repo/template/sbom.yml folder in the repo mentioned previously.

# templates/sbom.yml
spec:
  inputs:
    stage:
      default: security-dependency-sbom
      description: The stage where the job will run
    docker-image:
      default: denis.rendler/dependency-scan:1.0
      description: The Docker image used to run the job
    path:
      default: ./
      description: The path, file or docker image to scan
    report-type:
      default: cyclonedx-json
      description: The type of report to build
      options:
        - cyclonedx-json
        - spdx-json
    report-file:
      default: dependency-sbom.json
      description: The file name for the report
    report-expire:
      default: "1 year"
      description: The amount of time Gitlab should keep the report
      options:
        - "30 days"
        - "90 days"
        - "1 year"

---

"Build $[[ inputs.report-type ]] SBOM: $[[ inputs.path ]]":
  stage: $[[ inputs.stage ]]
  image: $[[ inputs.docker-image ]]
  script:
    - syft scan $[[ inputs.path ]] -o $[[ inputs.report-type]]=$[[ inputs.report-file ]]
  tags:
    - infosec
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"  # Add the job to merge request pipelines if there's an open merge request.
    - if: $CI_OPEN_MERGE_REQUESTS                       # Don't add it to a *branch* pipeline if it's already in a merge request pipeline.
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: always
  variables:
    GIT_DEPTH: "50"
  artifacts:
    name: "sbom-$[[ inputs.report-type ]]-$CI_COMMIT_SHORT_SHA"
    paths:
      - $[[ inputs.report-file ]]
    expire_in: $[[ inputs.report-expire ]]
    reports:
      dependency_scanning: $[[ inputs.report-file ]]
  allow_failure: false

Given that the template is designed for use across various projects, it's essential to allow for the modification of certain job values to facilitate an easy integration into existing pipelines. Thus, I am making use of Gitlab's spec:inputs feature to configure the behavior of the job when it is added to the pipeline. We can also configure default values that help incorporate the job immediately without additional configuration.
While I could also use environment variables, I found that the side effects can lead to a lot of confusion and increase in debug time. For example, if I were to set the path input as an environment variable, I would have to rename it to avoid overriding the value of the Linux environment variable called PATH.

After adding the template, and documenting its use cases and usage using a Markdown file in the docs/ folder, I like to create a new Git tag. Using Git tags I can make changes to the template without fear that I will break my colleague's pipelines, while at the same time providing them with the option to update at their own pace.
Based on my experience, this workflow significantly increases the adoption of security tools, since teams do not fear that their release processes will be affected. This is particularly due to the fast feedback loop on known vulnerabilities, allowing teams to address these issues prior to the code being merged.

Using the templates

To use the template, GitLab provides a YAML keyword: include - which merges external files with the current pipeline YAML.
In the second repository, create a file named .gitlab-ci.yml and position it in the root directory.
Add the code provided below at the top of the file and update the stage input with the name of the stage where you want the job to run:


include:
  - project: 'denis.rendler/ci-templates'
    file: '/templates/sbom.yml'
    ref: 0.1
      inputs:
    stage: testing

The required keywords are: project, file and ref.
The project keyword specifies the project from which the template is imported. The file keyword determines the import's path and file, which is relative to the repository. And the ref keyword directs GitLab to utilize the tag 0.1.
Alternatively, a branch name or commit SHA can be used, though this approach is generally recommended for development phases or when testing the template.

Final thoughts

Building custom Gitlab's CI/CD templates along with custom Docker images we can easily design and implement cybersecurity workflows that can be reused to secure many company projects.
Leveraging a SemVer versioning system the templates we design can be integrated into the projects at their own pace, or updated to new versions without fear of breaking project pipelines.
Taking advantage of the smaller Docker images and securing access only to private repositories, topics I discussed in my previous articles, I believe we can achieve a more robust infrastructure against supply-chain attacks.

Hardening Docker with OPA and Harbor

Denis Rendler — Sat, 03 Feb 2024 15:53:19 +0000

In my article Docker Chronicles - Securing Docker instances with OPA and Harbor I am discussing the benefits that Open-Policy-Agent (OPA) and Harbor bring to securing Docker instances.

This post aims to guide you through the technical steps that I implemented for leveraging OPA and Harbor to not only secure your Docker containers but also to streamline the management of the policies. With OPA's powerful policy-as-code capabilities and Harbor's efficient image management system, you'll discover how to build a Docker ecosystem that's robust, secure, and compliant with industry best practices.

Let's begin.

The Setup

The code repository we will be using can be found here: https://github.com/httpsec-eu/opa-article

First we need to create the Gitlab repository for our policies. I named my repository OPA policies. If you want to use the bash commands you should change the environment vars to your own values.

export GL=gitlab.example.com      
export AUTH_TOKEN=gl-123456789ABCDEFG

curl --request POST --header "PRIVATE-TOKEN: ${AUTH_TOKEN}" \
     --header "Content-Type: application/json" --data '{
        "name": "opa-policies", "description": "OPA Policies", "path": "opa-policies",
        "namespace_id": "1", "initialize_with_readme": "true"}' \
     --url "https://${GL}/api/v4/projects/"

Now that we created the Gitlab project to host our policies, you can go ahead an copy the /docker folder from my repository. Along with the folder you can copy the .gitlab-ci.yml which provides you with the pipeline to create the OPA bundle and push it to Harbor.

The pipeline uses several variables described below:

Variable name	Purpose	Default value
BUNDLE	the name of the bundle which will be used as a Harbor artefact name	bundle
REPO	the folder name to build	./docker
TAG	the tag to set for the bundle when pushed to the repository	0.1
IMG_REPO	the repository URL domain	harbor.httpsec.eu
REPO_USER	the robot account to be used to login to Harbor	no value
REPO_PASS	the robot account password	no value

Next we need to create the Harbor repository. I named mine docker-opa. If you want, I provided a quick curl call to create and setup the project - please change the env vars to your own.

export REPO=harbor.example.com
export AUTH=[BASIC_AUTH_TOKEN_FOR_REOBOT_ACCOUNT_HERE]

curl -X 'POST' \
  "https://${REPO}/api/v2.0/projects" \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H "authorization: Basic ${AUTH}" \
  -d '{
  "project_name": "docker-opa",
  "public": false,
  "metadata": {
    "enable_content_trust": "true",
    "enable_content_trust_cosign": "true"
  }
}'

Once the repository is created we need to create a Harbor robot account which we will use to login to Harbor from our Gitlab instance. You can set the variables REPO_USER and REPO_PASS as environment variables in the Gitlab project so that you don't have to enter them manually each time you run the pipeline.

Build the first bundle

Now that we created the two repositories we need to build our first OPA bundle. Go to your Gitlab project and select Build > Pipelines and click on Run pipeline. Fill in the variables or use the default values and select Run. Once the pipeline finishes you should see a new entry in the Harbor project similar to figure below.

NOTE: in the screenshot the name of the bundle is docker_auth because I set the Gitlab pipeline variable BUNDLE to the same name.

Configure Docker

The next steps are to install the Docker plugin and configure it to pull the policies from our Harbor instance.

Before we install the plugin we need to set the configuration file. The /etc/docker directory will be mounted as /opa in the container running the plugin, so let’s create a sub-directory for our configuration file there.

sudo mkdir -p /etc/docker/opa-config

Now copy or move the config.yaml file from my repository to the /etc/docker/opa-confg/ folder.

To install the plugin run the following command:

docker plugin install openpolicyagent/opa-docker-authz-v2:0.9 opa-args="-config-file /opa/opa-config/config.yaml"

To validate that our plugin has been installed correctly, run the following command:

docker plugin ls

If the everything works you should see an output similar to this:

ID             NAME                                      DESCRIPTION                                     ENABLED
d6cee85ae9aa   openpolicyagent/opa-docker-authz-v2:0.9   A policy-enabled authorization plugin for Do…   true

The last step is to configure Docker to use plugin. For this we need to edit the file, or create it if it doesn't exist, /etc/docker/daemon.json and add the following line:

"authorization-plugins": ["openpolicyagent/opa-docker-authz-v2:0.9"]

Run the following command to restart the Docker daemon:

sudo systemctl restart docker

To validate that everything is working run the following command:

docker image pull nginx:latest

And you should now receive an error similar to this:

$ docker image pull nginx:latest
Error response from daemon: authorization denied by plugin openpolicyagent/opa-docker-authz-v2:0.9: request rejected by administrative policy

Now your Docker instance is hardened.

Final thoughts

As we wrap up, hardening Docker environments by integrating Open Policy Agent (OPA) and Harbor represents a good starting step in securing containerised applications. Through this tutorial, we've seen how OPA's policy-as-code approach, combined with Harbor's robust image management capabilities, can create a more secure and manageable Docker ecosystem.

By implementing these tools, OPS and security teams can enforce consistent security policies and practices, reducing the risk of vulnerabilities and enhancing the overall security posture of their applications.