Besides IAM Policies, some services use additional authorization mechanism. The services with their own authorization mechanism are:
SNS and SQS: A Topic Policy or Queue Policy can open a topic/queue to things like IAM User, IAM Role, AWS Account, or just all of us. This can be handy, but you should think twice before doing so. Most likely, you can use the assume role approach to achieve the same!
Glacier: Glacier comes with two types of policies, one to control access, and the other to control modification of archives. The latter is important if you have to enforce that data can not be changed for legal reasons.
IoT: As mentioned, IoT Things can authenticate, and the Policy determines what they can do in your AWS account.
Lambda: A Lambda Function can be opened for invocation by a Permission. This is needed if you want a “Cron” to trigger your Lambda because this “Cron” is AWS. So AWS needs permissions to invoke your function. Most likely, you can use the assume role approach to achieve the same!
S3: S3 is the king of alternative ways for authorization.
You can set ACLs on the bucket and object level to give read/write permissions. I recommend no using them. There is no simple way to change all ACLs on the object level. And it is very hard to reason if every object can have different permissions.
You can also use a Bucket Policy to give read/write permissions to your bucket/objects. This makes sense if your bucket is public and you ant to give read access to the world.
You can also generate pre-signed URLs to give temporary permissions to read or upload objects. This makes sense if you want users to directly upload files from their browser.
KMS: Key Policies are the primary way to control access to customer master keys (CMKs) in KMS. On top of that, you can use IAM policies to authorize. The second way to control access are Grants. With a Grant, you can allow another AWS principal (e.g. an AWS account) to use a CMK with some restrictions. You could also implement this with the Key policy, but grants are more flexible to control.
The only additional authorization mechanism iamy supports at the moment is S3 bucket policies. In the interests of making this more of an umbrella tool for AWS authorization, should we support more of these mechanisms?
From https://cloudonaut.io/aws-security-primer/
The only additional authorization mechanism
iamysupports at the moment is S3 bucket policies. In the interests of making this more of an umbrella tool for AWS authorization, should we support more of these mechanisms?