Protecting Critical SNS Topics From Deletion

stops even all-powerful IAM admin users in their tracks

I run some SNS topics as a public service where anybody can subscribe their own AWS Lambda functions, SQS queues, and email addresses.

If one of these SNS topics were to be accidentally deleted, I could recreate it with the same name and ARN. However, all of the existing user subscriptions would be lost and I would not be able to restore them myself. Each of the hundreds of users would have to figure out what happened and re-subscribe the appropriate targets with the correct permissions.

I don’t want these SNS topics to be deleted. Ever.

AWS IAM "ReadOnlyAccess" Managed Policy Is Too Permissive (For Us)

taking away some read-only permissions that Amazon allows

Amazon has created an IAM Managed Policy named ReadOnlyAccess, which grants read-only access to active resources on most AWS services. At Campus Explorer, we depend on this convenient managed policy for our read-only roles.

However, our use of “read-only” doesn’t quite match up with the choices that Amazon made when creating this policy. This isn’t to say that Amazon is wrong, just that our concept of “read-only” differs slightly from Amazon’s.

The biggest difference is that we want our read-only roles to be able to see the architecture of our AWS systems and what resources are active, but we would prefer that the role not be able to read sensitive data from DynamoDB, S3, Kinesis, SQS queue messages, CloudFormation template parameters, and the like.

For example, third party services often ask for a ReadOnlyAccess role to allow them to analyze your AWS account and provide helpful tips on how to improve security or cost control. This sounds good, but do you really want them to be reading messages from Kinesis streams and SQS queues or downloading the contents of S3 objects?

AWS IAM "ReadOnlyAccess" Managed Policy Is Missing Features

adding in some read-only permissions that Amazon missed

Amazon has created a Managed Policy in IAM named ReadOnlyAccess, which grants read-only access to AWS resources and API calls that make no changes to the account. At Campus Explorer, we depend on this convenient managed policy for our read-only roles–though we add a few Deny statements as we don’t believe, for example, that pulling messages off of an SQS queue really belongs in a read-only role.

In theory, and mostly in practice, Amazon manages this managed policy so that we don’t have to keep up with all of the changing API calls from new services and new features in existing services.