Enforcing Standard Resources With Service Catalog at Scale with Least Privilege

Having defined new standards and begun remediation efforts, it becomes obvious when innovation begins to outpace governance. Teams start provisioning new resources with noncompliant configurations quicker than operations teams can remediate the discrepancies. It becomes a hole that grows exceedingly difficult to dig back out from under.

Config service provides an incredibly powerful function in remediating misconfigurations. The counter point is that there are billing considerations with highly scalable environments, as well as the need to develop remediation of the targeted misconfigurations. In more complex compliance checks, there may also be a need for Lambda compute to be developed and leveraged, also possibly impacting cost.

Service Catalog provides a path for moving from detecting and responding to preventatively addressing misconfigurations by providing consumers templates in the form of CloudFormation template that provide a baseline that meets governance requirements.

Previously, Service Catalog was lacking in the integration with Organizations. Currently, if used from the Organizations master account, Service Catalog can share the templates used for creating resources with the Organization or an OU within the Organization.

It would be great to see the ability to delegate administration as seen in the way the newly released Macie works. But since that is not currently the case, sharing portfolios is limited to other individual accounts. These portfolios contain products that are represented as CloudFormation templates. Just like normal, these templates can take in parameters to customize the resource being provisioned in a limited way.

Once deployed, a new decision is necessary. Now that users can create defined resources, should they have the permissions to create similar resources from other services directly? That is, if presented with an S3 bucket with logging and versioning enabled (as defined in a standard or policy) through the Service Catalog service, should the user still have the ability to create a new S3 bucket from the console or CLI directly via the S3 service?

Launch constraints can be applied to the newly shared Portfolios. Choosing to create a local role name launch constraint will require the accounts to have a role named as such built in the account prior to the launching of any products from Service Catalog. (There also seems to be a requirement for this role to exist in the Organization master account in this scenario, though it is not used in the solution after validation at the time of creating the constraint.)

The role should have a few default permissions to conduct the Service Catalog requests plus whatever least privileged permissions would be needed to complete the work required to build the resources contained in the CloudFormation.

Once the role is deployed and the portfolio shared from the Organization master, there is still a need for the association between the portfolio and the IAM entities in the account. This can be accomplished by deploying another CloudFormation with the AWS::ServiceCatalog::PortfolioPrinicipalAssociation resource. Where sharing with the Organization made the portfolio available to the account, the principal association makes it available to the IAM entities within the account. These are the entities that will be invoking the service which will use the role identified in the launch constraint to build the resources.

Once the constraint role has been deployed, the portfolio populated with products and shared to the Organization, and the portfolio has been associated with principals, users can be granted permissions to the Service Catalog service instead of the permissions needed to manage the resources directly. The decision should be made as to whether the users will be authenticating into a principal that has access to refer to the Service Catalog as a reference catalog for common resources or if the products will be prescriptively provided as an exclusive means of creation. If the latter is the direction decided upon, leaving the principal being logged into with the least of privileges that match the level of management needed for the resource post creation.