IaC and cloud provisioning
HCP Terraform provides you with a robust and efficient cloud provisioning workflow. The choice of workflow is important, and engineering effort will be required to change it later. The high level points required to implement a cloud provisioning workflow are as follows.
- Plan your project, covering installation and configuration of HCP Terraform or Terraform Enterprise, and how you intend to provide self-service capability to your internal customers. This is detailed further in the Terraform Operating Guide: Standardization HVD. Consideration now of how you will onboard, and work with, early-adopter teams, and later how to onboard gradually larger groups of teams until the platform is generally available will save a lot of time and effort.
- Consider the size and bandwidth of your platform team. Consider what would happen to their workload if any of the onboarding experience of your internal customers was not fully automated.
- Plan a landing zone provisioning workflow.
- Ensure your platform team is fully trained on IaC with Terraform and the cloud provider(s) you are using. All contributors should be expected to read, understand, and adhere to the HashiCorp Terraform language style guide(opens in new tab). Facility in your documentation should be given to guiding all developers to write Terraform code that is compliant with the style guide.
- Set up a Terraform workspace with cloud credentials.
- Store your Terraform code in your strategic version control system.
- Arrange for the IaC in the VCS to be run in the workspace in order to provision cloud resources.
- Consider the configuration required for HCP Terraform and for the workspace therein used to enable the deployment end-to-end in the context of your organization's security and compliance requirements. Revisit each step in the workflow, and consider the requirements in terms of engineering content and effort, and focus on the manual steps and what you would need to do to automate each step. Also consider what would be necessary in a disaster recovery scenario.
- If your deployment is intended to scale to a large number of teams, ensure to read the respective HVDs in this series.
The landing zone provisioning workflow is a crucial process that you implement for your application or development teams to ensure infrastructure provisioning in the appropriate landing zones. Each cloud platform has its own recommendations for implementing these landing zones, and for Kubernetes-based teams, a Kubernetes namespace can also serve as a component of a landing zone.
To achieve end-to-end cloud provisioning, developers will commit Terraform code to the designated repository, triggering a plan in HCP Terraform workspaces which will utilize cloud credentials to complete the plan phase. Once approved, the workspaces will apply the plan, provisioning the desired resources in the cloud.
The landing zone workflow should be implemented and owned by the platform team, partnering the networking, security, and finance teams, adhering to the guidance provided by the cloud vendors' well-architected framework. The landing zone must be implemented by your team before any application teams can initiate infrastructure provisioning in the cloud.
Cloud landing zones
A cloud landing zone is a foundational concept in cloud computing. It refers to an infrastructural design that facilitates secure and efficient cloud operations at scale.
A cloud landing zone provides a secure and compliant environment for an organization's cloud resources, including networking components, identity and access management, security measures, and baseline configurations. This forms a blueprint for setting up workloads in the cloud and serves as a launching pad for broader cloud adoption. Cloud landing zones address several important areas:
- Uniformity: Providing a standardized entry point for development teams to access cloud environments into which they have control over the infrastructural objects required to support the deployment of business-critical applications. Levels of control can vary between organizations.
- Operations: Includes operational tools and services, such as monitoring, logging, and automation tools. These help to manage and optimize cloud resources effectively.
- Cost management: Enables cost monitoring and optimization by facilitating tagging policies, budget alerts, and cost reporting tools.
- Identity and access management: Helps to enforce IAM policies, role-based access control (RBAC), and other permissions settings. This allows an organization to control who can access their cloud resources and what actions they can perform.
- Security and compliance: Security configurations like encryption settings, security group rules, and logging settings. This helps ensure that an organization's cloud environment complies with internal policies and external regulations.
- Networking: Configured with the network resources, such as virtual private clouds, subnets, and connectivity settings needed for operating workloads in the cloud. This includes setting up appropriate firewall rules, network access control lists, and routes to control inbound and outbound traffic.
Major cloud providers offer their own solutions for this approach:
- AWS Control Tower
- Azure Landing Zone Accelerator
- Cloud Foundation Toolkit for GCP.
While the implementation of cloud landing zones is a best practice recommendation, it takes significant additional planning for full scale-out in order to achieve the highest return on investment and engineering time to automate the end-to-end process in order to ensure platform team manual support task backlogs do not accumulate.
Workload identity
With dynamic credentials, users are able to authenticate their Vault providers using OpenID Connect (OIDC) compliant identity tokens to provide just-in-time credentials and eliminate the need to store long lived secrets on HCP Terraform/Enterprise. Some of the benefits of workload identity include the following.
- No more cloud credentials: Removes the need to store long-lived cloud credentials in HCP Terraform. Temporary cloud credentials are instead retrieved either from the CSP or via Vault on the fly.
- No more secret rotation logic: Credentials issued by cloud platform are temporary, removing the need to rotate secrets.
- Granular permissions control: Allows for using authentication and authorization tools from the cloud service provider to scope permissions based on HCP Terraform metadata such as run phase, workspace, or organization.
We recommend the implementation of workload identity to ensure that your cloud provisioning workflow adopts the most secure posture possible at all times. You will likely start by using fixed cloud credentials in order to authenicate your provider configuration and this is expected. Workflow identity should be part of your plans as the project proceeds and should be well-understood and fully-implemented prior to production deployment.