Update
Mike Pope has published a nice article about Granting Permission to Launch EC2 Instances with IAM Roles (PassRole Permission) on the AWS Security Blog, which explains the subject matter from an AWS point of view.
Initial Answer
Skaperen's answer is partially correct (+1), but slightly imprecise/misleading as follows (the explanation seems a bit too complex for a comment, hence this separate answer):
To launch an EC2 instance with an IAM role requires administrative access to the IAM facility.
This is correct as such and points towards the underlying problem, but the required administrative permissions are rather limited, so the following conclusion ...
Because IAM roles grant permissions, there is clearly a security issue to be addressed. You would not want IAM roles being a means to allow permission escalation.
... is a bit misleading, insofar the potential security issue can be properly addressed. The subject matter is addressed in Granting Applications that Run on Amazon EC2 Instances Access to AWS Resources:
You can use IAM roles to manage credentials for applications that run
on Amazon EC2 instances. When you use roles, you don't have to
distribute AWS credentials to Amazon EC2 instances. Instead, you can
create a role with the permissions that applications will need when
they run on Amazon EC2 and make calls to other AWS resources. When
developers launch an Amazon EC2 instance, they can specify the role
you created to associate with the instance. Applications that run on
the instance can then use the role credentials to sign requests.
Now, within the use case at hand the mentioned developers [that] launch an Amazon EC2 instance are in fact EC2 instances themselves, which appears to yield the catch 22 security issue Skaperen outlined. That's not really the case though as illustrated by the sample policy in section Permissions Required for Using Roles with Amazon EC2 :
{
"Version": "2012-10-17",
"Statement": [{
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"*"
},
{
"Effect":"Allow",
"Action":"iam:ListInstanceProfiles",
"Resource":"*"
},
{
"Effect":"Allow",
"Action":"ec2:*",
"Resource":"*"
}]
}
So iam:PassRole
is in fact the only IAM permission required, and while technically of administrative nature, this isn't that far reaching - of course, the sample policy above would still allow to escalate permissions by means of listing and in turn passing any available role, but this can be prevented by specifying only those roles that are desired/safe to pass for the use case at hand - this is outlined in section Restricting Which Roles Can Be Passed to Amazon EC2 Instances (Using PassRole):
You can use the PassRole permission to prevent users from passing a
role to Amazon EC2 that has more permissions than the user has already
been granted, and then running applications under the elevated
privileges for that role. In the role policy, allow the PassRole
action and specify a resource (such as
arn:aws:iam::111122223333:role/ec2Roles/*) to indicate that only a
specific role or set of roles can be passed to an Amazon EC2 instance.
The respective sample policy illustrates exactly matches the use case at hand, i.e. grants permission to launch an instance with a role by using the Amazon EC2 API:
{
"Version": "2012-10-17",
"Statement": [{
"Effect":"Allow",
"Action":"ec2:RunInstances",
"Resource":"*"
},
{
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::123456789012:role/Get-pics"
}]
}
Is there a way to do what I aim for, or is the full user list a prerequisite to be able to change your own credentials in the console?
I'm afraid the latter is the case, at least that has been my experience as well so far, see e.g. my related answer to IAM access to EC2 REST API?, where I explore 'IAM Credentials Self Management' - interestingly the Official Solution to Allow a user to manage his or her own security credentials quoted from the AWS documentation just two weeks ago has vanished there, which 'correlates' with my qualification (i.e. they might have realized this being only applicable via custom solutions using the API and thus confusing):
Please note that this solution still has usability flaws depending on how AWS resources are accessed by your users, i.e. via API, CLI, or the AWS Management Console (the latter requires additional permissions for example).
Accordingly, my Extended Variation includes iam:ListUsers
as well to gain a usable result. This is really unfortunate, because granting meanwhile fine grained access to AWS resources via the AWS Management Console is by far the easiest and most instructive way to empower new AWS users to explore on their own.
Best Answer
One way you could do this is make a new zone that's a subdomain of the main domain, like
stuff.example.com
and delegate the subdomain's NS to that secondary zone. Give them IAM privileges to that subdomain's zone and they'd be able to create subdomains likemy.stuff.example.com
. For records that you want to be first-class citizens, you couldCNAME
my.example.com
tomy.stuff.example.com
, which would functionally permit them to manage that subdomain without having full privileges.