When infrastructure teams embark on cloud automation projects, identifying the precise IAM permissions required for their resources often becomes a time-consuming challenge. Engineers frequently find themselves searching through extensive AWS documentation, experimenting with policies, or overprovisioning permissions to avoid blockers. What if there was a more structured approach to discovering exactly which permissions are needed for specific operations on AWS resources?

This blog post introduces a powerful yet often overlooked resource: CloudFormation resource schemas. These schemas provide detailed information about the permissions required for the common CRUD (Create, Read, Update, Delete) operations plus list functionality across AWS resources, offering a single source of truth that can benefit teams using either CloudFormation or Terraform through its AWSCC provider.

The Challenge of Permission Discovery

When automating infrastructure deployment and management, teams often face questions like:

  • What are even the permissions associated with a service or resource ?
  • Which exact permissions are needed to create this resource?
  • Are there different permission sets needed for listing versus reading individual resources?
  • How can we implement least-privilege access without the trial and error?

These questions become even more complex as organizations scale their AWS footprint and incorporate newer services with evolving permission models.

CloudFormation Resource Schemas: A Complementary Approach

AWS CloudFormation provides machine-readable schemas for all supported resource types. These schemas are publicly accessible and contain valuable metadata about resources, including their required permissions.The schemas are available at: https://cloudformation-schema.s3.us-west-2.amazonaws.com/ for every supported resource type.

Important Note: This approach is not meant to replace established security practices like using AWS IAM Access Analyzer for comprehensive policy validation and refinement. Rather, it provides a useful starting point to avoid beginning with overly permissive policies like AdministratorAccess. Consider this method as one tool in your broader security toolkit.

Practical Example: Discovering IAM Permissions for Amazon S3 Bucket

Let's walk through the process of identifying required permissions for Amazon S3 bucket operations:

Step 1: Locate the Resource Schema

First, we need to find the schema for S3 buckets. CloudFormation resource types follow a pattern of AWS::Service::Resource. For S3 buckets, we're looking for AWS::S3::Bucket.

The schema URL would be https://cloudformation-schema.s3.us-west-2.amazonaws.com/resourcetype/AWS-S3-Bucket.json

Step 2: Examine the Permissions Section

After downloading the schema, look for the handlers section, which contains information about permissions required for different operations:

"handlers": {
  "create": {
    "permissions": [
      "s3:CreateBucket",
      "s3:PutBucketTagging",
      "s3:PutBucketPolicy",
      "s3:PutBucketVersioning",
      "s3:PutBucketAcl",
      "s3:PutBucketLogging",
      ...
    ]
  },
  "read": {
    "permissions": [
      "s3:GetBucketAcl",
      "s3:GetBucketLocation",
      "s3:GetBucketPolicy",
      "s3:GetBucketTagging",
      "s3:GetBucketVersioning",
      ...
    ]
  },
  "update": {
    "permissions": [
      "s3:PutBucketAcl",
      "s3:PutBucketPolicy",
      "s3:PutBucketVersioning",
      "s3:PutBucketTagging",
      ...
    ]
  },
  "delete": {
    "permissions": [
      "s3:DeleteBucket",
      "s3:DeleteBucketPolicy",
      ...
    ]
  },
  "list": {
    "permissions": [
      "s3:ListAllMyBuckets"
    ]
  }
}

Step 3: Build Your IAM Policy

Based on the operations your automation needs to perform, you can now craft a precise IAM policy with only the necessary permissions. For example, if your automation only needs to create and read S3 buckets, you would include just the permissions from the "create" and "read" handlers. Keep in mind that some of the S3 permissions currently includes the S3tables permissions which you may not need.

Example: AWS QBusiness Application Permissions

Let's look at the newer AWS QBusiness service:

Step 1: Find the Schema

The schema URL for QBusiness applications would be https://cloudformation-schema.s3.us-west-2.amazonaws.com/resourcetype/aws-qbusiness-application.json

Step 2: Extract the Required Permissions

The schema would contain permissions like:

"handlers": {
  "create": {
    "permissions": [
      "qbusiness:CreateApplication",
      "qbusiness:TagResource",
      "iam:PassRole"
    ]
  },
  "read": {
    "permissions": [
      "qbusiness:GetApplication",
      "qbusiness:ListTagsForResource"
    ]
  },
  "update": {
    "permissions": [
      "qbusiness:UpdateApplication",
      "qbusiness:TagResource",
      "qbusiness:UntagResource",
      "iam:PassRole"
    ]
  },
  "delete": {
    "permissions": [
      "qbusiness:DeleteApplication"
    ]
  },
  "list": {
    "permissions": [
      "qbusiness:ListApplications"
    ]
  }
}

Notice how the iam:PassRole permission appears in both create and update operations—this is a critical permission that might be easily overlooked when manually researching required permissions.

Benefits for Terraform Users

Terraform users utilizing AWSCC provider could benefit easily as they map to similar CloudFormation resources. That being said, the knowledge of required permissions applies to any script/IAC tooling your team might use to provision the infrastructure.

For example, when using:

resource "awscc_s3_bucket" "example" {
  bucket_name = "my-example-bucket"
  # other properties
}

The permissions required would match those in the CloudFormation schema for the create, read, update, and delete operations.

Sample script to do this

While I was writing this, I wanted to extend this by creating a simple script for my own usage as look to review permissions on a daily basis. This does require you to know the current CloudFormation resource type .

This script:

  1. Creates a CloudFormationPermissionsExtractorclass to handle the permission extraction logic class to handle the permission extraction logic
  2. Fetches the schema for the specified resource type
  3. Extracts permissions based on the operation type (if specified)
  4. Displays the results in a formatted way

To use the script:

  1. Install the required packages: 
pip install requests

Example usage:

Enter CloudFormation resource type (e.g., AWS::S3::Bucket): AWS::S3::Bucket

Available operations: create, read, update, delete, list
Press Enter to see all permissions
Enter operation type (optional): create

The script output will then display the required permissions for creating an S3 bucket through CloudFormation.
Remember to handle the response appropriately as different resource types may have different permission structures in their schemas.

Best Practices for Using Resource Schemas

  1. Keep permissions scoped: Only include permissions for the operations your code actually performs.
  2. Verify through testing: While schemas are comprehensive, always verify with real-world testing.
  3. Automate policy generation: Consider automating the extraction of permissions from schemas for your CI/CD pipelines.
  4. Stay current: Resource schemas are updated as AWS services evolve, so check for updates periodically.

Integrating with Existing Security Practices

This schema-based approach works best as part of a comprehensive security strategy:

  1. Start with schema-derived permissions for initial deployment
  2. Use AWS IAM Access Analyzer to identify unused permissions
  3. Implement continuous policy refinement based on actual usage patterns
  4. Maintain regular security reviews of all IAM policies

Conclusion

CloudFormation resource schemas provide a valuable source of information about required IAM permissions that can significantly streamline your infrastructure automation efforts. By leveraging these schemas, teams can:

  • Implement least-privilege access more easily
  • Reduce troubleshooting time related to permission issues
  • Stay up-to-date with permission requirements as AWS services evolve
  • Apply consistent permission sets across both your IAC workflows

Next time your team is setting up IAM permissions for a new AWS resource, consider checking the CloudFormation schema firstit could save hours of research and experimentation while improving your security posture through more precise permission definitions.