Resource Configuration Policies
Policies control the configuration of resources to enforce security and compliance standards like preventing public access to object storage buckets.After implementing policies for basic Service and Location Restrictions, many cloud foundation teams find the need to enforce configuration policies for certain cloud resources. Examples for common use cases of these policies are
Restricting public access to Object Storage Buckets to prevent accidental misconfiguration and exposure of data
Restricting access to public IPs for enforcing a private-only networking model in a Landing Zone
Enforcing activation of Centralized workload and infrastructure logs in cloud resources like virtual machines
Enforcing mandatory encryption of storage at rest, optionally in combination with a Managed Key Vault
Landing zones that offer a Shared Responsibility Model Alignment with a high degree of freedom for application teams to directly provision cloud resources should strongly consider enforcing resource configuration policies as a preventive measure for security incidents. Cloud foundation teams should consider implementing a healthy balance of preventive and reactive security measures like Resource Configuration Scanning to achieve a good cloud security posture.
Landing zones that offer less freedom for application teams for direct resource provisioning can enforce resource configuration shared or managed services that already implement the desired policies like a Virtual Network Service or Managed bastion hosts. This approach is usually most effective when combined with Service and Location Restrictions that prevent direct provisioning of the affected cloud resources.
Proven Patterns for Implementing Cloud Resource Configuration Policies
There are a myriad of cloud services and technical options to implement resource configuration policies on most cloud platforms. This can make it difficult for cloud foundation teams to find the right balance between establishing important guard rails, while not getting lost in the details. It’s therefore essential that cloud foundation teams decide on a crisp Shared Responsibility Model Alignment and strong Service and Location Restrictions for their Landing zones first, so they can restrict the “problem scope” of cloud resources that may need mandatory configuration policies.
Leverage the Cloud API as the Policy Enforcement Point
In a self-service model where application teams are able to directly interact with the cloud to provision resources, the cloud platform’s API offers the only possible policy enforcement point for implementing preventive policies.
The most common tools to achieve preventive resource configuration policies on popular cloud platforms are
Azure Policy with
DenyeffectAWS IAM Policies and service-specific APIs like S3
PublicAccessBlockGCP Organization Policies
Kubernetes Admission Controllers with Open Policy Agent
Start out with the most basic policies before going more fine granular. A cloud foundation evolves and you will have to plan for supporting this evolution anyway. In practice, this means starting with basic restrictions before going into details.
Review Provider Best-Practices and Published Policies
All of the hyper-scale cloud providers offer extensive guidance and reference implementations of best-practice configurations for secure resource configuration. Many providers offer libraries of published and maintained policies (e.g. Azure built-in policy definitions) that you can leverage out of the box. Reference landing zone implementations supplied by the cloud providers (see the Related Tools section below) also often contain custom policy implementations that can serve as templates for your own policies.
Leverage Infrastructure-as-Code and Resource Hierarchy
The policies and guardrails established by your cloud foundation team will have to evolve. By leveraging a Resource Hierarchy you can easily define policies at a central location and have them inherit to a large number of cloud tenants. Infrastructure-as-code also helps maintaining the set of policies and establishing a proper change management for the inevitable evolution of your policy definitions.
Build a Test Environment and Automate Testing
Custom resource configuration policies often contain complex logic. Having a dedicated environment for developing and testing your landing zones is thus essential.
Document Policy Decisions and Effects Extensively
Typical errors generated by cloud platforms in response to a violated resource configuration policy are very opaque. There’s nothing more frustrating for an application team trying to deploy their own cloud resources than a failed deployment with an obscure error message about a violated policy that the team didn’t know exists.
This is especially critical if the team was planning on using a particular service or configuration for their application and was not aware that the desired service or configuration is not available in the landing zone. Cloud foundation teams should thus maintain a central documentation of the resource policies effective in a particular landing zone. Most importantly, foundation teams should also document why a policy is in place and what compliance controls this helps implement with an accompanying compliance statement. Infrastructure as Code Landing Zone Frameworks like the Landing Zone Construction Kit can help automate this documentation of policy and compliance statements for your landing zones.
Related Tools
- GCP Fabric FAST
Reasonable defaults are set and additional helpful policies are proposed via code comments in the terraform files. They can be enabled on demand.
Learn More - GCP CFT - Example Foundation
A good amount of reasonable default policies are rolled out via Terraform. They match the best practices provided by GCPs Cloud Foundation Toolkit.
Learn More - Azure LZ accelerator - ES
Assign different policies and initiatives based on Microsoft Cloud Adaption Framework. Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc.
Learn More - Azure LZ Terraform module - ES
Reasonable defaults are set and additional helpful policies are proposed via code comments in the terraform files. They can be enabled on demand.
Learn More - Azure CAF Terraform Modules
Assign different policies and initiatives based on Microsoft Cloud Adaption Framework. Some examples are: Deploy activity logs and keep them in log analytic workspace, Enable Microsoft Defender for different services, Enable Microsoft Sentinel, Prevent usage of Public-IP and etc.
Learn More - AWS Control Tower with Account Factory
AWS Control Tower sets up 20 preventive guardrails (implemented by SCPs) and 3 detective guardrails (implemented by AWS Config). Those are the “Mandatory” guardrails enabled by default that we see are reasonable, such as disallowing deletion of the log archive bucket, disallowing changes to AWS IAM roles set up by CT and CloudFormation, etc. There are also more guardrails available that are not enabled by default, which are “Elective” and “Strongly Recommended” guardrails. Newly provisioned accounts with Account Factory inherit guardrails from their parent OU.
Learn More - AWS Control Tower with AFT
Accounts provisioned through AFT also inherit all guardrails from their parent OU which is covered by CT. Additional policies can be applied through AFT customization framework.
Learn More - AWS Landing Zone Accelerator
Reasonable guardrails are applied to the default domains Infrastructure, Security and Quarantine. It is easy to also define additional guardrails or to define them for additional, custom OUs.
Learn More - collie-cli
Deploy any policy via the terraform-based Landing Zone Construction Kit framework. Collie provides a workflow for documenting compliance controls and compliance statements that lay out what policies are in effect in your landing zone and how they help implement compliance controls.
Learn More
