Forem: Rafael Herik de Carvalho

Bringing Azure Infrastructure into Kubernetes: Why ASO v2 is a Game Changer for GitOps

Rafael Herik de Carvalho — Mon, 07 Apr 2025 16:54:21 +0000

Infrastructure as Code (IaC) isn’t just a best practice in modern cloud environments, it’s essential.

As systems scale, teams need automation, consistency, and strong security to avoid the pitfalls of manual provisioning. IaC makes your infrastructure repeatable, auditable, and self-service-friendly — all while speeding up delivery.

Traditionally, tools like Terraform, Bicep, and ARM templates have been the standard for managing Azure infrastructure. But what if you could provision and manage your cloud resources the same way you manage your applications — using Kubernetes, CRDs, and GitOps workflows?

That’s where Azure Service Operator v2 (ASO v2) comes in.

What is ASO v2?

Azure Service Operator v2 is the official, production-grade Kubernetes operator built by Microsoft for managing Azure resources using Kubernetes-native APIs.

It allows you to define and manage Azure services (e.g., SQL Databases, Cosmos DB, Storage Accounts, Key Vaults) as Kubernetes Custom Resources — fully integrated with GitOps pipelines using tools like Flux and ArgoCD.

Compared to the original ASO, version 2 brings:

A modular, per-service architecture, so you can install only what you need
Support for latest Azure API versions, mapped 1:1 to Azure's resource model
Better multi-tenancy support and flexible identity management
Improved controller reliability and reconciliation performance

Why This Matters in a GitOps World

GitOps has changed the way we ship and manage applications — but applying GitOps to infrastructure, especially stateful resources, is still challenging.

Take a database, for example. Provisioning one isn’t just about spinning up a container. You also need:

Data persistence
Backup and restore policies
Geo-replication
Access controls and secrets
Performance configuration

Most infrastructure tools treat this separately from the application layer. That can lead to siloed pipelines, manual work, and config drift.

ASO v2 brings infrastructure and app delivery together — in the same GitOps flow. You define resources declaratively, store them in Git, and Kubernetes takes care of syncing the desired state with Azure.

How ASO v2 Works

ASO v2 works by introducing Azure-specific Custom Resource Definitions (CRDs) into your Kubernetes cluster. For each supported Azure service, there’s a matching Kubernetes resource type. For example:

SqlServer and SqlDatabase for Azure SQL
StorageAccount for Azure Blob/File/Table storage
KeyVault, CosmosDB, PostgreSqlDatabase, etc.

Each of these resources is managed by a controller — a background process that:

Watches for changes to the custom resources
Validates desired state against current Azure state
Makes API calls to Azure to bring the resource into alignment

This means your Azure infrastructure becomes Kubernetes-native — you can kubectl apply a database, update it with a GitOps commit, and monitor it just like any other workload.

Perfect for Hybrid Environments

In real-world teams, hybrid environments are the norm: developers deploy applications, while platform teams manage infrastructure. ASO v2 helps bridge this gap by enabling:

Self-service provisioning: Developers can request their own databases or Key Vaults — with guardrails — using YAML.
Environment consistency: Staging, QA, and prod environments can be defined and reproduced identically.
Policy enforcement: Teams can apply RBAC, Azure AD identities, and resource quotas at the Kubernetes level.

You can even use different credentials per namespace, meaning each team or workload can authenticate with different Azure identities — perfect for multi-tenant clusters.

Example: Provisioning an Azure SQL Database

Here’s what an Azure SQL Database resource might look like using ASO v2:

apiVersion: azure.microsoft.com/v1api20211101
kind: SqlDatabase
metadata:
  name: my-database
spec:
  location: eastus
  owner:
    name: my-sql-server
  collation: SQL_Latin1_General_CP1_CI_AS
  maxSizeBytes: 5368709120  # 5 GB
  sku:
    name: S1
    tier: Standard
    capacity: 10

This lives alongside your app code and gets deployed via GitOps. Need to change the SKU or scale up storage? Just edit the file and commit.

What ASO Can’t (Yet) Do

ASO v2 is powerful, but it’s important to note a few things it doesn’t do — at least not yet:

You can’t create a database from a backup directly in the CRD (like point-in-time restore or copy from another DB). This still needs to be done using CLI or ARM.
Not all Azure services are supported yet (but the list is growing fast).
It’s not a full replacement for Terraform/Bicep — rather, it's a GitOps-friendly complement that excels in app-adjacent infrastructure.

Key Benefits for Teams

GitOps-native Azure infrastructure
Modular installation — only install the Azure services you need
Fine-grained identity control using Azure AD Workload Identity
Unified workflows for app + infra using Kubernetes-native tooling
Developer enablement with self-service infra provisioning

ASO v2 and Crossplane: Competing or Complementary?

As more teams adopt GitOps and Kubernetes-native infrastructure workflows, it's natural to compare tools like ASO v2 and Crossplane — both aim to bring cloud resource management into the Kubernetes world.

While they share similar goals and some overlapping features, this post is focused on ASO v2. I won’t dive into a full comparison here — but stay tuned! I’ll be sharing a dedicated post soon that explores Crossplane in more depth, along with a detailed side-by-side breakdown.

For now, just know that these tools aren’t necessarily competing — they can be complementary, depending on your cloud strategy and team structure.

Final thoughts

GitOps and Kubernetes have changed how we manage modern applications. With Azure Service Operator v2, you can bring those same practices to your infrastructure — making Azure resources part of your Kubernetes-native, declarative workflows.

Whether it’s provisioning databases, Key Vaults, or storage accounts, ASO v2 helps you build secure, consistent, and repeatable environments — all from YAML.

That said, tools like Terraform and Bicep aren’t going away. A hybrid approach is a good option:

Platform teams use Terraform/Bicep to set up baseline infrastructure.
Developers use ASO v2 / Crossplane to provision and manage app-specific resources, backed by GitOps.

This way, you get the stability of traditional IaC and the flexibility of Kubernetes-native workflows.

Microsoft is continuing to invest in ASO, and it’s already proving to be a powerful tool for hybrid and cloud-native teams alike.

Kubernetes Operators - The k8s orchestration "service"

Rafael Herik de Carvalho — Mon, 07 Apr 2025 15:28:10 +0000

If you're familiar with Kubernetes, you've probably heard of, used, or at least come across the term "Operators." In simple terms, an Operator is a software extension to Kubernetes that helps manage applications and their components by automating complex tasks.

The official Kubernetes definition is:

"Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components. Operators follow Kubernetes principles, notably the control loop". kubernetes.io

What Exactly Are Kubernetes Operators?

Think of Operators as specialized tools designed to simplify the management of your software. Instead of manually handling every individual part of an application—like servers, storage, or networking—an Operator allows us to treat the entire application as one cohesive unit. This way, we can focus only on the parts that need adjusting, without worrying about the technical details.

Automation Made Easy

Operators are not only powerful in managing applications, but they also automate everyday tasks. For instance, they handle installation, configuration, updates, backups, and even recovery—all without requiring manual intervention. Because Operators are built into the Kubernetes system, they integrate smoothly with it, allowing everything to work seamlessly together.
How Do Kubernetes Operators Work?

At a high level, Operators function as controllers that make it easier to package, deploy, and manage software on Kubernetes. They use Custom Resource Definitions (CRDs) to specify how an application should behave. These definitions allow the Operator to continuously monitor and adjust the application, ensuring that it always matches the desired state.

For example, if an application needs more resources or a restart, the Operator can take care of it automatically, skipping any human intervention.

Why Are Operators So Powerful?

In essence, Operators take on the heavy lifting of managing complex applications. By using Kubernetes APIs and principles, Operators can automate tasks that would otherwise require manual configuration or intervention. This makes them an invaluable tool for any Kubernetes-based infrastructure, offering streamlined management and reducing the need for constant oversight.

In Conclusion

Kubernetes Operators are "set-it-and-forget-it" tools that automate and manage complex tasks behind the scenes, ensuring your applications stay healthy, up to date, and running smoothly. They bring immense power, particularly in complex or large-scale environments, by eliminating manual intervention and streamlining processes. With Operators, you can save time, optimize resources, and maintain consistency and reliability across your Kubernetes cluster, making them an essential tool for modern application management.

References:

Azure Verified Modules: Consolidated Standards for a Good IaC

Rafael Herik de Carvalho — Wed, 04 Sep 2024 07:30:42 +0000

Microsoft introduced the AVM(Azure Verified Modules) as part of an effort to help internal and external parties build well-designed and reliable infrastructure using infrastructure as code.

"Azure Verified Modules enable and accelerate consistent solution development and delivery of cloud-native or migrated applications and their supporting infrastructure by codifying Microsoft guidance (WAF - Well-Architected Framework), with best practice configurations." - Azure Verified Modules

With AVM, Microsoft aims to provide a single definition of a suitable IaC module. This initiative is not about Bicep but multiple IaC languages, following the principles of the well-architected framework.

These clearly defined statements will help organizations drive Cloud Adoption and mature their cloud infrastructure according to best practices.

Why AVM?

The community has been throwing a bunch of Infrastructure as Code (IaC) modules at the wall, but nothing's really stuck as the go-to, trustworthy source. We've got modules in different languages, styles, and support levels scattered all over the place.

This new effort is about creating a unified strategy for IaC modules that customers and partners can rely on. The goal is to build a consistent, supported, and available library of modules in whatever language you prefer.

This should help speed up projects like Landing Zone Accelerators and give users solid building blocks, no matter where they are in their IaC journey. Plus, it addresses the big headache of support - customers need to know Microsoft's got their back when using these modules, especially in enterprise settings.

Basically, they're trying to clean up the chaos and give people something they can trust and build on without worrying about it falling apart when it matters most.

The proposed design

On the image above you can see the AVM design, it's supported by Azure Resource Manager, then all Domain Specific Languages such Bicep and Terraform implements the resource management.

AVM provides three types of Modules: Resource Modules, Patern Modules and Utility Modules. See more about Modules Classification here

Resource Modules

Resource modules are designed to manage specific Azure Resources like Virtual Machines, Virtual Networks, and Azure Kubernetes Services(AKS).

Pattern Modules

Pattern modules are designed to implement specific architectural patterns, often involving multiple resources working together. A prime example is a production-ready Azure Kubernetes Service (AKS) deployment. Setting up AKS properly involves more than just provisioning the AKS resource itself - it requires configuring network-related resources, setting up a private container registry for enhanced security, and applying various other specific configurations. Pattern modules simplify this process by encapsulating all these components and best practices into a single, easy-to-use module. This approach significantly reduces complexity and helps users deploy comprehensive, well-architected solutions with less effort and reduced risk of misconfiguration. See this module example for AKS production ready Terraform module.

Utility Modules

Utility modules implement functions and routines that can be used by Resouce and Pattern modules, but they MUST NOT deploy any Azure Resource; they are only utilities.

If you use IaC to provision Azure infrastructure, the AVM Overview must be read.

Available Modules

For now (Sep 2024), only Bicep and Terraform are supported, AVM uses Bicep Registry and Terraform Registry to share the modules:

Framework	Module Type	Published	Proposed
Bicep	Resource	135	14
	Pattern	11	31
	Utility	0	1
Terraform	Resource	51	86
	Pattern	9	22
	Utility	0	1

Note: Data as of September 2024

Contributing

If you want to contribute, you can even propose a new module or develop or contribute to an existing module:

Bicep

Terraform

Update: I've missed adding the observation that only Microsoft full-time employees can be module owners for now.

Final Thoughts

For large cloud environments, the AVM still needs to deliver its full potential; it needs some maturing and the implementation of new modules. However, as it is a good standard, you can get started with the modules already available and contribute to the initiative.

References

In Light of Terraform Licensing Changes, OpenTofu Offers a Free, Open-Source Path

Rafael Herik de Carvalho — Tue, 03 Sep 2024 09:12:03 +0000

As of April 2024, HashiCorp has become part of IBM. This acquisition has sparked concerns about the future of Terraform, mainly due to HashiCorp’s controversial license change to a BSL License in August 2023.

"BSL 1.1 is a source-available license that allows copying, modification, redistribution, non-commercial use, and commercial use under specific conditions."

This scenario exemplifies the challenge of monetising open-source software. Large open-source projects are typically sustained by big tech companies, which provide funding and engineering resources. This support allows projects to maintain a dedicated workforce to keep the development engine running smoothly.

Concerns Surrounding the Acquisition

Two main concerns have been raised about IBM’s acquisition of HashiCorp:

IBM's Track Record: IBM has a history of unsuccessful acquisitions of promising companies, which raises doubts about the future success of Terraform under its new ownership.
Conflict of Interest: IBM’s cloud offerings present a potential conflict of interest. Terraform is widely used to manage infrastructure on major cloud platforms like AWS, Azure, and GCP. This could reduce effort or interest in maintaining integrations with competing cloud providers.

Considering Alternatives to Terraform

If you are currently using Terraform and are not inclined to acquire licenses in the future, consider exploring alternatives. The most straightforward option is OpenTofu.

Following the license change, a private fork of Terraform was created, leading to the release of OpenTofu. You can read the official announcement here.

Terraform vs OpenTofu: What Are the Differences?

Apart from licensing, Terraform and OpenTofu are fundamentally the same. Since the fork is relatively recent, they function very similarly. Here's an overview:

Installing OpenTofu

For Linux and macOS, you can install OpenTofu via Homebrew:


brew update
brew install opentofu

Usage
After installation, using OpenTofu is almost identical to using Terraform:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "4.1.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example-rg" {
    name = "example-rg"
    location = "West Europe"  
}

With this infrastructure configured, initialize OpenTofu:


tofu init

Initializing the backend...

Initializing provider plugins...

OpenTofu has been successfully initialized!

You may now begin working with OpenTofu. Try running "tofu plan" to see any changes that are required for your infrastructure. All OpenTofu commands should now work.

If you ever set or change modules or backend configuration for OpenTofu, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.

From now on, you only need to replace the terraform command with tofu to run your IaC.

For more details on migrating from Terraform to OpenTofu, visit the migration guide.

Final Thoughts

I'm launching a new GitHub repo to explore examples using OpenTofu further. Please follow the repo here.

This post aims to introduce OpenTofu as a viable alternative and encourage community engagement in using and improving this important tool in the modern cloud development landscape.

The Case for Terraform Modules: Why Not Just Use Providers Directly?

Rafael Herik de Carvalho — Tue, 20 Aug 2024 08:58:54 +0000

When it comes to large-scale Infrastructure as Code (IaC) for complex cloud environments, managing the sheer number of resources is not the only challenge. The real differentiator lies in provisioning infrastructure according to strict governance, security, and availability requirements without introducing unnecessary complexity or increasing the risk of human error during the design and implementation process.

In large-scale environments, we encounter a set of pre-established definitions that encompass everything from corporate standards to security practices and cost management. These guidelines, though essential, often make the process of writing infrastructure code more challenging, demanding speed, efficiency, and compliance.

Developing modules in Terraform is a key strategy to manage this complexity. Modules not only help create consistent patterns but also enable engineers to describe and provision the required infrastructure without worrying about all the compliance and security details. Rather than limiting creativity and agility, modules provide a solid foundation that ensures best practices are followed.

Security awareness is crucial in cloud development, but it should not be an obstacle. On the contrary, it should be a core part of the organizational culture, naturally integrated into the design and implementation process of cloud solutions.

To address the main question, let's start with the basics: What is Terraform?

"Terraform is an infrastructure as code tool developed by HashiCorp that allows you to define both cloud and on-premises resources in human-readable configuration files that can be versioned, reused, and shared. You can then use a consistent workflow to provision and manage your entire infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features." — HashiCorp.

What is a provider in Terraform?

A provider in Terraform is a plugin that allows Terraform to interact with various platforms, services, or APIs. Providers are a crucial component in Terraform's architecture, enabling the tool to manage and configure resources across different systems.

Key Points about Terraform Providers:

Platform Interaction: Providers are responsible for translating Terraform's declarative code into API calls that integrate with an infrastructure platform. This platform can be a cloud provider like Azure or AWS, a Software as a Service (SaaS) like GitHub or Datadog, or even on-premises systems.
Resource Management: Each provider defines a set of resources it can manage. These resources are declared in Terraform configuration files.
State Management: Providers work with Terraform to manage the state of the infrastructure, allowing Terraform to understand what changes are necessary during a terraform apply.
Installation and Versioning: Providers are distributed as plugins, and Terraform automatically downloads the required providers when you initialize your configuration (terraform init). Each provider has its own versioning, and you can specify the version you need in your configuration.
Extensibility: If a platform or service doesn't have an official provider, you can develop a custom provider using the Terraform SDK.

Example:

If you want to manage resources in AWS using Terraform, you need to use the AWS provider. In your configuration file, you would declare your provider like this:

provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

In this example:

The aws provider allows Terraform to integrate with AWS.
The aws_instance resource is defined by the AWS provider and represents an EC2 instance in AWS.

Providers are essential to Terraform's operation because they abstract the complexity of interacting with different platforms, making infrastructure as code easily manageable across multiple environments.

What is a module in Terraform?

A module in Terraform is a container for one or more resources that are used together. It is a fundamental unit of code organization in Terraform, serving to group related resources and make configurations more modular, reusable, and easier to manage.

Essentially, a Terraform module is a set of .tf files in a directory. Every configuration file (.tf) in a directory is implicitly considered part of the module. When you start a project and create the main.tf, output.tf, and variables.tf files, this set of files in the root directory is called the "root module."

You can explicitly use modules by placing related configurations in a directory and calling the module from your configuration file (.tf) in the root module or any other module.

Reusability:

Modules allow you to encapsulate patterns in your resource declarations and reuse them in multiple projects or environments. This reduces code duplication and makes your configuration more DRY (Don't Repeat Yourself).

For example, you can create a module to handle common tasks like provisioning an EC2 instance, configuring a network, or provisioning a Kubernetes cluster. Once the module is created, it can be used in different configurations by simply referencing it.

Modules typically accept inputs (variables) and produce outputs. This allows you to customize the module's behavior based on your needs and pass information from one module to other parts of your Terraform configuration.

How to use a module?

module "ec2_instance" { 
    source = "./modules/ec2-instance" 
    instance_type = "t2.micro" 
    ami_id = "ami-123456" 
    vpc_id = "vpc-123456" 
}

In this example, the ec2_instance module is referenced from a directory called ./modules/ec2-instance. Variables like instance_type, ami_id, and vpc_id are passed to the module.

Modules can be referenced from various sources:

Locally: source = "./modules/my-module"
Terraform Registry: source = "terraform-aws-modules/vpc/aws"
Git Repositories: source = "git::https://github.com/user/repo.git//path/to/module"

Terraform Module Registry

The Terraform Module Registry is a public repository where you can find and share modules created by the community. It offers various commonly used modules that can save significant development time when provisioning infrastructure.

What are the advantages of using Terraform modules?

There are several advantages to using Terraform modules. The ability to reuse code and standardize it are key factors driving teams to adopt Terraform modules.

Example without a module:

Here’s what the code to create a virtual machine in Azure would look like:

# main.tf

terraform {
    required_providers {
        azurerm = {
            source  = "hashicorp/azurerm"
            version = "3.116.0"
        }
    }
}

provider "azurerm" {
    features {}
}

resource "azurerm_resource_group" "rg" {
    name     = "myresourcegroup"
    location = "West Europe"
}

resource "azurerm_virtual_network" "vnet" {
    name                = "myvnet"
    resource_group_name = azurerm_resource_group.rg.name
    location            = azurerm_resource_group.rg.location
    address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "subnet" {
    name                 = "mysubnet"
    resource_group_name  = azurerm_resource_group.rg.name
    virtual_network_name = azurerm_virtual_network.vnet.name
    address_prefixes     = ["10.1.0.0/24"]
}

resource "azurerm_network_interface" "nic" {
    name                = "myvmnic"
    location            = azurerm_resource_group.rg.location
    resource_group_name = azurerm_resource_group.rg.name
    ip_configuration {
        name                          = "myvmnicconfig"
        private_ip_address_allocation = "Dynamic"
    }
}

resource "azurerm_virtual_machine" "vm" {
    name                  = "myvm"
    location              = azurerm_resource_group.rg.location
    resource_group_name   = azurerm_resource_group.rg.name
    network_interface_ids = [azurerm_network_interface.nic.id]
    vm_size               = "Standard_DS1_v2"

    os_profile_linux_config {
        disable_password_authentication = false
    }

    os_profile {
        computer_name  = "hostname"
        admin_username = "testadmin"
        admin_password = "Password1234!"
    }

    storage_image_reference {
        publisher = "Canonical"
        offer     = "0001-com-ubuntu-server-jammy"
        sku       = "22_04-lts"
        version   = "latest"
    }

    storage_os_disk {
        name              = "myosdisk"
        caching           = "ReadWrite"
        create_option     = "FromImage"
        managed_disk_type = "Standard_LRS"
    }
}

In this example, to create a virtual machine, you also need to create a virtual network, a subnet, a network interface, and a resource group. This adds some complexity due to the need to manage resources related to the virtual machine, which could be managed separately.

Example with the use of a module:

Now see how using a module can simplify the code:

# main.tf

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "East US"
}

module "network" {
  source              = "./network/vnet"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  vnets = {
    vnet1 = {
      name          = "vnet1"
      address_space = ["10.0.0.0/16"]
      subnets       = {


        subnet1 = {
          name            = "subnet1"
          address_prefixes = ["10.0.1.0/24"]
        }
      }
    }
  }
}

module "nic" {
  source              = "./network/nic"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  nics = {
    nicvm1 = {
      name      = "nicvm1"
      subnet_id = module.network.vnet_ids["vnet1"].subnets["subnet1"]
    }
  }
}

module "compute" {
  source              = "./compute/vm"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  vms = {
    vm1 = {
      name            = "vm1"
      size            = "Standard_B1s"
      admin_username  = "adminuser"
      admin_password  = "P@ssw0rd1234!"
      nic_name        = "nicvm1"
      image_publisher = "Canonical"
      image_offer     = "UbuntuServer"
      image_sku       = "18.04-LTS"
      image_version   = "latest"
    }
  }
}

In this example, three modules were used, reducing the complexity of creating one or more virtual machines.

Another important factor is abstraction and encapsulation. By developing a module, you can simplify resource management and design infrastructure that is more user-friendly for those who will consume these modules.

Imagine that your company decides that only Ubuntu version 22.04 will be available for creating virtual machines. You can set this as a default value in the module and omit it from the configuration. Another important aspect is security: for example, you could enforce that Linux virtual machines are only created with SSH key authentication, disabling password authentication.

From a governance perspective, you can establish naming standards and tags that are transparent to the user but ensure your infrastructure remains compliant.

Modules are a great strategy, but using providers directly can be advantageous when the complexity is low and the number of resources doesn't justify the use of modules.

Modules make your infrastructure as code more secure, reusable, and reliable. They shouldn't be seen as a complicating factor; whenever you choose to use modules, ensure they are up to date with provider versions, test your modules, and ensure they are an aid to those who use them, not a burden.

See more on: https://github.com/rafaelherik/terraform-samples

Improving Cloud governance using an automated naming generation tool.

Rafael Herik de Carvalho — Wed, 14 Aug 2024 14:13:04 +0000

Managing cloud assets efficiently is crucial for governance, operational management, and accounting. One of the key challenges is ensuring consistent and meaningful naming of resources, which becomes increasingly complex as your infrastructure grows. Without a standardized naming convention, locating and managing resources can be time-consuming and error-prone, leading to inefficiencies and increased costs.

This article introduces an automated approach to generating resource names using a Terraform provider. This solution simplifies the naming process, ensuring consistency and compliance across your cloud environment. Implementing this automated naming convention lets you quickly locate and manage resources, improve governance, and streamline operational workflows.

Additionally, this approach helps associate cloud usage costs with business teams through chargeback and showback mechanisms. With well-defined naming and metadata tagging conventions, you can more accurately track and allocate expenses, making it easier to manage budgets and optimize resource utilization.

Implementing an automated resource naming solution with Terraform not only saves time and reduces human error but also enhances your overall cloud management strategy, providing clear benefits in governance, operational efficiency, and cost control.

AzureNamingTool

AzureNamingTool was created to help administrators define and manage their naming conventions while providing users with a simple interface for generating compliant names. The tool was developed using a naming pattern based on Microsoft's best practices.

This tool is extensible, and you can apply new components to the name generation and improve the policies used to generate names.

It's an open-source tool, and you can extend it to fit your needs, add extra functionalities, and customize its content. This flexibility puts you in control, and your heart makes the tool adaptable to your unique requirements.

Why Use a Terraform Provider?

Benefits of a Declarative API

Terraform's declarative API offers significant advantages for managing resource naming conventions:

Simplicity and Clarity: By defining the desired state of resource names, you can ensure consistency and avoid naming conflicts. Terraform configurations are straightforward, making it easy to understand and manage the naming conventions.
Automation: A declarative approach allows for the automation of resource naming, reducing the need for manual intervention and minimizing human error. This automation ensures that all resources follow the defined naming standards automatically.
Scalability: As your infrastructure grows, maintaining a consistent naming convention manually becomes increasingly challenging. Terraform's declarative model scales seamlessly, enabling you to manage large and complex environments with ease.

State Management for Naming Convention

Terraform's state management is a powerful feature that tracks the current state of your infrastructure. This capability is particularly beneficial for enforcing naming conventions:

Consistency: Terraform maintains a state file that records the names of all resources, ensuring that changes are applied consistently across your environment. This prevents discrepancies and maintains uniformity in resource naming.
Version Control: State management allows for versioning, making it possible to track changes to naming conventions over time. This historical insight helps in auditing and compliance, providing a clear record of how resource names have evolved.
Conflict Resolution: Terraform's state management helps in detecting and resolving naming conflicts before they occur. By keeping track of the existing resource names, Terraform can prevent duplicate names and ensure that new resources adhere to the naming standards.

Setup the environment

To make the Azure Naming Tool work, you must deploy and configure it. Then, you can start using the Terraform provider.

You must consider the compatibility matrix related to which provider version you can use to communicate with your Azure Naming Tool Api.

Azure Naming Tool

AzureNamingTool offers multiple installations modes, the easiest one is running it in a Container, but you can also deploy it to an App Service: More details here

To use the Terraform provider, you must choose the best installation mode and generate the APIKEY that the provider will use to generate names.

The Terraform provider

I've created a new provider to provide the interface to request names to AzureNamingTool.

The provider's v1.0.0 is quite simple. It cannot manage all the entities, only the resource names.

To see more: Documentation.

How to configure the provider


  terraform {
   required_providers {
     aznamingtool = {
        source = "registry.terrafrom.io/rafaelherik/aznamingtool"
        version = "1.0.0-beta"
   }
 }

provider "aznamingtool" {
  api_key = "YOUR_API_KEY"
  base_url = "http://AZURE_NAMING_TOOL_BASE_URL"
  admin_password = "YOUR_ADMIN_PASSWORD" 
}

How to create a new Azure Resource using a name provided by the naming tool

variable "project_configuration" {
  type = map(string)
  default = {
    resource_environment = "dev"
    resource_location = "euw"
    resource_proj_app_svc = "tnp"
  } 
}
resource "aznamingtool_resource_name" "aznt-rg" {  
  components = merge(var.project_configuration, {
    resource_type= "rg"    
    resource_instance = "1"
  })
}

Using this approach, you can easily configure your projects to reuse properties and automate the resource naming generation. To use the name generated from the aznamingtool_resource_name:



resource "azurerm_resource_group" "az-rg" {
  name     = aznamingtool_resource_name.aznt-rg.resource_name
  location = "West Europe"
}

Your plan result must have similar values:

# aznamingtool_resource_name.aznt-rg will be created
  + resource "aznamingtool_resource_name" "aznt-rg" {
      + components         = {
          + "resource_environment"  = "dev"
          + "resource_instance"     = "1"
          + "resource_location"     = "euw"
          + "resource_proj_app_svc" = "tnp"
          + "resource_type"         = "rg"
        }
      + created_on         = (known after apply)
      + id                 = (known after apply)
      + resource_name      = (known after apply)
      + resource_type_name = (known after apply)
    }

 #azurerm_resource_group.az-rg will be created
 + resource "azurerm_resource_group" "az-rg" {
      + id       = (known after apply)
      + location = "westeurope"
      + name     = (known after apply)
    }

This is a simple example, but both tools are very extensible, and you can configure them to fit your infrastructure requirements. Managing resource names and metadata using tags can help you improve your governance and manage large-scale cloud environments.

Give a detailed look to both documentation to get know more each one of these tools AzureNaminTool aznamintool terraform provider

Using TruffleHog and pre-commit hook to prevent secret exposure

Rafael Herik de Carvalho — Thu, 25 Jul 2024 13:20:04 +0000

In today's landscape of modern software development and distributed teams, Git has become an essential tool for source control. However, a common and recurring issue I've encountered is the inadvertent pushing of secrets to remote repositories. This often necessitates the tedious process of rebasing branches to remove those commits and safeguard credentials from being exposed or stored in the source code.

What is TruffleHog??

"TruffleHog™ is a secrets scanning tool that digs deep into your
code repositories to find secrets, passwords, and sensitive keys." Read more

TruffleHog is easy to install and use. If you are interested in more features, you can also look at the Enterprise version, but for now, the focus will be on the open-source version to work with git hooks.

Hands on

Initializing a Git Repo (Or use your current repo)

$ mkdir tutorial
$ cd tutorial
$ git init

Adding the code

Here I'm adding a new simple python API that to List Cars from a MySQL database:

import os
import mysql.connector
from fastapi import FastAPI

app = FastAPI()

def _get_db_connection():
    return mysql.connector.connect(
        host="localhost",
        user="root",
        database="CarDatabase",
        password=os.environ.get("MYSQL_ROOT_PASSWORD"))


@app.get("/")
def read_root():
    return { "message": "Hello World!"}


@app.get("/cars")
def read_cars():
    conn = _get_db_connection()
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM Cars")
    cars = cursor.fetchall()
    cursor.close()
    conn.close()
    return cars

The code is working, and I'm ready to commit it to my repository.

Install TruffleHog

$ brew install trufflehog

Here for Linux and Windows users

Scanning the main.py file

$ trufflehog filesystem ./src/main.py

The result:

2024-07-25T12:06:02+02:00       info-0  trufflehog      running source  {"source_manager_worker_id": "f1VKj", "with_units": true}
2024-07-25T12:06:02+02:00       info-0  trufflehog      finished scanning       {"chunks": 1, "bytes": 531, "verified_secrets": 0, "unverified_secrets": 0, "scan_duration": "3.183166ms", "trufflehog_version": "3.80.1"}

No secrets were found.

Configuring a Git Hook for pre-commit

I'm using pre-commit, follow the link to get installation instructions.

The pre-commit-config.yaml:


repos:
  - repo: local
    hooks:
      - id: trufflehog
        name: TruffleHog
        description: Detect secrets in your data.
        entry: bash -c 'trufflehog git file://. --since-commit HEAD --no-verification --fail'
        language: system
        stages: ["commit", "push"]

After creating the pre-commit-config.yaml, let's install the hook:

$ pre-commit install
pre-commit installed at .git/hooks/pre-commit

Now the repo is ready.

Testing the hook

I will add a hard-coded secret to test the hook:

@app.get("/test")
def read_root():
    secret = "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"
    return { "message": "Hello World!"}

After adding this piece of code, I need to try to commit:

$ git add .
$ git commit -m "Try to add a hard-coded secret"

TruffleHog...............................................................Failed
- hook id: trufflehog
- exit code: 183

🐷🔑🐷  TruffleHog. Unearth your secrets. 🐷🔑🐷

2024-07-25T15:07:13+02:00       info-0  trufflehog      running source  {"source_manager_worker_id": "gWFQC", "with_units": true}
2024-07-25T15:07:13+02:00       info-0  trufflehog      scanning repo   {"source_manager_worker_id": "gWFQC", "unit": ".", "unit_kind": "dir", "repo": "https://github.com/rafaelherik/demo-trufflehog.git", "base": "7e7de59764df7420fc94897219c7dc55bf33a32e"}
Found unverified result 🐷🔑❓
Detector Type: Github
Decoder Type: PLAIN
Raw result: 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
Rotation_guide: https://howtorotate.com/docs/tutorials/github/
Version: 2
Commit: Staged
File: src/main.py
Line: 30
Repository: https://github.com/rafaelherik/demo-trufflehog.git
Timestamp: 0001-01-01 00:00:00 +0000

2024-07-25T15:07:13+02:00       info-0  trufflehog      finished scanning       {"chunks": 2, "bytes": 212, "verified_secrets": 0, "unverified_secrets": 1, "scan_duration": "20.145917ms", "trufflehog_version": "3.80.1"}

Understanding the result:

Found unverified result
Detector Type: Github
Decoder Type: PLAIN
Raw result: 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
Rotation_guide: https://howtorotate.com/docs/tutorials/github/
Version: 2
Commit: Staged
File: src/main.py
Line: 30
Repository: https://github.com/rafaelherik/demo-trufflehog.git

It says the Detector Type is GitHub, and it found a plain text secret in line 30 on src/main.py.

Safeguarding sensitive information in code repositories is critical to modern software development. TruffleHog offers a robust solution for detecting and preventing secrets from being inadvertently pushed to remote repositories.

By integrating TruffleHog with git hooks, developers can automate scanning for sensitive information before committing code, thus enhancing the security of their projects.

As demonstrated, setting up TruffleHog is straightforward, and its ability to identify hard-coded secrets can significantly mitigate the risk of credential exposure.

By incorporating such tools into the development workflow, teams can ensure a higher security level and maintain best source control management practices.

Find this code on GitHub.

Thank you for reading this post!

I appreciate your interest and hope you found the information useful. Your support and engagement are greatly valued. If you have any questions or feedback, please feel free to leave a comment. Happy coding!