Enforce compliance using AWS Organizations tag policies with Serverless Transit Network Orchestrator (STNO)

Our customers commonly need the ability to create a self-service model for establishing networking connectivity between their accounts, while maintaining a predetermined security posture. The self-service model provides guardrails to disallow insecure or incorrect configurations. The Serverless Transit Network Orchestrator (STNO) v3.0 solution automates the process of setting up and managing transit networks in distributed AWS environments. Furthermore, it creates a web interface to help control, audit, and approve (transit) network changes.

AWS Organizations tag policies are a type of policy that can help you standardize tags across resources in your organization’s accounts. In a tag policy, you specify tagging rules that are applicable to resources when they’re tagged. Tag policies let you enforce compliance by the ability to create a resource with only allowed values.

The new release (v3.0) of the STNO solution now lets you use “/” or “:” as a delimiter when tagging your resources. This helps you control which route tables you allow route propagation to via AWS Organizations tag policies.

The STNO solution, combined with AWS Organizations tag policies, provides an alternative to manually allowing each request via the STNO management web interface, or automatically approving all requests. In this post, we demonstrate how to leverage tag policies with STNO to make sure that accounts are connected and propagated to the right AWS Transit Gateway route tables. These guardrails will limit the changes that end users can make to configurations you choose for association, and propagation to Transit Gateway route tables. Therefore, this provides a better security posture as well as proper configuration.

We walk you through a use-case where AWS Organizations tag policies can be used to make sure that a developer account’s VPC isn’t allowed to attach to the production Transit Gateway route table.

Solution Overview

• OU-based configuration – In the preceding diagram, we have designed our OU structure to correspond with our desired software development stages. The tag policies that we configure will be at the OU level, and they will apply to all of the member accounts within. This configuration is easily managed and will scale with our organization as we grow.
• Limit east-west traffic – Because we don’t want traffic from the development accounts communicating to staging or production (east-west traffic), we will control the route propagation and attachment via Tag Policies. By controlling the configuration that an end user can tell the STNO to perform, we are making sure that there can’t be any unapproved east-west traffic.
• Ensure proper network configuration – In our case preceding, we must also make sure that route propagation from the VPC to the on-premises Transit Gateway route table is configured. Our configured tag policy will make sure that the end user specifies on-premises in addition to the proper environment transit gateway route table (Development, Staging, Production).

Prerequisites

1. An AWS Organizations management account, with at least one OU (Development) and corresponding AWS account where you run your development workloads, as well as another Shared Services/Networking OU with a corresponding AWS account that you will use to manage AWS Transit Gateway.
2. Deployment of hub and spoke configurations using the STNO solution. For additional guidance on setting up your networks, refer to this blog.

Solution Walkthrough

• Setup AWS Organizations tag policies
  • AWS Management Console → AWS Organizations → Policies → Select Tag policies
  • Select Enable tag policies

• Create AWS Organizations Tag Policy
  • Now that tag policies are enabled, you should see a screen like the following, then select Create policy.

• Fill in policy name and description, for our example we used “Development-STNO” and “Limit development accounts AWS Transit Gateway attachment and route propagation.
  • Define Tag keys
    • Fill in the Tag key, and check Tag key capitalization compliance (optional), Tag value compliance, and select Specify values, in our case that value will be Development

• • • Next, to prevent users from specifying values that we did not approve, we will check the box Prevent noncompliant operations for this tag. You will the see this box where we must limit compliance to ec2:vpc and ec2:subnets only.

• • • Once your Associate-with looks like mine, we will select Add tag key to add the next tag that we must control, Propagate-to. Following the same process for the previous key with the exception of values, we will instead add Development/On-premises. Note that to limit the number of possible combinations you would need to enter into the list of allowed values, we recommend having a tagging strategy in place, such as allowing routes to be defined in alphabetic ordering while tagging. For example, in the current setup, if you try to tag your subnet with On-premises/Development value, it will be rejected unless you also let this value be in the list of allowed values for the “Propagate-to” tag key. Both are valid combinations, but restricting entry to alphabetic ordering will allow minimal maintenance, especially when you must allow multiple cross-account propagation (Development, On-premises, Staging), which will require up to six allowed values for “Propagate-to”.

• • Attach tag policy to Development OU.
    • Next, you will attach the policy to the Development OU. Under the Targets tab of the Development-STNO policy, select Attach.

• • • Next, attach the tag policy to your Development OU, and select Attach policy.

Demonstration

If I now log in to a development account and try to create a subnet, then in the following I will demonstrate both success and error when the supplied value is conforming and non-conforming.

Propagate-to example of creating subnet with the correct tag value

Example of creating subnet with the incorrect tag value

Example modifying Associate-with tag with the incorrect value

Example modifying Associate-with tag with the correct value

Summary

In the above steps, we have walked you through the setup process utilizing the new capability of STNO where tag policies can be used to limit both propagations and associations. By utilizing these tag policies, we can setup an environment where our end users can create, modify, and delete their VPCs while still getting access to corporate resources as a self-service model requiring no additional approvals. Additionally, if we wanted to use the approval process within the STNO, we have that option.

Clean-up

• Go to AWS Organizations and select Policies, then select Tag policies, and then select the policy we created Development-STNO
• Select Delete, type Development-STNO to confirm deletion, then select Delete

Conclusion

In this post, you configured AWS Organization tag policies to enforce compliance, and allow only approved route associations and propagation, while giving the individual teams flexibility to tag their VPCs and automatically apply routing changes to the target environments via STNO.

Author Bio

	Jared Keating is a Senior Cloud Consultant with AWS Professional Services. Jared assists customers with their cloud infrastructure, compliance, and automation requirements drawing from his 20+ years of experience in IT.
	Kishore Dhamodaran is a Senior Cloud Consultant with AWS Professional Services. Kishore helps customers with their Cloud Enterprise Strategy and migration journey, leveraging his years of industry and cloud experience.