Automatic SCP Pipeline for your LandingZone

Photo by Alex Kulikov on Unsplash

AWS Service Control Policies (SCPs) enable you to set granular permissions across your organization’s AWS accounts. SCPs are designed to help you enforce compliance and security requirements across your organization by limiting the actions that can be taken within AWS accounts. On the other hand, deployment pipelines are a set of automated processes that are used to build, test, and deploy software applications. They are used to speed up the software delivery process and ensure that code changes are deployed to production in a controlled and predictable manner.

While SCPs and deployment pipelines are not directly related, deployment pipelines can be used to manage SCPs in a more efficient and scalable way. This can include automating SCP deployment, validation, testing, and updates as part of the deployment pipeline. By doing so, you can ensure that your policies are consistently and reliably applied to your AWS accounts, and that changes are automatically deployed to the appropriate accounts.

In this topic, we will explore how to take advantage of deployment pipelines for AWS Service Control Policies. We will cover the benefits of using deployment pipelines for SCPs, how to automate SCP deployment, validation, testing, and updates as part of the pipeline, and best practices for managing SCPs in the context of deployment pipelines. By the end of this topic, you will have a good understanding of how to use deployment pipelines to manage SCPs, and how to ensure that your AWS accounts are in compliance with your organization’s policies and standards.

AWS Service Control Policies (SCPs)

AWS Service Control Policies (SCPs) are a feature of AWS Organizations that enable you to set granular permissions across your organization’s AWS accounts. With SCPs, you can create policies that restrict the AWS services and actions that can be performed by entities (such as IAM users, roles, or AWS accounts) within your organization.

SCPs are designed to help you enforce compliance and security requirements across your organization, by limiting the actions that can be taken within AWS accounts. They work by specifying which AWS services and actions are allowed or denied for a given entity.

An SCP can be attached to the root of your AWS organization, to an organizational unit (OU), or to an individual AWS account. SCPs are evaluated in a top-down order, starting at the root of your organization and progressing to the specific AWS account or OU. This means that a denial in an SCP applied to the root of your organization will override any allowance granted in a more specific SCP.

By using SCPs, you can ensure that your organization’s AWS accounts are in compliance with your organization’s policies and standards. For example, you can use SCPs to restrict access to certain AWS services or prevent the creation of resources in specific regions.

Overall, AWS Service Control Policies are a powerful tool for managing and securing your organization’s AWS accounts, and can be an essential part of an effective AWS security strategy.

What is a deployment pipeline?

Deployment pipelines are a set of automated processes that are used to build, test, and deploy software applications. The primary goal of a deployment pipeline is to speed up the software delivery process and ensure that code changes are deployed to production in a controlled and predictable manner.

A deployment pipeline typically consists of several stages that are executed in sequence. These stages may include:

1. Build: This stage involves compiling source code, packaging the application, and creating artifacts that can be deployed to different environments.

2. Test: This stage involves running automated tests to ensure that the application meets functional and non-functional requirements.

3. Integration: This stage involves deploying the application to an integration environment and running additional tests to ensure that it works with other systems and services.

4. User Acceptance Testing (UAT): This stage involves deploying the application to a staging environment and conducting user acceptance testing to ensure that it meets business requirements.

5. Production: This stage involves deploying the application to production and making it available to end-users.

Deployment pipelines can be implemented using a variety of tools and technologies, including continuous integration and continuous delivery (CI/CD) tools like Jenkins, Travis CI, or AWS CodePipeline. These tools automate the entire process, from building the code to deploying it to production, and can be configured to trigger deployments automatically when new code is committed to a source code repository.

Overall, deployment pipelines provide an efficient and reliable way to deliver software applications to production, and are an essential component of modern software development practices.

How to take advantage of deployment pipelines for SCPs?

While deployment pipelines and AWS Service Control Policies (SCPs) are not directly related, deployment pipelines can be used to implement and manage SCPs in a more efficient and scalable way. Here are some ways that deployment pipelines can be used to take advantage of AWS SCPs:

1. Automated SCP deployment: SCPs can be deployed using AWS CloudFormation templates or the AWS Organizations API. By including SCP deployment as part of the deployment pipeline, you can automate the process of deploying SCPs to your AWS accounts and ensure that your policies are consistently applied across your organization.

2. SCP validation: SCPs can be complex and difficult to manage manually, particularly in larger organizations with multiple AWS accounts. By including SCP validation as part of the deployment pipeline, you can automatically check that the policies are correctly defined and that they do not conflict with other policies that are already in place.

3. SCP testing: SCPs can have unintended consequences if not carefully tested before they are deployed. By including SCP testing as part of the deployment pipeline, you can test your policies in a sandbox environment before they are deployed to production, and identify any issues or conflicts that need to be resolved.

4. SCP updates: As your organization evolves and your policies change, you may need to update your SCPs. By including SCP updates as part of the deployment pipeline, you can ensure that your policies are consistently updated across your organization, and that changes are automatically deployed to the appropriate AWS accounts.

Overall, by including AWS SCPs in your deployment pipeline, you can automate the process of managing and deploying policies across your organization, and ensure that your policies are consistently and reliably applied to your AWS accounts.

SCP Pipeline Example For Your LandingZone

This section provides a CloudFormation template that creates an AWS CodePipeline to deploy AWS Service Control Policies (SCPs) stored in an AWS CodeCommit repository to an AWS organization.

Here’s a breakdown of the template:

• AWSTemplateFormatVersion specifies the CloudFormation template version.
• Parameters section allows you to pass input values to the CloudFormation stack. In this case, it defines the parameters that will be used in the stack.
• CodeCommitRepoName is the name of the CodeCommit repository where the SCP templates are stored. It has a default value of my-scp-repo.
• CodeCommitBranchName is the name of the branch in the CodeCommit repository where the SCP templates are stored. It has a default value of main.
• CodeBuildProjectName is the name of the CodeBuild project used to validate the SCP templates. It has a default value of my-scp-validation-project.
• PipelineName is the name of the CodePipeline used to deploy the SCP templates. It has a default value of my-scp-pipeline.
• Resources section defines the AWS resources that will be created when the CloudFormation stack is launched.
• SCPRepo is an AWS CodeCommit repository resource, which is created with the specified RepositoryName.
• SCPDeploymentPipeline is an AWS CodePipeline resource, which is created with the specified Name and RoleArn.
• Stages section of SCPDeploymentPipeline resource defines the pipeline stages and actions.
• Source is the first pipeline stage and has a single action called SourceAction. This action retrieves the SCP templates from the CodeCommit repository.
• Build is the second pipeline stage and has two actions:
• ValidateSCPs action uses an AWS CodeBuild project to validate the SCP templates.
• DeploySCPs action deploys the SCP templates to the AWS organization using the AWS Systems Manager Parameter Store.
• PipelineRole is an AWS Identity and Access Management (IAM) role that allows the CodePipeline to access the necessary AWS services. It has an AssumeRolePolicyDocument and a Policies section. The Policies section allows the role to perform actions on the CodeCommit repository and the AWS Systems Manager Parameter Store.

That’s a high-level overview of the CloudFormation template. When you launch this CloudFormation stack, it will create an AWS CodeCommit repository, an AWS CodePipeline, an AWS CodeBuild project, and an AWS IAM role to manage the pipeline. The pipeline retrieves the SCP templates from the CodeCommit repository, validates them with CodeBuild, and deploys them to the AWS organization with AWS Systems Manager Parameter Store.

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  CodeCommitRepoName:
    Type: String
    Default: my-scp-repo
    Description: The name of the CodeCommit repository where the SCP templates are stored.
  CodeCommitBranchName:
    Type: String
    Default: main
    Description: The name of the branch in the CodeCommit repository where the SCP templates are stored.
  CodeBuildProjectName:
    Type: String
    Default: my-scp-validation-project
    Description: The name of the CodeBuild project used to validate the SCP templates.
  PipelineName:
    Type: String
    Default: my-scp-pipeline
    Description: The name of the CodePipeline used to deploy the SCP templates.
Resources:
  SCPRepo:
    Type: "AWS::CodeCommit::Repository"
    Properties:
      RepositoryName: !Ref CodeCommitRepoName
  SCPDeploymentPipeline:
    Type: "AWS::CodePipeline::Pipeline"
    Properties:
      Name: !Ref PipelineName
      RoleArn: !GetAtt [PipelineRole, Arn]
      Stages:
        - Name: "Source"
          Actions:
            - Name: "SourceAction"
              ActionTypeId:
                Category: "Source"
                Owner: "AWS"
                Version: "1"
                Provider: "CodeCommit"
              OutputArtifacts:
                - Name: "SCPSource"
              Configuration:
                RepositoryName: !Ref CodeCommitRepoName
                BranchName: !Ref CodeCommitBranchName
        - Name: "Build"
          Actions:
            - Name: "ValidateSCPs"
              ActionTypeId:
                Category: "Build"
                Owner: "AWS"
                Version: "1"
                Provider: "CodeBuild"
              InputArtifacts:
                - Name: "SCPSource"
              OutputArtifacts:
                - Name: "SCPTemplates"
              Configuration:
                ProjectName: !Ref CodeBuildProjectName
              RunOrder: 1
            - Name: "DeploySCPs"
              ActionTypeId:
                Category: "Deploy"
                Owner: "AWS"
                Version: "1"
                Provider: "SSM"
              InputArtifacts:
                - Name: "SCPTemplates"
              Configuration:
                Name: "deploy-to-organization"
                TargetType: "AWS:ORGANIZATIONS"
                Targets: [ "*" ]
                Parameters:
                  policy: !Join ["", ["file://", !FindInMap [Environment, !Ref "AWS::Region", PolicyFileName]]]
              RunOrder: 2
  PipelineRole:
    Type: "AWS::IAM::Role"
    Properties:
      RoleName: "my-scp-pipeline-role"
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service:
                - "codepipeline.amazonaws.com"
            Action: "sts:AssumeRole"
      Policies:
        - PolicyName: "my-scp-policy"
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: "Allow"
                Action:
                  - "codecommit:GitPull"
                  - "codecommit:ListBranches"
                  - "codecommit:GetCommit"
                Resource: !Join [ "", [ "arn:aws:codecommit:*:", !Ref "AWS::AccountId", ":", !Ref CodeCommitRepoName ] ]
              - Effect: "Allow"
                Action:
                  - "ssm:UpdateServiceSetting"
                  - "organizations:DescribeOrganization"
                  - "organizations:CreatePolicy"

Example for GitHub

This CloudFormation template is an updated version of the original, but using GitHub instead of CodeCommit as the repository for the SCP templates. It creates a CodePipeline that automatically deploys any new or updated SCP templates to your AWS Organizations account, after validating them with a CodeBuild project.

The template includes several parameters that can be customized, such as the name of the GitHub repository, the branch where the SCP templates are stored, the name of the CodeBuild project, and the name of the CodePipeline.

The resources created by this template include an AWS CodePipeline, a GitHub repository, and an IAM role with the necessary permissions to perform the pipeline operations. The pipeline has two stages: “Source” and “Build.” In the “Source” stage, the pipeline retrieves the SCP templates from the GitHub repository. In the “Build” stage, the pipeline validates the SCP templates using a CodeBuild project, and then deploys them to the AWS Organizations account using the AWS Systems Manager (SSM) service.

The pipeline role has permissions to access the GitHub repository, list its branches, and get commits. It also has permissions to update the SSM service settings, create an organization policy, and describe the organization.

Overall, this CloudFormation template automates the process of deploying SCP templates to your AWS Organizations account, making it easier to manage your account and enforce your security policies.

Note that this template assumes that you have stored a GitHub personal access token in AWS Secrets Manager with the name ‘my-github-token:SecretString:token’

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  GitHubOwner:
    Type: String
    Default: my-github-account
    Description: The name of the GitHub account where the SCP templates are stored.
  GitHubRepoName:
    Type: String
    Default: my-scp-repo
    Description: The name of the GitHub repository where the SCP templates are stored.
  GitHubBranchName:
    Type: String
    Default: main
    Description: The name of the branch in the GitHub repository where the SCP templates are stored.
  CodeBuildProjectName:
    Type: String
    Default: my-scp-validation-project
    Description: The name of the CodeBuild project used to validate the SCP templates.
  PipelineName:
    Type: String
    Default: my-scp-pipeline
    Description: The name of the CodePipeline used to deploy the SCP templates.
Resources:
  SCPDeploymentPipeline:
    Type: "AWS::CodePipeline::Pipeline"
    Properties:
      Name: !Ref PipelineName
      RoleArn: !GetAtt [PipelineRole, Arn]
      Stages:
        - Name: "Source"
          Actions:
            - Name: "SourceAction"
              ActionTypeId:
                Category: "Source"
                Owner: "ThirdParty"
                Version: "1"
                Provider: "GitHub"
              OutputArtifacts:
                - Name: "SCPSource"
              Configuration:
                Owner: !Ref GitHubOwner
                Repo: !Ref GitHubRepoName
                Branch: !Ref GitHubBranchName
                OAuthToken: "{{resolve:secretsmanager:my-github-token:SecretString:token}}"
        - Name: "Build"
          Actions:
            - Name: "ValidateSCPs"
              ActionTypeId:
                Category: "Build"
                Owner: "AWS"
                Version: "1"
                Provider: "CodeBuild"
              InputArtifacts:
                - Name: "SCPSource"
              OutputArtifacts:
                - Name: "SCPTemplates"
              Configuration:
                ProjectName: !Ref CodeBuildProjectName
              RunOrder: 1
            - Name: "DeploySCPs"
              ActionTypeId:
                Category: "Deploy"
                Owner: "AWS"
                Version: "1"
                Provider: "SSM"
              InputArtifacts:
                - Name: "SCPTemplates"
              Configuration:
                Name: "deploy-to-organization"
                TargetType: "AWS:ORGANIZATIONS"
                Targets: [ "*" ]
                Parameters:
                  policy: !Join ["", ["file://", !FindInMap [Environment, !Ref "AWS::Region", PolicyFileName]]]
              RunOrder: 2
  PipelineRole:
    Type: "AWS::IAM::Role"
    Properties:
      RoleName: "my-scp-pipeline-role"
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service:
                - "codepipeline.amazonaws.com"
            Action: "sts:AssumeRole"
      Policies:
        - PolicyName: "my-scp-policy"
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: "Allow"
                Action:
                  - "codebuild:StartBuild"
                  - "ssm:UpdateServiceSetting"
                  - "organizations:DescribeOrganization"
                  - "organizations:CreatePolicy"
                Resource: "*"

About the Authors:

Sven Leiß

My name is Sven Leiss and I am an 5x certified AWS enthusiast and AWS Migration Blackbelt. I have been working in the AWS space for the past 7 years and have extensive knowledge of the AWS platform and its various services. I am passionate about helping customers get the most out of the cloud and have a great track record of successful implementations.

Mirac Coskuner

My name is Mirac Coskuner and I am an 3x certified AWS enthusiast and AWS Migration Blackbelt. I have been working in the AWS space for the past 2 years and have extensive knowledge of the AWS platform and its various services.

We have extensive experience in designing and implementing cloud architectures using AWS services such as EC2, S3, Lambda and more. Our team is well versed in DevOps and AWS cloud migration journeys.

If you are looking for experienced AWS experts, we would be more than happy to help. Feel free to contact us to discuss your cloud needs and see how we can help you get the most out of the AWS cloud.