iam 3.3 roles spec

Table of Contents IAM Roles Launching an instance with a role Related Service Interfaces/Operations IAM Operations STS Operations EC2 Changes euca2ools Changes Discussion

IAM Roles

Roles allow for automatic provisioning of security tokens for use by instance-hosted applications. Using roles for instances, access keys and control the associated permissions (IAM profile).

Things to know about roles and their use from instances:

AWS access keys are automatically made available to running instances.
AWS access keys are rotated automatically multiple times a day. Keys are made available at least 5 minutes before the expiration of the previous set.
You can assign granular service permissions for applications running on an EC2 instance that make requests to other services in AWS.
Roles can be used with all Windows and Linux AMIs.
The instance metadata service is used to expose access keys to the instances.
Precautions to restrict instance metadata service should be taken on role-based instances which run services that might interact with the metadata service (e.g., HTTP proxies).

Launching an instance with a role

Create roles using the IAM APIs (See creating a role)
Launch an instance while specifying the role (See launching an instance with a role)
Use the metadata service from the instance to obtain the credentials (See using temporary security credentials)

```bash $ iam-rolecreate -r s3access -s ec2.amazonaws.com

$ iam-roleaddpolicy -r s3access -e Allow -a s3:\* -c \* -p s3star -o {"Version":"2008-10-17","Statement":[{"Effect":"Allow","Action":["s3:*"],"Resource":["*"]}]}

$ iam-instanceprofilecreate -s s3access -r s3access arn:aws:iam::111111111111:instance-profile/s3access ```

Related Service Interfaces/Operations

Impacted services/tools which need to add support are:
- EUARE
  - Role related operations
  - InstanceProfile related operations
- STS
  - AssumeRole
- EC2
  - running an instance with a profile
  - using the profile information to populate the instance metadata service credentials periodically
- euca2ools
  - run-instance support for -p, --iam-profile arn|name
    
    Type: String
    
    Default: None
    
    Example: arn:aws:iam::111111111111:instance-profile/s3access

IAM Operations

API Reference

STS Operations

API Reference
- AssumeRole

EC2 Changes

RunInstances
- IamInstanceProfile.Arn
  Amazon resource name (ARN) of the IAM Instance Profile (IIP) to associate with the instances. Type: String, Default: None
- IamInstanceProfile.Name
  The name of the IAM Instance Profile (IIP) to associate with the instances. Type: String Default: None

Instance Metadata Items
iam/info	Returns information about the last time the instance profile was updated, including the instance's LastUpdated date, InstanceProfileArn, and InstanceProfileId.	2012-06-01
iam/security-credentials/	Returns the name of the IAM role associated with the instance.	2012-06-01
iam/security-credentials/role-name	Where role-name is the name of the IAM role associated with the instance. Returns the temporary security credentials (AccessKeyId, SecretAccessKey, SessionToken, and Expiration) associated with the IAM role.	2012-06-01

euca2ools Changes

run-instance support for -p, --iam-profile arn|name
The IAM instance profile to associate with the launched instance(s). IAM instance profiles enable you to manage permissions for applications running on EC2. This is either the Amazon Resource Name (ARN) of the instance profile (e.g., arn:aws:iam::111111111111:instance-profile/s3access) or the name of the role (e.g., s3access).

Discussion

. Summary of IAM roles related changes needed:
1. . STS: AssumeRole operation implementation [2].
2. . EC2: RunInstance with an IamInstanceProfile [3].
3. . IAM: Role related operations [4].
4. . Instance Metadata: Obtaining, refreshing, and giving access to security tokens [5,6].
. Roles & AssumeRole subtleties
1. . Roles work by providing the policies for narrowing privileges in a way that RunInstance can obtain those policies and, subsequently and periodically, request AssumeRole's which have been restricted appropriately.
2. . Roles are not an authorizable entity in and of themselves -- the application of the role's policies is done through security tokens.
3. . The Policy argument can be used to specify the restriction of access to be only the resource of the specific ELB.
4. . Obtaining the tokens will necessarily happen on the EC2 service side (either in instance state management or instance metadata) and need to happen periodically.
5. . For the EC2 service to be able to apply the right narrowing Policy it has to be able to identify that policy which is defined by ELB (!!)
6. . To expose the appropriate Policy the information has to be passed across the RunInstance API.
7. . It follows that an IamInstanceProfile be used as it is the only appropriate field in the RunInstance request.
8. . The IamInstanceProfile has associated with it IamRoles which have associated the relevant Policys.
. EC2/Instance Metadata & IAM Roles
1. . Providing access to the credentials will involve periodically calling AssumeRole.
2. . To narrow the delegated privileges for the security tokens the right Policy has to be provided when calling AssumeRole.
3. . The only way to associate a Policy w/ an Instance is at RunInstance time -- indirectly by associating an IamInstanceProfile with the Instance.
4. . The IamInstanceProfile, subsequently, has an IamRole and that has a list of Policys. (NOTE: despite being a list, an InstanceProfile can only ever have a single role associated with it [7])
5. . Using the IamInstanceProfile information and its policies AssumeRole can be used to obtain appropriate credentials.
6. . Instance metadata: When credentials are demanded using http://169.254.169.254/latest/meta-data/iam/security-credentials/${iamProfile} two things are needed:
  1. . If no credentials are currently cached for the instance obtain new credentials.
  2. . If cached credentials are expired obtain new credentials.
7. . Note that persisting tokens is not indicated as they are ephemeral, caching for the timeout period is sufficient. For example Suppliers.memoizeWithExpiration( new TokenSupplier() {/**/}, timeOut, TimeUnit.MINUTES );
8. . The value for the timeout of tokens in this case is unspecified (anyone?) and should be a configurable value which is local to the EC2 service (as it would apply to all system run VMs).
. IAM Role related operations: Based on the above discussion it seems to me like we need the following operations:
1. . Obtaining the instance profile is necessary as the EC2 service must not hardcode ELB specific policy information:
  1. . EC2 uses GetInstanceProfile using the IamInstanceProfile given to RunInstances, yields the Role
  2. . EC2 uses ListRolePolicies for the above obtained Role
  3. . EC2 uses GetRolePolicy for each of the above obtained RolePolicies
2. . Creating the instance profile is needed as the IAM service must not hardcode ELB specific policy information:
  1. . ELB uses CreateRole for LB instances.
  2. . ELB uses PutRolePolicy to specify policy.
  3. . ELB uses CreateInstanceProfile for LB instances.
  4. . ELB uses AddRoleToInstanceProfile to associate role with instance profile.
3. . The related {List,Delete}Role, {List,Delete}InstanceProfile, {List,Delete}InstanceProfile are very desirable but not /necessary/ for functionality. They should still be planned as they would be essential to operator control.
. Separation of concerns between ownership and authorization ==> IAM Policies ==> AssumeRole
1. . Handling request authorization should not be done based on request origin (i.e., examples where we do this now are wrong and are not a precedent for anything)
2. . A uniform (system-wide) IAM policy evaluation mechanism is possible (not all policies can be evaluated before starting processing of the request operation; so IAM policy evaluation is still relevant and needed in operations)
3. . The ELB service is effectively a 3rd party which needs API access to act on behalf of some user w/in the restricted role of managing the LB instances.
4. . AssumeRole [8] makes it possible for ELB to manage LB instances using a role which is delegated from whatever owning account we wish (including possibly the user account that defined the logical ELB).
5. . In this way, the question of authorization (system-wide mechanism) is made distinct from LB instance ownership (ELB implementation specific)
6. . Also, ownership of the LB vms can be decided w/ a focus on the related considerations w/o being compromised.
. Ownership of the ELB instance: this is a multi-faceted question with many implications.
1. . Operator (cloud admin) access and control; admins need to be able to identify, operate on, manage, and account for LB vms.
2. . ELB-User resource accounting; resource usage by ELB vms should be accounted against the user who created the ELB.
3. . Multi-tenancy: for it to be possible then LB vms have to be managed in a cross-account fashion.
4. . Security Groups: management of the security groups for the LB vms varies in complexity and risk exposure.
. Options for LB vm ownership: I've tried to identify and discuss some of the options for LB vm ownership, please review, amend, comment.
1. . "eucalyptus" account owned: LB vms run under the "eucalyptus" system account
  1. . Direct cloud admin control of LB vms
  2. . Trivial to handle from authorization perspective
  3. . Compromises accountability
  4. . Compatible with multi-tenant LB vms
  5. . Security group management is co-mingled
2. . User account owned: LB vms are just instances running w/in the ELB owning account,
  1. . Would need policy filtering/restricting {Describe,Terminate}Instances operations for non-cloud-admin users.
  2. . Delegated cloud admin control of LB vms localized to user owning the ELB
  3. . Minor authorization work (AssumeRole) to switch to user when running LB vms
  4. . Direct accountability w/in the user account
  5. . Not suitable for multi-tenant LB vms
  6. . Security group management is localized; needs policy filtering/restricting {Describe,Delete}SecurityGroups
3. . Special ELB-only per-UserAccount-account owned: ELB would create a special account specific to the Account which created the ELB and use it to run LB vms.
  1. . Delegated cloud admin control of LB vms through an indirected account on a per-user
  2. . Special authorization work (AssumeRole)
  3. . One-to-one accountability between this account and the corresponding Account that created the ELB
  4. . Not suitable for multi-tenant LB vms
  5. . Security group management is localized; doesn't need special handling