Introduction
In the rapidly evolving landscape of cloud computing, security remains paramount. Ensuring the confidentiality, integrity, and availability of your cloud resources is a complex task that requires a well-defined approach. A crucial component of this strategy lies in Identity and Access Management (IAM), which plays a pivotal role in safeguarding sensitive data, controlling user access, and mitigating or reducing potential threats.
In the cloud world, where dynamic scalability and shared resources are the norm, traditional security models face new challenges. Here, IAM can step in to provide a robust solution to some of those. IAM offers a systematic approach to managing digital identities, defining access privileges, and regulating interactions within a cloud ecosystem. With IAM, you can determine precisely who can access what resources, under what circumstances, and with what level of authority.
But what if there was a way to elevate IAM management even further, making it not just secure, but also highly efficient, repeatable, easily scalable, and error-resistant? This is where Infrastructure as Code (IaC) comes into play. IaC is a transformative concept that empowers you to manage and provision your cloud infrastructure using code, allowing you to codify, version, and automate your setup. The fusion of IAM with IaC creates an interesting harmony with cloud security, streamlining access control, enhancing visibility, and enabling rapid responses to changes and challenges.
While IaC offers a degree of cloud-agnosticism by abstracting some cloud-specific concepts, it's important to note that complete cloud-agnosticism might not always be achievable due to provider-specific nuances. Nonetheless, the principles of IAM and IaC provide a highly standardized approach to security and automation that is applicable across various cloud environments and providers.
In this blog, we'll go on a journey to explore the synergy between IAM and IaC as a part of cloud security. We'll look into the significance of IAM in ensuring data integrity and confidentiality, and unveil the benefits of adopting IaC for IAM management. By the end, you'll have scratched the surface in understanding how to build a strong security foundation using these powerful tools, enabling a more secure and efficient cloud experience.
Understanding IAM Challenges
Now that we have an understanding of the important role IAM plays in cloud security, let's go deeper into the challenges that often arise when managing IAM resources manually. If you've tried managing IAM manually, you're likely well-acquainted with the complexities that accompany it, and if you haven't, lucky you.
Working within critical infrastructure as I do, especially with the European NIS and NIS2 regulations, IAM is always a major focal point for both internal and external auditors. Knowing who has access to what, when that access has been used, and making sure your infrastructure doesn't have highly privileged users without a business specific need, are some things we just have to be in control of, or possibly face repercussions.
Manually configuring and updating IAM roles, policies, and permissions can quickly become a convoluted task, especially as your cloud infrastructure expands. The risk of human error, whether it's granting excessive privileges or overlooking necessary access, looms large. This not only hampers security but also increases the chances of compliance or regulatory violations.
As teams grow and projects evolve, maintaining consistency across IAM settings becomes increasingly daunting. It's not uncommon for teams to have different IAM policies or users, resulting in a fragmented security landscape. Additionally, keeping track of changes over time and maintaining an accurate record of who has access to what resources can quickly become an administrative nightmare.
The intricacies of IAM can also create barriers to agility. Manually configuring access for every new team member or service can slow down deployment processes. This friction between security and speed can lead to workarounds that undermine the very security measures IAM aims to enforce.
So, what's a possible solution? Automation. By embracing the principles of Infrastructure as Code (IaC), you can overcome many of these challenges and enhance your IAM management. Automating IAM resource provisioning and updates not only reduces the risk of errors but also ensures consistency across your cloud environment. This means that IAM settings can be treated as code, versioned, and deployed just like any other infrastructure element.
In a moment, we'll explore the advantages of automating IAM through IaC, demonstrating how it not only mitigates the challenges we've discussed but also lays the groundwork for a more secure and efficient cloud environment.
Getting Started with Terraform and IAM
Now that we have a clear understanding of the challenges surrounding manual IAM management, let's explore how Terraform comes to the rescue, offering a powerful and efficient solution. Terraform lets you define, manage, and provision your cloud infrastructure resources as code. This aligns perfectly with the goal of enhancing IAM management, providing a consistent and automated approach to access control. It might not be all aspects of IAM that's suited for being handled through Terraform, but there are certain places where it excels. We'll be exploring those here.
Terraform's syntax and structure are designed for simplicity and readability. At its core, you define your desired cloud infrastructure state in a declarative manner using HashiCorp Configuration Language (HCL). This means you specify what IAM resources you need, such as roles, policies, and permissions, without worrying about the how-to details. Terraform then takes care of translating your code into actual API calls to your cloud provider.
The beauty of Terraform is its vendor-agnostic nature. It supports the "big three" – AWS, Azure, and Google Cloud Project. Each of these platforms provides Terraform providers that offer a wide range of possibilities, including IAM-related ones. This means you can use the same Terraform syntax to manage IAM resources across different cloud providers, ensuring consistency in your access control strategy regardless of your chosen platform. Mind you, the code will be different, but the approach is generally the same.
When you want to use Terraform to define IAM roles, policies, and instance profiles you will, for AWS, be using the aws_iam_role, aws_iam_policy, and aws_iam_instance_profile resource types. Azure provides similar functionality with its azurerm_role_definition, azurerm_role_assignment, and other IAM-related resources. Google Cloud follows suit with its google_project_iam_binding, google_project_iam_member, and google_project_iam_policy resources.
A simple example using Terraform to define an Azure custom role would look like this:
resource "azurerm_role_definition" "custom_storage_role" {
name = "CustomStorageRole"
scope = "/subscriptions/00000000-0000-0000-0000-000000000000"
description = "A custom role for read access to storage accounts"
permissions {
actions = [
"Microsoft.Storage/storageAccounts/*/read"
]
}
assignable_scopes = ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}
With this role you'd be able to list/view all storage account objects like blob services, file services etc. You wouldn't be able to create new objects or delete existing ones, as we haven't permitted those actions.
In AWS you would need a bit more code to do the same. With AWS you have to first define the custom access policy, then define the custom role, and lastly apply the custom access policy to the custom role. That would look like this:
# Here you create the custom access policy, stating what is allowed or not
resource "aws_iam_policy" "custom_storage_policy" {
name = "CustomStoragePolicy"
description = "A custom policy for read access to s3 buckets"
policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Action = "s3:GetObject",
Effect = "Allow",
Resource = "*"
}
]
})
}
# Here you define the custom role
resource "aws_iam_role" "custom_storage_role" {
name = "CustomStorageRole"
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Action = "sts:AssumeRole",
Effect = "Allow",
Principal = {
Service = "ec2.amazonaws.com"
}
}
]
})
}
# And here you attach the custom access policy to the custom role
resource "aws_iam_role_policy_attachment" "custom_storage_role_policy_attachment" {
storage_policy_arn = aws_iam_policy.custom_storage_policy.arn
storage_role = aws_iam_role.custom_storage_role.name
}
In short, due to Terraform's approach to vendor-agnosticism, you're able to accomplish the same tasks for different Cloud Service Providers, but the road to get there might be slightly different. In the next section, we'll dive more into specific use cases and practical examples that showcase the power of Terraform in IAM management.
Implementing IAM Best Practices with Terraform
With a foundation on the importance of IAM and its challenges that come along with it, as well as an understanding of how Terraform can streamline parts of IAM management, let's delve into how you can implement some IAM best practices using Terraform. These best practices not only enhance your cloud security but also contribute to a more organized and efficient access control strategy. I'll focus on Azure from here on out, but both AWS and GCP have viable options for solving these challenges.
Secure Identity Provisioning and Deprovisioning:
Terraform enables pretty straight forward identity provisioning and deprovisioning by codifying account management processes. Now, using Terraform to manage very dynamic entities such as user accounts, might not always be the best solution, however you might very well utilize Terraform's capabilities to create, update, and delete system or service users, or Managed Identities in Azure. This way you can also set up easy restrictions on who can actually manage these resources.
Role-Based Access Control (RBAC) and Least Privilege:
As hinted at with the first example, you can leverage Terraform to define IAM roles and policies, adhering to the principle of least privilege. You can create custom roles tailored to specific responsibilities and attach only the strictly necessary permissions. This ensures that users and services have access to resources essential for their tasks without unnecessary privileges.
Multi-Factor Authentication (MFA) and Strong Authentication Policies:
Besides performing granular access control through custom roles, you can also strengthen authentication mechanisms by using Terraform to enforce MFA and strong authentication policies. You can configure IAM roles to require MFA for specific actions or under certain conditions, or in other words; conditional access through code.
So, How Can You Implement These Practices?
Secure Identity Provisioning and Deprovisioning:
To implement secure account provisioning and deprovisioning in Azure using Terraform, you can utilize the `azurerm_user_assigned_identity` resource. This resource allows you to create and manage Managed Identities, which can be associated with Azure resources, such as Virtual Machines or App Services.
resource "azurerm_user_assigned_identity" "example_identity" {
name = "CustomManagedIdentity"
resource_group_name = "CustomResourceGroup"
location = "northeurope"
}
However, just creating the identity is not going to help us much, so let's see what you can do to add permissions to your newly created account.
Role-Based Access Control (RBAC) and Least Privilege:
You can define custom Azure RBAC roles with Terraform's azurerm_role_definition resource. This allows you to assign appropriate permissions to these roles and associate them with users or groups using the azurerm_role_assignment resource. This way, you maintain fine-grained access control while keeping permissions aligned with responsibilities.
One option would be to simply use Azure built-in roles. You can assign these directly with the 'azurerm_role_assignment' resource, but what often happens is that Microsofts built-in roles can be a bit over permissive, e.g., the "Storage Account Contributor" built-it role also lets the identity create support tickets, which we might not need, so let's build a custom one just for fun.
Say we expand on our previous custom role. We would like for the Managed Identity to be able to manage storage account creation, but it shouldn't be able to delete anything or create support tickets. That could look like this:
resource "azurerm_role_definition" "custom_storage_role" {
name = "CustomStorageRole"
scope = "/subscriptions/00000000-0000-0000-0000-000000000000"
description = "A custom role for management of storage accounts"
permissions {
actions = [
"Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action",#Joins resource such as storage account or SQL database to a subnet.
"Microsoft.Resources/deployments/*", #Create and manage a deployment
"Microsoft.Resources/subscriptions/resourceGroups/read", #Gets or lists resource groups.
"Microsoft.Storage/storageAccounts/*", #Create and manage storage accounts
] not_actions = [
"Microsoft.Support/*"
] }
assignable_scopes = ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}There's a bunch of additional permissions in the built-in role, that we don't explicitly need for our purpose, and have therefore been left out. The role we're left with, is able to deploy storage account resources to a given resource group and join the resource to a specified subnet. Or remove it again.
To assign it to the previously created Managed Identity, you would include the following code block:
resource "azurerm_role_assignment" "custom_assignment" {
principal_id = azurerm_user_assigned_identity.custom_identity.principal_id
role_definition_name = azurerm_role_definition.custom_storage_role.name
scope = azurerm_role_definition.custom_storage_role.scope
}
And that's it! An attempt at a least privilege implementation of permissions for a Managed Identity managing storage accounts.
Multi-Factor Authentication (MFA) and Strong Authentication Policies:
For your user accounts, you can easily implement and manage Azure MFA for specific user actions by utilizing Terraform's azuread_conditional_access_policy resource from the azuread provider - notice, previously we used the azurerm provider.
You start by creating an Azure policy that enforces MFA requirements and then assign this policy to specific users or groups using Terraform. You can even specify specific conditions to trigger the MFA authentication if you don't want to prompt for it at all times.
resource "azuread_conditional_access_policy" "custom_mfa_policy" {
display_name = "Custom Policy Require MFA"
state = "enabled"
conditions {
client_app_types = ["all"]
applications {
included_applications = ["Office365"]
}
locations {
included_locations = ["All"]
excluded_locations = ["AllTrusted"]
}
platforms {
included_platforms = ["iOS", "windows"] excluded_platforms = []
}
users {
included_users = ["All"]
}
}
grant_controls {
operator = "OR"
built_in_controls = ["mfa"]
}
}
The conditions define when the policy is applied, here it's for all client application types (browser, mobile clients, etc.), for access to Office365, from all locations other than those defined as trusted, using any iOS or Windows device (that probably says a bit of what I'm used to work with), for all your users. With this specific policy, you might run into an angry office mob rather quickly as it's quite generic, but you can easily adjust it to only be specific user groups or individuals like your privileged users.
The 'grant_controls' block specifies which built-in Azure policy we want to apply.
And with that, you have a working MFA policy for Azure, maintainable through Terraform. AWS and GCP have some amazing go-to resources and providers for the same functionality, so there's no reason not to try it out!
Wrapping up
As we've unpacked, managing IAM manually is laden with challenges. Missteps in configuration can have significant repercussions, leaving vulnerabilities in the security infrastructure, thus the importance of streamlined IAM processes cannot be overstated.
The potential benefits of Terraform in IAM management, especially in enforcing best practices, are considerable. From provisioning certain types of identities securely in Azure, adhering to the principle of least privilege, to enforcing stringent Multi-Factor Authentication or Conditional Access policies, Terraform emerges as an enabler of robust access control strategies.
In wrapping up, while the challenges of IAM are daunting, they are also necessary to overcome. Terraform offers a promising path forward. By utilizing Terraform in the right locations, staying informed about its challenges, and combining it with sound cloud architectural practices, organizations can harness the true potential of the cloud while maintaining rigorous security protocols.
SEC510: Public Cloud Security: AWS, Azure, and GCP
This blog supports content taught in our public cloud security course. Learn more about the course here.
About the Author
Andreas Laursen Lindhagen is a Senior IT Security Architect at DSB A/S, Danish State Railways. He holds multiple certifications, including GCLD and GPCS, and has more than six years of experience in information security, from both consultancy and critical infrastructure companies, focusing on cloud and security architecture. Andreas has a MSc in Information Technology with a specialization in Cybersecurity from the Technical University of Denmark. Connect with Andreas on LinkedIn.
