Build and Control your Cloud Service Catalog

| | | 0 comments

IT Product Lifecycle Management in AWSIn the brave new world of Cloud technology, corporate users are clamoring to get access to the cloud.  Whether it is developers testing out new applications, seasoned DBAs building out databases to review performance, or IT professionals building VMs for the first time, everyone wants a piece of the pie.  This can immediately raise questions about who should be allowed to build out infrastructure in the cloud and how to ensure these policies are enforced. . Without implementing tight controls, chaos and anarchy may prevail.  In the internal IT environment, strict rules regarding who could build what and how they could build it were set in stone, but with the cloud many of those old ways of doing things are no longer applicable. This brings about headaches for granting access to the cloud and making sure that users build within the guidelines that IT has dictated.

How can an IT organization put some rules or policies in place to make sure that infrastructure is built out according to the standard that management wants? Enter the AWS Service Catalog. The AWS Service Catalog provides users with a predefined set of CloudFormation templates, called Products, curated by IT to guarantee that infrastructure is built out in a repeatable and defined process.  Users that are given access to the AWS Service Catalog can deploy any Products that are defined within the Service Catalog Portfolio. This allows users to quickly deploy approved infrastructure all by themselves without having to involve IT. Users can do this because they are not given direct access to provision resources, rather each product within the AWS Service Catalog can be granted the proper permissions to deploy the predefined resources negating the need to provide your users any additional permissions.  This will prevent your users from deploying infrastructure outside of the pre-defined IT infrastructure.

Service Catalog – under the hood

To see how the AWS Service Catalog and its dependencies are built and deployed, let’s review the AWS Service Catalog in more detail.  To create an AWS Service Catalog for your users to consume, a Portfolio will need to be created in each region that you intend to use the AWS Service Catalog in.  Each Portfolio will be deployed with its own unique Portfolio ID per region. Access is granted to the Portfolio through two defined IAM Roles for admins and users.  IAM permissions for administering the Portfolio are granted through the IAM Role AWSServiceCatalogAdminFullAccess. Users that will be deploying the Products within the Portfolio will be granted access at a Portfolio level through the predefined IAM Role ServiceCatalogEndUserFullAccess.  It is recommended to assign each IAM Role to a corresponding IAM Group, granting users in the group the permissions provided by the IAM Role.

Once the Portfolio has been setup and users granted access to view the dashboard, Products will need to be added for users to deploy services and infrastructure in each region.  Similar to Portfolios, a Product ID is generated for each Product per region. Products are built from CloudFormation templates to allow for extremely granular control of what is provisioned.   In addition, parameterization of each CloudFormation template allows for flexibility for deployments such as EC2 instance size, the number RDS instance you wish to deploy, or VPC design options at deployment time.  Each Product is not limited to a single service either, multi-tier architectures with web servers, app servers, RDS instances and integrated lambda functions can be built out. Users are empowered to spin up complete environments with the click of a button, which allows for business agility while still enforcing security standards, utilization of AWS best practices, and cost containment..

 

An example of an AWS Service Catalog Product CloudFormation Template for DynamoDB.

AWSTemplateFormatVersion: 2010-09-09

Description: >-

DynamoDB_Table: This template demonstrates the creation of a DynamoDB table.

Parameters:

HashKeyElementName:

Description: HashType PrimaryKey Name

Type: String

AllowedPattern: ‘[a-zA-Z0-9]*’

MinLength: ‘1’

MaxLength: ‘2048’

ConstraintDescription: must contain only alphanumberic characters

HashKeyElementType:

Description: HashType PrimaryKey Type

Type: String

Default: S

AllowedPattern: ‘[S|N]’

MinLength: ‘1’

MaxLength: ‘1’

ConstraintDescription: must be either S or N

ReadCapacityUnits:

Description: Provisioned read throughput

Type: Number

Default: ‘5’

MinValue: ‘5’

MaxValue: ‘10000’

ConstraintDescription: must be between 5 and 10000

WriteCapacityUnits:

Description: Provisioned write throughput

Type: Number

Default: ’10’

MinValue: ‘5’

MaxValue: ‘10000’

ConstraintDescription: must be between 5 and 10000

Resources:

myDynamoDBTable:

Type: ‘AWS::DynamoDB::Table’

Properties:

AttributeDefinitions:

– AttributeName: !Ref HashKeyElementName

AttributeType: !Ref HashKeyElementType

KeySchema:

– AttributeName: !Ref HashKeyElementName

KeyType: HASH

ProvisionedThroughput:

ReadCapacityUnits: !Ref ReadCapacityUnits

WriteCapacityUnits: !Ref WriteCapacityUnits

Outputs:

TableName:

Value: !Ref myDynamoDBTable

Description: Table name of the newly created DynamoDB table

In order to allow for these resources to be built in AWS without providing the users direct access to the services, Products are given proper permissions to deploy the defined architecture.  This is done through what are called Service Catalog Launch Constraints, which work in concert with IAM policies and roles to assume the proper permissions on behalf of the users. First, a policy must be defined detailing the exact permissions needed to build the infrastructure that makes up the Product.  Once defined, the IAM Policy is assigned to an IAM Role. This IAM Role is then assigned to the Launch Constraint, allowing the Product to assume the IAM role and all its permissions in order to deploy the services on behalf of the user. Since IAM is a global service these Roles and Policies will only need to be defined once per AWS Account.

To ease the deployment of the AWS Service Catalog across multiple regions within your AWS account, AWS has created AWS CloudFormation Templates for the entire solution.  From a single CloudFormation stack, IT can deploy multiple AWS Service Catalog Portfolios across regions with Products created from their own AWS CloudFormation Templates along with all the necessary IAM Roles, Polices, and Groups.  An example of creating the Portfolio through CloudFormation is below:

Description: “This CF template creates the main Portfolio and outputs the PortfolioID.”

Resources:

MainPortfolio:

Type: “AWS::ServiceCatalog::Portfolio”

Properties:

AcceptLanguage: “en”

Description: “Main Portfolio.”

DisplayName: “Main Portfolio”

ProviderName: “Foghorn”

Outputs:

PortfolioID:

Value: !Ref MainPortfolio

 

The AWS Service Catalog is the perfect tool for allowing users within your organization the autonomy to create and destroy infrastructure and services at will without affecting the IT service pipeline while guaranteeing that a properly architected solution is deployed.  Contact the us at Foghorn to help you deploy this solution to help dynamically improve the speed and effectiveness of the cloud for all users in your organization.

how to adopt and manage cloud services

The Reinvention of Amazon Bedrock

The Reinvention of Amazon Bedrock

Amazon Bedrock is a sophisticated and fully managed service provided by AWS, designed to facilitate the development and scaling of generative AI applications. Some key improvements have been launched at AWS Re:Invent this week. We’ll dive deeper into those later....