A KeyVault for the Power Platform

sandr0-p — Mon, 25 Nov 2024 19:00:00 +0000

My friend and Microsoft MVP David Wyatt recently asked me to provide him with an Azure Key Vault for his Power Apps. "Easy", I thought, but everyone who ever worked with Microsoft products knows that "easy" is a relative term.

We started by creating a standalone Key Vault. I added David and the Power Platform SPN with Secret Get/List permissions, and we gave it a go. It will not surprise you that it didn't work (otherwise I wouldn't write, right?!). The Key Vault Firewall rejected the traffic.
Fair, but thanks to our Company policies, we couldn't just allow public traffic. Which admittedly makes sense if you want to keep your secrets safe 🤷‍♂️

In the next step, we added a couple of Power Platform IP addresses to the Key Vault Firewall. Unfortunately, it had the same outcome. The firewall rejected the traffic. It was at this moment we knew this was getting out of hand. It became actual work.
As it turns out, we needed an entire Virtual Network with a Subnet and Network Security Group. If you ask me, this is too much work, but David insisted... and this is what it looks like:

As just mentioned, we need four resources. A Key Vault (kv), a Virtual Network (vnet), a Subnet (subnet) and a Network Security Group (nsg). To make matters worse, they have dependencies all over the place. If you are, like me, not a network specialist, this is a bit confusing. But here is what it looks like.

One of the resources without any dependencies is the nsg, which makes it a prime starting point.

resource nsg 'Microsoft.Network/networkSecurityGroups@2024-03-01' = {
  location: 'eastus2'
  name: 'nsg'
  properties: {
    securityRules: [
      {
        name: 'AllowPP'
        properties: {
          access: 'Allow'
          destinationAddressPrefix: 'VirtualNetwork'
          destinationPortRange: '*'
          direction: 'Inbound'
          priority: 100
          protocol: '*'
          sourceAddressPrefix: 'PowerPlatformInfra'
          sourcePortRange: '*'
        }
      }
    ]
  }
}

The main focus here is on the sourceAddressPrefix and sourceAddressPrefix. These indicate from where to where we want to allow traffic. Usually, we would enter a list of IP addresses here, but Microsoft was so kind to provide us with Virtual Network Service Tags, which we can use instead of IP addresses.

Next up, the vnet. This is the second resource without a dependency.

resource vnet 'Microsoft.Network/virtualNetworks@2024-03-01' = {
  name: 'vnet'
  location: 'eastus2'
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
  }
}

You can choose your addressPrefixes pretty much at random if this is an isolated network. If you intend to connect this network to another, make sure that you use a compatible IP range. The IP range in the example is a CIDR notation and means that we can use the 65,536 IP addresses between 10.0.0.0 and 10.0.255.255.

Let's continue with the subnet, which depends on the vnet and nsg which we have just defined.

resource vnet 'Microsoft.Network/virtualNetworks@2024-03-01' existing = {
  name: 'vnet'
}

resource nsg 'Microsoft.Network/networkSecurityGroups@2024-03-01' existing = {
  name: 'nsg'
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2024-03-01' = {
  name: 'default'
  parent: vnet
  properties: {
    addressPrefix: '10.0.1.0/24'
    networkSecurityGroup: {
      id: nsg.id
    }
    serviceEndpoints: [
      {
        service: 'Microsoft.KeyVault'
      }
    ]
  }
}

We use the existing keyword to access the vnet and nsg, which should already exist when the subnet is being deployed. The vnet is used as the parent and the nsg.id for the networkSecurityGroup. We must also decide which IPs available on the vnet should be assigned to this subnet. In the example, we assigned all IPs from 10.0.1.0 to 10.0.1.255. And very importantly, we need to make Microsoft.KeyVault available in the serviceEndpoints. Otherwise, the traffic will be blocked once again.

💡 To be safe, ensure your related resources use the same API version. In the above, we have three Microsoft.Network resources using API version 2024-03-01. More often than not, mixed versions will work, but sometimes you end up with bizarre behaviour. Using the same API version will increase the chance that everything works.

And last but not least, we define the resource that has kicked off this odyssey, the Key Vault.

resource vnet 'Microsoft.Network/virtualNetworks@2024-03-01' existing = {
  name: 'vnet'
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2024-03-01' existing = {
  name: 'default'
  parent: vnet
}

resource keyVault 'Microsoft.KeyVault/vaults@2023-02-01' = {
  name: 'kv'
  location: 'eastus2'
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    networkAcls: {
      bypass: 'AzureServices'
      defaultAction: 'Deny'
      virtualNetworkRules: [
        {
          id: subnet.id
        }
      ]
    }
    enabledForTemplateDeployment: true
    accessPolicies: [
      {
        tenantId: subscription().tenantId
        objectId: '00000000-0000-0000-0000-000000000000'
        permissions: {
          certificates: []
          keys: []
          secrets: [
            'get'
            'list'
          ]
          storage: []
        }
      }
    ]
  }
}

Once again, we use the existing keyword to access the already deployed vent and subnet. The points of interest here are the networkAcls and accessPolicies.
The defaultAction: Deny property of networkAcls prohibits all traffic by default. With bypass: AzureServices we overrides= the defaultAction and allow Azure-hosted services, such as a Web App, direct access to the kv. The same is true for all IPs and rules defined in the subnet andnsg, which we assign to thevirtualNetworkRules. InaccessPolicieswe which identities (Users, Applications, Resources can perform which actions against Key Vault items. In the example, we grant get/list access to the given objectId. Where list allows to fetch a list of the name of all stored secrets and get allows to read the secret value.

To wrap things up, let's write the pipeline we can run in Azure DevOps.

trigger:
  - none

parameters:
  - name: TargetEnvironment
    type: string
    values: 
      - 'your-azure-resource-group'
  - name: kv01
    displayName: "Deploy Key Vault"
    type: boolean
    default: false
  - name: vnet01
    displayName: "Deploy Virtual Network"
    type: boolean
    default: false
  - name: nsg01
    displayName: "Deploy Network Security Group"
    type: boolean
    default: false
  - name: subnet01
    displayName: "Deploy Subnet"
    type: boolean
    default: false

variables:
  - name: serviceConnection
    value: "your-azure-service-connection"


stages:
  - stage: 'Infrastructure'
    displayName: 'Infrastructure'
    pool:
      vmImage: ubuntu-latest
    # Deploy kv01
    - job: kv01
      displayName: 'Create Key Vault'
      condition: eq('${{ parameters.kv01 }}', true)
      dependsOn:
        - vnet01
        - subnet01
      steps:
        - task: AzureCLI@2
          inputs:
            azureSubscription: $(serviceConnection)
            scriptType: "bash"
            scriptLocation: "inlineScript"
            inlineScript: |
              az deployment group create \
              --resource-group ${{parameters.TargetEnvironment}} \
              --template-file  $(Build.SourcesDirectory)/KeyVault.bicep
    # Deploy vnet01
    - job: vnet01
      displayName: 'Create Virtual Network'
      condition: eq('${{ parameters.vnet01 }}', true)
      steps:
        - task: AzureCLI@2
          inputs:
            azureSubscription: $(serviceConnection)
            scriptType: "bash"
            scriptLocation: "inlineScript"
            inlineScript: |
              az deployment group create \
              --resource-group ${{parameters.TargetEnvironment}} \
              --template-file  $(Build.SourcesDirectory)/VirtualNetwork.bicep
    # Deploy nsg01
    - job: nsg01
      displayName: 'Create Network Security Group'
      condition: eq('${{ parameters.nsg01 }}', true)
      steps:
        - task: AzureCLI@2
          inputs:
            azureSubscription: $(serviceConnection)
            scriptType: "bash"
            scriptLocation: "inlineScript"
            inlineScript: |
              az deployment group create \
              --resource-group ${{parameters.TargetEnvironment}} \
              --template-file  $(Build.SourcesDirectory)/NetworkSecurityGroup.bicep
    # Deploy subnet01
    - job: subnet01
      displayName: 'Create Subnet'
      condition: eq('${{ parameters.subnet01 }}', true)
      dependsOn:
        - vnet01
        - nsg01
      steps:
        - task: AzureCLI@2
          inputs:
            azureSubscription: $(serviceConnection)
            scriptType: "bash"
            scriptLocation: "inlineScript"
            inlineScript: |
              az deployment group create \
              --resource-group ${{parameters.TargetEnvironment}} \
              --template-file  $(Build.SourcesDirectory)/Subnet.bicep

With trigger: -none, we indicate that we want to execute the pipeline manually and not, for example, as part of a PR or merge. The following block allows to select which resources should be deployed on a run and to which resource group.
For the deployment of the resources, we have four identical blocks, one for each resource. With condition: eq('${{ parameters.kv01 }}', true), we instruct Azure to execute the job only if we have selected it. Otherwise, skip it.
dependsOn: - vnet01 - subnet01 defines our dependicies. Azure will attempt to execute the jobs in a way that all dependencies are finished before the job runs.

So yeah, that was our attempt to "quickly" spin up a Key Vault for the Power Platform. I hope this helps when your friend asks you for help.

If you are interested in Microsoft PowerPlatform, I highly recommend to check out David's Blog and Power DevBox.

Resources

Code Reviews: Easing the pain

sandr0-p — Mon, 11 Nov 2024 23:58:58 +0000

Most developers have met them throughout their career: Code Reviews. They are a crucial tool in software development and can help to ensure quality, consistency and maintainability. Yet, for many developers, the thought of a code review can bring a sense of dread. Why is that?

While there is a plethora of reasons for code reviews being viewed so negatively, I want to focus on consistency and predictability. What do I mean by that?

A code review should have roughly the same outcome, independent of who performs the review and the person's mood.

In this article, I will attempt to show a path towards a more positive and efficient experience for everyone involved, turning code reviews into an opportunity for learning rather than just a necessary hurdle.

The first step towards better code reviews is a shared understanding of their purpose and what a code review should entail. Without this shared understanding, every developer will focus on what they find important; thus, every code review will look different. The agreement should be as detailed as possible, preferably with examples or methodologies. It should be written down and made available in a central place.
Here are some of the things that I think are worth looking at:

S.O.L.I.D Principles - Does the code adhere to the solid principles widely known to produce reusable code?
Clean Code Development - Does the code follow the principles of clean code development?
Pureness - Does the code use pure functions?
Documentation - Is the code documented? In code and the technical documentation (where applicable)?

The eager reader will have noticed that the S.O.L.I.D Principles are already included in Clean Code Development. I listed them separately as I find they build a solid foundation for programming in general. (Pun intended)

Every seasoned developer and reviewer will find that list a little short. I agree. It is short on purpose. Many other tasks performed in a code review can and should be automated away. Executing tests? Done in the CI/CD pipeline. Naming conventions? Done using linting.

Most modern IDEs support plugins, allowing you to extend the IDE functionality based on your team's needs. You should use this capability to perform as many validations during development as possible. Many of these tools can additionally be used in CI/CD pipelines. In this way, code quality can be validated without a review, and the reviewer can focus on the aspects that actually require intelligence. It also makes a code review predictable. A reviewer shouldn't find anything if neither the IDE nor the pipeline reports any violations.

Last but not least, peer reviews. I know even more time is spent on code reviews. But, if done correctly, these sessions allow developers to learn from each other, provided they are interested. Over time the teams code will become more and more similar, making it even easier to perform a review.

Code reviews may never be a developer’s favourite part of the job. Still, by building consistency, using automated tools wisely, and fostering a culture of constructive feedback, we can transform code reviews into a positive experience. When reviews are predictable and focused on the most impactful elements, they become less of a chore and more of a valuable learning opportunity. By investing time in peer reviews, teams can align their code styles and principles, making future reviews more seamless and efficient. With the right approach, code reviews can strengthen code quality and team cohesion—turning an often-dreaded task into a cornerstone of continuous improvement.

DEV Community: sandr0-p

A KeyVault for the Power Platform

Code Reviews: Easing the pain