Client visit and self-signed root CA generation
One lasting effect following the pandemic, especially in the work- and business life, is a higher degree of remote work typically accepted, enabled through digital collaboration services and platforms. Still, the occasional physical presence meeting face-to-face can be beneficial though and something that’s not easy to replicate in digital realms only, and it was great spending a day together with the great and highly skilled team at the client premises in Älmhult, Sweden. In this part-time remote assignment, I’m assisting the team in enhancing and further and fully leverage the capabilities unlocked through the right and enhanced of cloud-native services and cloud-native computing in Azure, including setting new resource-, tagging- and naming conventions for project cost follow-up and analysis, bringing forth new storage solutions with emphasis on cost efficiency-, performance-, scale- and security, leveraging private endpoints Azure VPN Gateway configured with Entra ID work- and school account authentication and Azure Private DNS Resolvers- and Zones, for fully private end-to-end endpoint connections and resolution, Azure Kubernetes Services (AKS) maintenance- and migrations, ensuring subnet NSG integration with in- and outbound rules, network segmentation, enforcing VNet- and subnet integration and adopting a hub-spoke network topology approach, with VNet peerings to target application VNets, extending the use of identity-based authentication, as well as leveraging IaC for automating infrastructure deployments and enforcing structural-, naming-, hierarchical- and security defaults and configurations in a consistent manner etc., helping ensure adherence to best practices- and policy compliance.
In a recent workload, there was a requirement to preferably use a free or open-source public root CA (certificate authority). Most secrets and certificates are already stored in Azure Key Vaults, the go-to option for storing secrets and accessing secrets in Azure, and as this CA certificate was to be used by another Azure service, storing the certificate in Azure Key Vault was thus an obvious choice. There are plenty of different alternatives, guides and approaches available on the internet for generating self-signed public root CAs, however, many of them requires multiple components/resources and resource groups to be deployed, such as DNS zones, Azure Functions and other resources for the generation and periodic renewal of the CA, approaches that sometimes even requiring highly privileged roles such as Owner privilege on the subscription scope in order to function, which is not ideal from a Principle of Least Privilege (PoLP)- and security perspective, and also includes quite a few steps for the generation itself, and thus adding both security concerns and some complexity for automating the CA renewal, which is required for self-signed root certificates. Some tools like Certbot provide reasonable ease of use with relatively few steps, however, the solution I came across with the least permissions and fewest steps required to generate a compliant public root CA was AZ ACME. Requiring only privileges to the Azure Key Vault resource, to which the certificate is to be issued, and the DNS zone or provider, AZ ACME replicates the certificate management capabilities existing natively between Azure Key Vault and its native TLS issuers, Digicert and GlobalSign, enabling the certificate to exhibit management capabilities as it was a fully featured CA, with no infrastructure or other components required whatsoever, requiring only two commands to be run only in order to generate a compliant Let’s Encrypt or ZeroSSL self-signed root CA. With its az cli-Esque syntax, and readily available GitHub Actions and BiCep samples, automating the periodic 90-day certificate renewal, e.g., with the cli installed on a runner VM, cluster- or build agent with roles assigned to the identity over the DNS Zone and Key Vault scopes, becomes a very straight-forward process. I can definitely recommend anyone looking for fulfilling uses cases that includes generating self-signed root CAs with a minimum of components, complexity and permissions needed to give AZ ACME a look.