Sorry, currently no German translation is available for this blog post

Context

This blog post explores the application of least privilege principles in the management of AWS Core Account resources through Infrastructure as Code (IaC). At its core, the principle of least privilege is pivotal to many security frameworks, dictating that individuals and processes should only possess the essential permissions needed for their roles. Standards such as ISO/IEC 27001, NIST SP 800-53, and PCI DSS all champion this principle to curb the risks associated with unauthorized access and data breaches.

The tech industry widely endorses the use of IaC tools, like Terraform, for cloud service management due to several compelling benefits:

  • Speed and Efficiency: Automation via IaC significantly trims down deployment times.
  • Consistency and Repeatability: Ensures deployments are uniform and error-free.
  • Agility and Scalability: Facilitates quick adaptations and enhancements to AWS resource allocations.
  • Security and Compliance: Embeds security directly into deployment processes, enabling automated compliance checks that preemptively address potential infractions.
  • Collaboration and Governance: Promotes effective collaboration through meticulous version control and ensures robust oversight of infrastructural modifications.

We will focus on IaC CI/CD pipelines to manage the deployment of Foundation Core features, integrating a variety of AWS Services across multiple Core Accounts. The deployment process covers several principal use cases, including:

  • Use Case 1: A dedicated Core Pipeline deploys resources within a single Core Account.
  • Use Case 2: Coordinated efforts of multiple Core Pipelines manage deployments to a singular Core Account.
  • Use Case 3: A single Core Pipeline administers resource deployment across multiple Core Accounts.
Use-Cases

The integration of least privilege principles into IaC CI/CD pipelines especially for the Core Accounts is crucial, underscoring the necessity of stringent access controls to safeguard your infrastructure.

Solution

Our solution aims to redefine how CI/CD Pipelines for AWS Landing Zone core accounts are managed by leveraging again Infrastructure as Code. The solution uses Azure DevOps as the CI/CD platform of choice (but can also be adopted to other platforms like e.g. Terraform Cloud). This approach focuses on automating the provisioning and management of Azure DevOps and AWS resources, enhancing security, and ensuring operational efficiency.

Azure DevOps Integration: The core of our solution, the ‘Core-CICD-Manager’, is a Terraform-based pipeline hosted on Azure DevOps. This pipeline is meticulously designed to handle multiple use cases across AWS Core Accounts by interpreting a straightforward HCL (HashiCorp Configuration Language) specification file.

Specification Driven Deployment: Each pipeline within the ‘Core-CICD-Manager’ is configured to deploy core CI/CD pipelines based on predefined settings. These settings dictate which AWS principals are provisioned, ensuring that each deployment adheres to the principle of least privilege and is compliant with organizational policies.

Managed AWS Principals and DevOps Resources: For every core CI/CD pipeline, corresponding AWS Principals and Azure DevOps resources (repositories and pipelines) are managed and maintained efficiently. This ensures a streamlined workflow from development to production, minimizing the potential for errors and security breaches.

Visual and Technical Overview: Core CICD-Manager Use Cases

Simplified Configuration: Here’s an example of how easily the Core CI/CD resources can be specified and managed through our solution.

  • It will provision ADO resources (repository and pipeline) named ‘Org-Mgmt’ with three feature-specific AWS principals in the AWS Org Management account (org_mgmt).
  • It will provision ADO resources (repository and pipeline) named ‘Core-SCP’ with a AWS principal to manage the SCPs in the AWS Org Management account (org_mgmt).
  • It will provision ADO resources (repository and pipeline) named ‘Core-SSO’ with a AWS principal to manage the AWS Identity Center in the AWS Org Management account (org_mgmt).
  • It will provision ADO resources (repository and pipeline) named ‘Core-Org-CloudTrail’ with a AWS principal to manage the Organization CloudTrail in the AWS Org Management account (org_mgmt) and a AWS principal to manage the Organization CloudTrail Bucket in the AWS Core Logging account (core_logging).
  • It will provision ADO resources (repository and pipeline) named ‘Core-Security’ with a AWS principal to manage the resources in the AWS Core Security account (core_security).
  • It will provision ADO resources (repository and pipeline) named ‘Core-Baselining’ with a AWS principal to manage the resources in the AWS Core Security account (core_baselining).
core_cicd_settings = {
  pipelines = [
    {
      pipeline_name = "Org-Mgmt"
      aws_targets = [
        {
          feature_name     = "OrgMgmt"
          cf_template_name = "org_mgmt.yaml.tftpl"
          accounts = ["org_mgmt"]
        },
        {
          feature_name     = "OrgDelegation"
          cf_template_name = "org_delegation.yaml.tftpl"
          accounts         = ["org_mgmt"]
        },
        {
          feature_name     = "OrgStructure"
          cf_template_name = "org_ou_mgmt.yaml.tftpl"
          accounts         = ["org_mgmt"]
        }            
      ]
    },
    {
      pipeline_name = "Core-SCP"
      aws_targets = [
        {
          feature_name     = "ScpManagement"
          cf_template_name = "scp_management.yaml.tftpl"
          accounts         = ["org_mgmt"]
        }
      ]
    },
    {
      pipeline_name = "Core-SSO"
      aws_targets = [
        {
          feature_name     = "IdentityCenter"
          cf_template_name = "aws_idc_admin.yaml.tftpl"
          accounts         = ["org_mgmt"]
        }
      ]
    },
    {
      pipeline_name = "Core-Org-CloudTrail"
      aws_targets = [
        {
          feature_name     = "CloudTrailAdmin"
          cf_template_name = "org_cloudtrail_admin.yaml.tftpl"
          accounts         = ["org_mgmt"]
        },
        {
          feature_name     = "CloudTrailBucket"
          cf_template_name = "org_cloudtrail_bucket.yaml.tftpl"
          accounts         = ["core_logging"]
        }

      ]
    },
    {
      pipeline_name = "Core-Security"
      aws_targets = [
        {
          feature_name     = "FullAccess"
          cf_template_name = "admin_access.yaml.tftpl"
          accounts         = ["core_security"]
        }
      ]
    },
    {
      pipeline_name = "Core-Baselining"
      aws_targets = [
        {
          feature_name     = "FullAccess"
          cf_template_name = "admin_access.yaml.tftpl"
          accounts         = ["core_baselining"]
        }
      ]
    },
  ]
  aws_settings = {
    org_mgmt_account_id = "org_mgmt"
    resource_prefix     = "foundation-"
  }
  ado_settings = {
    ado_org_service_url = "https://dev.azure.com/acai-consulting/"
    ado_project_name    = "aws-lab1"
    pipeline_default = {
      aws_agent_pool_name = "aws-production-ecs-agent"
      access_to_variable_groups = [
        "REPO_ACCESS_TOKEN"
      ]
    }
  }
  aws_account_id_lookup = {
    org_mgmt        = "471112581705"
    core_baselining = "992382707537"
    core_security   = "891377225812"
    core_logging    = "851725413964"
  }
}

The cf_template names refer to the specification of the provisioning AWS principals provided in the ‘/cicd-principals/acf-cicd-manager’ folders of this public ACF modules:

The specification above will lead to this deployment:

Core CICD-Manager in action

With ACAI AWS CI/CI Manager in place, this CI/CD setup can be accomplished in less than an hour.

If you have any questions, feel free to get in touch with us: blog@acai.gmbh