Secure cloud assets using AWS Service Catalog’s Attribute Based Access Control

This post describes how Expedia Group protects production database assets from accidental or automated deletion using the new Attribute Based Access Control (ABAC) feature for AWS Service Catalog. We also cover the benefits of scaling using an ABAC strategy and how Expedia incorporated ABAC to their Cerebro platform.

Prerequisites

• AWS Service Catalog
• AWS Identity and Access Management (IAM)
• AWS Organizations
• AWS CloudFormation

ABAC is an authorization strategy that permits users to act on AWS resources based on attributes. AWS defines these attributes in the form of tags that can be associate to AWS resources or IAM resources such as users, groups, or roles. After defining the tags on AWS resources and users, AWS Service Catalog administrators can create tag-based IAM permissions policies for their principals (e.g. users, groups, roles), permitting or denying them the ability to act on specific resources (e.g. create, update, delete). By implementing ABAC, administrators can institute more granular permissions and dynamic controls. These policies adapt as the organization grows and evolves, alleviating administrators from dealing with cumbersome policy management.

AWS Service Catalog administrators can grant administrative privileges to specific users to manage resources within a given account. This operation streamlines workflows by sharing administrative tasks across the organization, protecting critical resources required for automation, and governing end user access to launch resources. To learn more about how to set up a multi-account hub and spoke model with AWS Service Catalog explore the blog How to set up a multi-region, multi-account catalog of company standard AWS Service Catalog products.

Expedia Group’s Database as a Service Platform (Cerebro)

Expedia Group’s Cerebro enables agile application development teams to self-serve and quickly provide the resources they need while adhering to the organization’s governance and controls. The Cerebro platform is a Database as a Service (DBaaS) offering built on AWS Service Catalog. Using this platform, Expedia Group quickly deploys, manages, and supports thousands of database clusters, all while enforcing governance, security controls, and best practices with a handful of engineers.

During Covid-19, the travel industry saw a significant business slowdown. Expedia Group, the world’s largest travel platform, was no different. The Expedia Group leadership took multiple initiatives to ensure that the company thrived even during the pandemic, including an effort to evolve the company toward a common platform strategy. This initiative has three goals: Drive efficiency, improve developer experience, and reduce platform costs by consolidating and decommissioning redundant tools. The Cerebro platform accelerates persistent store platform consolidation while reducing the operational overhead. Today it supports the data layer for over 700 applications within the Expedia Group portfolio with managed services and self-managed Amazon Elastic Compute Cloud (Amazon EC2) database instances. To learn more about Cerebro, see How Expedia Group built Database as a Service (DBaaS) offering using AWS Service Catalog.

Expedia Group’s use case of ABAC

Newly deployed database assets from Cerebro’s AWS Service Catalog are subject to governance policies within Expedia that detect assets missing specific tags and shut down instances that are out of compliance. The business problem here is unlike other deployed EC2 instances; database resources can be put into service immediately upon launch. They may already possess live production data or be deployed to the critical path of customer-facing services.

With ABAC, the AWS Service Catalog product deploys with a tag marking the underlying assets (EC2 Instance, Load Balancers, Auto Scaling Groups) as “ProtectedCerebroAsset = True.” This tag must be present on the IAM Role of any operational process attempting to shut down this asset automatically. This protection means that any automated process that detects and attempts to shut down these protected resources is denied termination rights. The Cerebro platform now detects and reports assets missing required tags for remediation rather than immediate termination.

Scaling permissions with ABAC

In an enterprise setting, it is not scalable to attach a policy individually to every IAM user or IAM group across tens or even hundreds of AWS accounts which is the case for the Expedia Group. Additionally, this solution must protect against termination requests from various AWS API operations, not only requests from AWS Service Catalog.

For this, Expedia Group used AWS Organizations, an account management service that enables multiple account consolidation into a centrally managed organization. An organization has one management account along with zero or more member accounts. Additionally, accounts can be organized in a hierarchical, tree-like structure with a root at the top and Organizational Units (OUs) nested under the root. Each account can also be directly in the root or placed in one of the OUs in the hierarchy, as shown in Figure 1 below.

Figure 1. AWS Organization with Service Control Policies (SCPs)

In Figure 2 below, the AWS Organization structure is set up in a sandbox environment. Expedia Group applies a shutdown protection for all its Cerebro resources at the OU level for every account under “Testing OU”. To achieve this, a Service Control Policy (SCP) is used.

Figure 2. Organizational structure in our sandbox environment

With an SCP, Expedia Group is able to manage permissions and control access at an account level, OU level, or even at the root level, as shown in Figure 1. SCPs are an organizational policy that can be used to manage permissions and offer central control over the maximum available permissions for all accounts in your organization. SCPs are like IAM permissions policies, and the key difference is an SCP do not grant permissions but instead defines guardrails or sets limits on the actions that IAM users and roles can perform.

Expedia Group created a comprehensive ABAC policy covering API termination requests from various services, including AWS Service Catalog, EC2, EC2 Auto Scaling, and CloudFormation. The SCP in the JSON block below extends across services by adding additional action blocks for each instance termination action. The condition block within the same JSON performs the attribute value check on the tag “ProtectedCerebroAsset” of any resource named in a termination request. If the value is “True,” the termination request is denied. If the tag doesn’t exist or the value is not “True,” the explicit denial is not triggered.

{"Version": "2012-10-17",
  "Statement": [
    {"Sid": "ExplicitDenial",
      "Effect": "Deny",
      "Action": [
        	"servicecatalog:TerminateProvisionedProduct",
	"ec2:TerminateInstances",
	"autoscaling:DeleteAutoScalingGroup",
        	"autoscaling:TerminateInstanceInAutoScalingGroup",
	"cloudformation:DeleteStackInstances"
      ],
      "Resource": ["*"],
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/ProtectedCerebroAsset": [
            "True"
          ]
        }}}]}

Now, this policy must be attached to the “Testing OU” as shown in the following Figure 3. Every account under the Testing OU will inherit this policy and hence all the Cerebro resources are protected from termination.

Figure 3. AWS Organizations Creation of Service Control Policy by Organizational Unit

Conclusion

This blog post showed how AWS Service Catalog’s integration with ABAC can protect critical automation workflows for Expedia Group. In doing so, you can improve system uptime and availability rather than redeploy resources or lose data. These ABAC policies can be quickly adjusted as resources and users change within the organization. The Expedia Group has applied this use case at scale, and it plans to expand its usage of ABAC to cover a variety of complex permission schemes.

Call to Action

To enable granular permissions with fewer policies consider using ABAC for AWS Service Catalog. You can get started with AWS Service Catalog and follow the instructions provided in this blog to try it out. To dive a little deeper into how AWS Organizations works with AWS Service Catalog you can read Simplify sharing your AWS Service Catalog portfolios in an AWS Organizations setup. To learn more you can refer the AWS documentation on ABAC for AWS, and for information on AWS services that support ABAC see our updated AWS services that work with IAM page.

Authors

Raghavendra Sayana is a staff database engineer at Expedia Group based out of Austin. He works on cloud automation specializing in database management, governance, migration, and modernization. He is passionate about building highly resilient, scalable, and self-service architecture solutions.