DEV Community: Nicholas Drone

Automated Service Principal Password Rotation

Nicholas Drone — Thu, 04 Nov 2021 19:53:26 +0000

Assumptions

Knowledge of Terraform
Knowledge of using Terraform with Azure
Knowledge of GitHub Actions
Knowledge of Bash Scripting

Setup

This code block holds all the Azure resources built out by Terraform. The resource group and key vault are not required. It's only to show the storage of the service principal password and to show that when a terraform apply -replace is done that whatever is consuming the output of that resource is also updated. After the resource group and key vault are two service principals examples for this example.

terraform {
  backend "azurerm" {
    subscription_id      = "xxx-xxx-xxx-xxx"
    resource_group_name  = "tfstate"
    storage_account_name = "dronetfstate"
    container_name       = "tfstate"
    key                  = "sp_rotate.tfstate"
  }
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.83.0"
    }
    azuread = {
      source  = "hashicorp/azuread"
      version = "2.8.0"
    }
  }
}

provider "azurerm" {
  features {}
}

provider "azuread" {
}

resource "azurerm_resource_group" "example" {
  name     = "example"
  location = "Eastus2"
}

data "azurerm_client_config" "current" {}

resource "azurerm_key_vault" "example" {
  name                        = "droneexamplekeyvault"
  location                    = azurerm_resource_group.example.location
  resource_group_name         = azurerm_resource_group.example.name
  enabled_for_disk_encryption = true
  tenant_id                   = data.azurerm_client_config.current.tenant_id
  soft_delete_retention_days  = 7
  purge_protection_enabled    = false

  sku_name = "standard"

  access_policy {
    tenant_id = data.azurerm_client_config.current.tenant_id
    object_id = data.azurerm_client_config.current.object_id

    secret_permissions = [
      "Get",
      "List",
      "Set"
    ]
  }
}

data "azuread_client_config" "current" {}

resource "azuread_application" "example1" {
  display_name = "example1"
  owners       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal" "example1" {
  application_id               = azuread_application.example1.application_id
  app_role_assignment_required = false
  owners                       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal_password" "example1" {
  service_principal_id = azuread_service_principal.example1.object_id
}

resource "azurerm_key_vault_secret" "example1" {
  name         = "example1"
  value        = azuread_service_principal_password.example1.value
  key_vault_id = azurerm_key_vault.example.id
}

resource "azuread_application" "example2" {
  display_name = "example2"
  owners       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal" "example2" {
  application_id               = azuread_application.example2.application_id
  app_role_assignment_required = false
  owners                       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal_password" "example2" {
  service_principal_id = azuread_service_principal.example2.object_id
}

resource "azurerm_key_vault_secret" "example2" {
  name         = "example2"
  value        = azuread_service_principal_password.example2.value
  key_vault_id = azurerm_key_vault.example.id
}

When having service principals created its good security practice to rotate those passwords on a regular basis. If you are using GitHub Actions to already apply/execute your resource changes, then adding a workflow to then rotate the password by doing forcing a replacement of the password resource causes a new password to be generated.

Rotation Workflow

name: Rotate Secrets

on:
  schedule:
    - cron: '0 1 1 12/3 *' # run every 4 months.
  workflow_dispatch:

env:
  ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }}
  ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }}
  ARM_CLIENT_SECRET: ${{ secrets.ARM_CLIENT_SECRET }}
  ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }}
  TF_IN_AUTOMATION: true

jobs:
  replace:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 1.0.8
      - name: Terraform Init
        run: terraform init -input=false -no-color
        # Pull all the resources from the state file put them in a file for the next step
      - name: Terraform List State Resources
        run: terraform state list > stateList
        # We are going to loop through each line in the file of the resources
        # We only want to replace the service_principal_password resource, so we
        # need to check the start of each resource starts with the correct address.
      - name: Terraform Replace
        run: while read target; do if [[ "${target:0:34}" == "azuread_service_principal_password" ]]; then terraform apply -replace="$target" -input=false -no-color -auto-approve; fi; done < stateList

The last two steps are where the work is really done. First we want to create a temporary file to store all the resources within the state file. Echoing out the created file

data.azuread_client_config.current
data.azurerm_client_config.current
azuread_application.example1
azuread_application.example2
azuread_service_principal.example1
azuread_service_principal.example2
azuread_service_principal_password.example1
azuread_service_principal_password.example2
azurerm_key_vault.example
azurerm_key_vault_secret.example1
azurerm_key_vault_secret.example2
azurerm_resource_group.example

Then the following step we are iterating over all those resources and looking for the ones with the block label of azuread_service_principal_password. When we find those block labels we then want to pass the entire address to Terraform to force a replacement of those resources.

while read target; do 
    if [[ "${target:0:34}" == "azuread_service_principal_password" ]]; then 
        terraform apply -replace="$target" -input=false -no-color -auto-approve
    fi
done < stateList

Repositories are not just for Databases

Nicholas Drone — Thu, 14 Nov 2019 23:01:32 +0000

This blog post came out of the necessity of my own mistake. I have been working strictly with databases longer than I care to admit to. So in a project, we were making changes so that a specific application didn't have direct database access to a different application. Simple separation of concerns right, and microservice architecture. All that jazz right? So I brought in an HttpClient into the service layer, removing the repository. It seemed right at the time. Not sure why, several weeks later this pattern was copied by may other developers on the project, and just turn that project to no longer a clean looking platform of microservices. Then one day it hit me. The HTTP crud operations were doing the same thing as the database operations. And both should be treated as a datastore. Whether the data lives in a file of any structure, HTTP request, and or database. The access to that data should all live in the repository layer.

The code in this blog can be seen here. The git repository as of writing this post contains a library module with several sub-modules. The idea is that the libraries are then used by the applications that have yet to be written to further explain why repositories are for datastores not just databases.

Let's ignore the contact-core-test module for now. It contains a base test class. Each ContactRepository implementation test class can extend the base test class, and then only needs to write tests based on their implementation, but should pass all tests in the base class. I may turn that into a blog post of its own.

The contact-core module. This is a small simple module that contains the contact object. The repository interface for the contact object. The exception class for that object, and the validator class. The validator class just validates that the inputs specified in the methods of the interface adhere to the specifications of the javadocs of the interface.

package org.example;

/**
 * A simple ContactRepository. Any implementation of this interface should
 * leverage {@link ContactRepositoryValidator} to validate the overriding methods
 * arguments. The implementations Tests classes should extend ContactRepositoryTests
 *
 * @see contact-core-test module
 */
public interface ContactRepository {

  /**
   * Search for the contact with the existing <code>id</code>
   *
   * @param id of the contact to be searched for
   * @return <code>contact</code> maybe <code>null</code> if <code>contact</code>
   * with the <code>id</code> doesn't exist
   * @throws IllegalArgumentException if <code>id</code> is <code>null</code>
   * @throws ContactException         if an error has occurred
   */
  Contact findContact(Integer id) throws IllegalArgumentException, ContactException;

  /**
   * Searching for <code>contact</code> that exactly matches the parameters
   * passed into the method.
   *
   * @param firstName to be exactly searched with
   * @param lastName  to be exactly searched with
   * @return a collection of <code>contact</code> that match the parameters
   * @throws IllegalArgumentException if both parameters are <code>null</code>
   * @throws ContactException         if an error has occurred
   */
  Iterable<Contact> findContacts(String firstName, String lastName)
      throws IllegalArgumentException, ContactException;

  /**
   * Saves a new or updated contact information. If a <code>contact</code> is passed with the
   * <code>id</code> is <code>null</code>. The contact will be treated as a new contact, and
   * an <code>id</code> will be generated for it. If an <code>contact</code> has an existing
   * <code>id</code> the <code>contact</code> with be updated.
   *
   * @param contact to be saved or updated
   * @return saved <code>contact</code>
   * @throws IllegalArgumentException if a <code>contact</code> with an existing <code>id</code>
   *                                  can not be found.
   * @throws ContactException         if an error has occurred
   */
  Contact saveContact(Contact contact) throws IllegalArgumentException, ContactException;
}

The contact-file, contact-http, and contact-jdbc are all modules that implement the ContactRepository. So an application then can bring in the specific technology implementation and build an application based on the interface.

A hypothetical scenario

As a product team, we are spinning up a contact service. We've requested a database, but that won't be ready for weeks, and the boss wants it done by next week. Well, we still can write that service. The rest application is written to the ContactRepository interface. We bring in the contact-file dependency for the short term while we are waiting on our database to be complete. Once the database is complete we then can swap out the contact-file dependency for the jdbc one, only changing enough code to connect to the database. Then file contents are moved to the database after deployment. The boss shows off your work to another team that wants access to the contact info. Except they can't get past the firewall use the contact-jdbc implementation. Not that you wanted them to. So you create the HTTP implementation to your applications URL endpoints. Then they just need to write code to the interface you just did, but leverage HTTP to get the same data you got from the JDBC implementation. The good news is if your API change, you can control the HTTP implementation too, so you can save your customer the headache of handling the versioning, just give them the new HTTP jar with the versioned changes in it.