Manage Users and Groups

• 1: Access Overview
• 1.1: Access Concepts
• 1.1.1: User Identities
• 1.1.2: Special Identities
• 1.1.3: Credentials
• 1.1.4: Account Creation
• 1.1.5: Special User Attributes
• 1.1.6: Roles
• 1.2: Policy Overview
• 1.2.1: Default Permissions
• 1.2.2: Quotas
• 1.2.3: Algorithms
• 1.2.4: Sample Policies
• 2: Access Tasks
• 2.1: Use Case: Create an Administrator
• 2.2: Use Case: Create a User
• 2.3: Accounts
• 2.3.1: Add an Account
• 2.3.2: Rename an Account
• 2.3.3: List Accounts
• 2.3.4: Delete an Account
• 2.4: Groups
• 2.4.1: Create a Group
• 2.4.2: Add a Group Policy
• 2.4.3: Modify a Group
• 2.4.4: Remove a User from a Group
• 2.4.5: List Groups
• 2.4.6: List Policies for a Group
• 2.4.7: Delete a Group
• 2.5: Users
• 2.5.1: Add a User
• 2.5.2: Add a User to a Group
• 2.5.3: Create a Login Profile
• 2.5.4: Generating User Credentials
• 2.5.5: Uploading a Certificate
• 2.5.6: Modify a User
• 2.5.7: List Users
• 2.5.8: Delete a User
• 2.6: Roles
• 2.6.1: Launch an Instance with a Role
• 2.6.2: Use a Role with an Instance Application
• 2.6.3: Assume a Role
• 2.6.4: Delegate Access Across Your Accounts Using Roles

1 - Access Overview

Access Overview

The Eucalyptus design of user identity and access management provides layers in the organization of user identities. This gives you refined control over resource access. Though compatible with the AWS IAM, there are also a few Eucalyptus-specific extensions.

1.1 - Access Concepts

Access Concepts

This section describes what Eucalyptus access is and what you need to know about it so that you can configure access to your cloud.

1.1.1 - User Identities

In Eucalyptus, user identities are organized into accounts. An account is the unit of resource usage accounting, and also a separate namespace for many resources (security groups, key pairs, users, etc.).Accounts are identified by either a unique ID (UUID) or a unique name. The account name is like IAM’s account alias. It is used to manipulate accounts. However, for AWS compatibility, the EC2 commands often use account ID to display resource ownership.

There are command line tools to discover the correspondence of account ID and account name. For example, euare-accountlist lists all the accounts with both their IDs and names.

An account can have multiple users, but a user can only be in one account. Within an account, users can be associated with Groups. Group is used to attach access permissions to multiple users. A user can be associated with multiple groups. Because an account is a separate name space, user names and group names have to be unique only within an account. Therefore, user X in account A and user X in account B are two different identities.

Both users and groups are identified by their names, which are unique within an account (they also have UUIDs, but are rarely used).

1.1.2 - Special Identities

Eucalyptus has two special identities for the convenience of administration and use of the system.

• The account: Each user in the eucalyptus account has unrestricted access to all of the cloud’s resources, similar to the superuser on a typical Linux system. These users are often referred to as system administrators or cloud administrators. This account is automatically created when the system starts for the first time. You cannot remove the eucalyptus account from the system.
• The user of an account: Each account, including the eucalyptus account, has a user named admin. This user is created automatically by the system when an account is created. The admin of an account has full access to the resources owned by the account. You can not remove the admin user from an account. The admin can delegate resource access to other users in the account by using policies.

1.1.3 - Credentials

This topic describes the different types of credentials used by Eucalyptus.Each user has a unique set of credentials. These credentials are used to authenticate access to resources. There are three types of credentials:

• An is used to authenticate requests to the SOAP API service.
• A is used to authenticate requests to the REST API service. You can manage credentials using the command line tools (the euare- commands).

In IAM, each account has its own credentials. In Eucalyptus, the equivalent of account credentials are the credentials of admin user of the account.

1.1.4 - Account Creation

This topic describes the process for creating an account using the command line tool.You must be a cloud administrator to use this command. Accounts created are available for immediate access.

To create an account, run the following command:

euare-accountcreate -a account_name

When an account is created by euare-accountcreate command, an “admin” user is created by default.

1.1.5 - Special User Attributes

Eucalyptus extends the IAM model by providing the following extra attributes for a user.

• This is only meaningful for the account administrator (that is, the account level).
• . Use this attribute to temporarily disable a user.
• Add any name-value pair to a user’s custom information attribute. This is useful for attaching pure text information, like an address, phone number, or department. You can retrieve and modify the registration status, enabled status, and password expiration date using the euare-usergetattributes and euare-usermod commands. You can retrieve and modify custom information using euare-usergetinfo and euare-userupdateinfo commands.

1.1.6 - Roles

A role A role is a mechanism that enables the delegation of access to users or applications.

A role is associated with an account, and has a set of permissions associated with it that are defined in the form of an IAM policy . A policy specifies a set of actions and resources within that account that the role is allowed to access.

By assuming a role, a user or an applications gets a set of permissions associated with that role. When a role is assumed, the Eucalyptus STS service returns a set of temporary security credentials that can then be used to make programmatic requests to resources in your account. This eliminates the need to share or hardcode security credentials with applications that need access to resources in your cloud.

Eucalyptus roles are managed through the Eucalyptus Euare service, which is compatible with Amazon’s Identity and Access Management service. For more information on IAM and roles, please see the Amazon IAM User Guide .

Usage Scenarios for Roles

There are several scenarios in which roles can be useful, including:

Applications

Applications running on instances in your Eucalyptus cloud will often need access to other resources in your cloud. Instead of creating AWS credentials for each application, or distributing your own credentials,, you can use roles to enable you to delegate permission to the application to make API requests. For more information, see Launch an Instance with a Role .

Account Delegation

You can use roles to allow one account to access resources owned by another account. IAM Roles under the ’eucalyptus’ account can be assumed by users under ’non-eucalyptus’ account(s). For example, if you had an ‘infrastructure auditing’ account, and an audit was needed to be performed on all the cloud resources used on the cloud, a user could assume the ‘Resource Administrator’ role and audit all the resources used by all the accounts on the cloud. For more information on IAM account delegation, see Using Roles to Delegate Permissions and Federate Identities . Also, go to the walkthrough provided in the AWS Identity and Access Management section of the AWS documentation.

Pre-Defined Roles

Eucalyptus offers a number of pre-defined privileged roles. These roles are associated with the eucalyptus account, and have privileges to manage resources across the cloud and non-privileged accounts. Only the eucalyptus account can manage or modify these roles.

To see the pre-defined roles, use euare-rolelistbypath with the credentials of a user that is part of the eucalyptus account. For example:

# euare-rolelistbypath 
arn:aws:iam::944786667073:role/eucalyptus/AccountAdministrator
arn:aws:iam::944786667073:role/eucalyptus/InfrastructureAdministrator
arn:aws:iam::944786667073:role/eucalyptus/ResourceAdministrator

Account Administrator

The Account Administrator (AA) can manage Eucalyptus accounts. To view the policy associated with the Account Administrator role, use euare-rolelistpolicies with the credentials of a user that is part of the eucalyptus account. For example:

# euare-rolelistpolicies --role-name AccountAdministrator --verbose
AccountAdministrator
{
  "Statement":[ {
    "Effect": "Allow",
    "Action": [
      "iam:*"
    ],
    "NotResource": "arn:aws:iam::eucalyptus:*",
    "Condition": {
      "Bool": { "iam:SystemAccount": "false" }
    }
  } ]
}
IsTruncated: false

Resource Administrator

The Resource Administrator (RA) can manage AWS-defined resources (such as S3 objects, instances, users, etc) across accounts. To view the policy associated with the Resource Administrator role, use euare-rolelistpolicies with the credentials of a user that is part of the eucalyptus account. For example:

# euare-rolelistpolicies --role-name ResourceAdministrator --verbose
ResourceAdministrator
{
  "Statement":[ {
    "Effect": "Allow",
    "Action": [
      "autoscaling:*",
      "cloudwatch:*",
      "ec2:DescribeInstanceAttribute",
      "ec2:DescribeInstances",
      "ec2:DescribeInstanceStatus",
      "ec2:DescribeInstanceTypes",
      "ec2:GetConsoleOutput",
      "ec2:GetPasswordData",
      "ec2:ImportInstance",
      "ec2:ModifyInstanceAttribute",
      "ec2:MonitorInstances",
      "ec2:RebootInstances",
      "ec2:ReportInstanceStatus",
      "ec2:ResetInstanceAttribute",
      "ec2:RunInstances",
      "ec2:StartInstances",
      "ec2:StopInstances",
      "ec2:TerminateInstances",
      "ec2:UnmonitorInstances",
      "ec2:*AccountAttributes*",
      "ec2:*Address*",
      "ec2:*AvailabilityZones*",
      "ec2:*Bundle*",
      "ec2:*ConversionTask*",
      "ec2:*CustomerGateway*",
      "ec2:*DhcpOptions*",
      "ec2:*ExportTask*",
      "ec2:*Image*",
      "ec2:*InternetGateway*",
      "ec2:*KeyPair*",
      "ec2:*NetworkAcl*",
      "ec2:*NetworkInterface*",
      "ec2:*PlacementGroup*",
      "ec2:*ProductInstance*",
      "ec2:*Region*",
      "ec2:*ReservedInstance*",
      "ec2:*Route*",
      "ec2:*SecurityGroup*",
      "ec2:*Snapshot*",
      "ec2:*SpotDatafeedSubscription*",
      "ec2:*SpotInstance*",
      "ec2:*SpotPrice*",
      "ec2:*Subnet*",
      "ec2:*Tag*",
      "ec2:*Volume*",
      "ec2:*Vpc*",
      "ec2:*Vpn*",
      "ec2:*VpnGateway*",
      "elasticloadbalancing:*",
      "s3:*"
    ],
    "Resource": "*"
  }, {
    "Effect": "Allow",
    "Action": [
      "iam:Get*",
      "iam:List*"
    ],
    "NotResource": "arn:aws:iam::eucalyptus:*"
  } ]
}
IsTruncated: false

Infrastructure Administrator

The Infrastructre Administrator (IA) can perform operations related to cloud setup and management. Typical responibilities include:

• Installation and configuration (prepare environment, install Eucalyptus, configure Eucalyptus)

• Monitoring and maintenance (infrastructure supporting the cloud, cloud management layer, upgrades, security patches, diagnostics and troubleshooting)

• Backup and restoration To view the policy associated with the Infrastructure Administrator role, use euare-rolelistpolicies with the credentials of a user that is part of the eucalyptus account. For example:

  euare-rolelistpolicies –role-name InfrastructureAdministrator –verbose

  InfrastructureAdministrator { “Statement”:[ { “Effect”: “Allow”, “Action”: [ “euprop:”, “euserv:”, “euconfig:”, “ec2:MigrateInstances” ], “Resource”: “” } ] } IsTruncated: false

1.2 - Policy Overview

Policy Overview

Eucalyptus uses the policy language to specify user level permissions as AWS IAM. Policies are written in JSON. Each policy file can contain multiple statements, each specifying a permission.A permission statement specifies whether to allow or deny a list of actions to be performed on a list of resources, under specific conditions.

A permission statement has the following components:

• Begins the decision that applies to all following components. Either: or
• Indicates service-specific and case-sensitive commands. For example:
• Indicates selected resources, each specified as an Amazon resource name (ARN). For example:
• Indicates additional constraints of the permission. For example:

The following policy example contains a statement that gives a user with full permission. This is the same access as the account administrator:

{
  "Version":"2011-04-01",
 	"Statement":[{
 	  "Sid":"1",
 	  "Effect":"Allow",
 	  "Action":"*",
 	  "Resource":"*"
 	}]
}

For more information about policy language, go to the IAM User Guide .

Policy Notes

You can combine IAM policies with account level permissions. For example, the admin of account A can give users in account B permission to launch one of account A’s images by changing the image attributes. Then the admin of account B can use IAM policy to designate the users who can actually use the shared images.

You can attach IAM policies to both users and groups. When attached to groups, a policy is equivalent to attaching the same policy to the users within that group. Therefore, a user might have multiple policies attached, both policies attached to the user, and policies attached to the group that the user belongs to.

Do not attach IAM policies (except quota policies, a Eucalyptus extension) to account admins. At this point, doing so won’t result in a failure but may have unexpected consequences.

1.2.1 - Default Permissions

Different identities have different default access permissions. When no policy is associated with them, these identities have the permission listed in the following table.

1.2.2 - Quotas

Eucalyptus adds quota enforcement to resource usage. To avoid introducing another configuration language into Eucalyptus, and simplify the management, we extend the IAM policy language to support quotas.The only addition added to the language is the new limit effect. If a policy statement’s effect is limit , it is a quota statement.

A quota statement also has action and resource fields. You can use these fields to match specific requests, for example, quota only being checked on matched requests. The actual quota type and value are specified using special quota keys, and listed in the condition part of the statement. Only condition type NumericLessThanEquals can be used with quota keys.

{
 "Version":"2011-04-01",
 "Statement":[{
   "Sid":"4",
   "Effect":"Limit",
   "Action":"ec2:RunInstances",
   "Resource":"*",
   "Condition":{
     “NumericLessThanEquals”:{
       “ec2:quota-vminstancenumber”:”16”
     }
   }
 }]
}

You can attach quotas to both users and accounts, although some of the quotas only apply to accounts. Quota attached to groups will take no effect.

When a quota policy is attached to an account, it actually is attached to the account administrator user. Since only system administrator can specify account quotas, the account administrator can only inspect quotas but can’t change the quotas attached to herself.

The following is all the quota keys implemented in Eucalyptus:

Default Quota

Contrary to IAM policies, by default, there is no quota limits (except the hard system limit) on any resource allocations for a user or an account. Also, system administrators are not constrained by any quota. Account administrators are only be constrained by account quota.

1.2.3 - Algorithms

This topic describes the algorithms used by Eucalyptus to determine access.

Policy Evaluation Algorithm

You can associated multiple policies and permission statements with a user. The way these are combined together to control the access to resources in an account is defined by the policy evaluation algorithm. Eucalyptus implements the same policy evaluation algorithm as AWS IAM :

1. If the request user is account admin, access is allowed.
2. Otherwise, collect all the policy statements associated with the request user (attached to the user and all the groups the user belongs to), which match the incoming request (i.e. based on the API being invoked and the resources it is going to access).

Access Evaluation Algorithm

Now we give the overall access evaluation combining both account level permissions and IAM permissions, which decides whether a request is accepted by Eucalyptus:

1. If the request user is sys admin, access is allowed.
2. Otherwise, check account level permissions, e.g. image launch permission, to see if the request user’s account has access to the specific resources.

Quota Evaluation Algorithm

Like the normal IAM policies, a user may be associated with multiple quota policies (and multiple quota statements). How all the quota policies are combined to take effect is defined by the quota evaluation algorithm:

1. If the request user is sys admin, there is no limit on resource usage.
2. Otherwise, collect all the quotas associated with the request user, including those attached to the request user’s account and those attached to the request user himself/herself (for account admin, we only need collect account quotas).
3. Evaluate each quota one by one. Reject the request as long as there is one quota being exceeded by the request. Otherwise, accept the request.

1.2.4 - Sample Policies

A few example use cases and associated policies.Here are some example use cases and associated polices. You can edit these polices for your use, or use them as examples of JSON syntax and form.

Examples: Allowing Specific Actions

The following policy allows a user to only run instances and describe things.

{
   "Statement":[{
      "Effect":"Allow",
      "Action":["ec2:*Describe*",​"ec2:*Run*"],
      "Resource":"*",
      }
   ]
   }

The following policy allows a user to only list things:

{
  "Statement": [
    {
      "Sid": "Stmt1313686153864",
      "Action": [
        "iam:List*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
  }

The following policy grants a generic basic user permission for running instances and describing things.

{
  "Statement": [
    {
      "Sid": "Stmt1313605116084",
      "Action": [
        "ec2:AllocateAddress",
        "ec2:AssociateAddress",
        "ec2:AttachVolume",
        "ec2:Authorize*",
        "ec2:CreateKeyPair",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSnapshot",
        "ec2:CreateVolume",
        "ec2:DeleteKeyPair",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSnapshot",
        "ec2:DeleteVolume",
        "ec2:Describe*",
        "ec2:DetachVolume",
        "ec2:DisassociateAddress",
        "ec2:GetConsoleOutput",
        "ec2:RunInstances",
        "ec2:TerminateInstances"
        "ec2:ReleaseAddress"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Examples: Denying Specific Actions

The following policy allows a user to do anything but delete.

{
  "Statement": [
    {
      "Action": [
        "ec2:Delete*"
      ],
      "Effect": "Deny",
      "Resource": "*"
    }
  ]
  }

The following policy denies a user from creating other users.

{
  "Statement": [
    {
      "Sid": "Stmt1313686153864",
      "Action": [
        "iam:CreateUser"
      ],
      "Effect": "Deny",
      "Resource": "*"
    }
  ]
}

Examples: Specifying Time Limits

The following policy allows a user to run instances within a specific time.

{
  "Statement": [
    {
      "Sid": "Stmt1313453084396",
      "Action": [
        "ec2:RunInstances"
      ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "DateLessThanEquals": {
          "aws:CurrentTime": "2011-08-16T00:00:00Z"
        }
      }
    }
  ]
}

The following policy blocks users from running instances at a specific time.

{
  "Statement": [
    {
      "Sid": "Stmt1313453084396",
      "Action": [
        "ec2:RunInstances"
      ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "DateLessThanEquals": {
          "aws:CurrentTime": "2011-08-16T00:00:00Z"
        }
      }
    }
  ]
  }

The following policy keeps alive an instance for 1,000 hours (60,000 minutes).

{
  "Statement": [
    {
      "Action": ["ec2:RunInstances" ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": { "NumericEquals":{"ec2:KeepAlive":"60000"}}
    }
  ]
  }

The following policy sets an expiration date on running instances.

{
  "Statement": [
    {
      "Action": ["ec2:RunInstances" ],
      "Effect": "Allow",
      "Resource": "*",
      "Condition": { "DateEquals":{"ec2:ExpirationTime":"2011-08-16T00:00:00Z"}}
    }
  ]
}

Examples: Restricting Resources

The following policy allows users to only launch instances with a large image type.

{
  "Statement": [
    {
      "Action": [
        "ec2:RunInstances"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:ec2:::vmtype/m1.xlarge"
    }
  ]
  }

The following policy restricts users from launching instances with a specific image ID.

{
  "Statement": [
    {
      "Action": [
        "ec2:RunInstances"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:ec2:::image/emi-0FFF1874"
    }
  ]
  }

The following policy restricts users from allocating addresses to a specific elastic IP address.

{
  "Statement": [
    {
      "Sid": "Stmt1313626078249",
      "Action": "*",
      "Effect": "Deny",
      "Resource": "arn:aws:ec2:::address/192.168.10.140"
    }
  ]
  }

The following policy denies volume access.

{
  "Statement": [
    {
      "Action": [
        "ec2:*"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:ec2:::volume/*"
    }
  ]
   
}

2 - Access Tasks

Access Tasks

This section provides details about the tasks you perform using policies and identities. The tasks you can perform are divided up into tasks for users, tasks for groups, and tasks for policies.

2.1 - Use Case: Create an Administrator

This use case details tasks for creating an administrator. These tasks require that you have your account credentials for sending requests to Eucalyptus using the command line interface (CLI) tools. To create an administrator account, perform the following tasks.

Create an Admin Group

Eucalyptus recommends using account credentials as little as possible. You can avoid using account credentials by creating a group of users with administrative privileges.

Create a group called administrators.

euare-groupcreate -g administrators

Verify that the group was created.

euare-grouplistbypath

Eucalyptus returns a listing of the groups that have been created, as in the following example.

arn:aws:iam::123456789012:group/administrators

Add a Policy to the Group

Add a policy to the administrators group that allows its members to perform all actions in Eucalyptus.

Enter the following command to create a policy called admin-root that grants all actions on all resources to all users in the administrators group:

euare-groupaddpolicy -p admin-root -g administrators -e Allow -a "*" -r "*" -o

Create an Administrative User

Create a user for day-to-day administrative work and add that user to the administrators group.

Eucalyptus admin tools and Euca2ools commands need configuration from ~/.euca . If the directory does not yet exist, create it:

mkdir ~/.euca

Create an administrative user, for example alice and create it along with an access key:

euare-usercreate -wd DOMAIN USER >~/.euca/FILE.ini

where:

• means output access keys and region information in a euca2ools.ini type configuration file.

• DOMAIN is the DNS domain to use for region information in configuration file output (default: based on IAM URL).

• USER is the name of the new admin user: alice.

• FILE can be anything; we recommend a descriptive name that includes the user’s name; for example:

  euare-usercreate -wd DNS_DOMAIN alice >~/.euca/alice.ini

This creates a user admin file with a region name that matches that of your cloud’s DNS domain.

Add the new admin user to the administrators group.

euare-groupadduser -u alice administrators

To list the new user’s access keys:

euare-userlistkeys --region alice@DNS_DOMAIN

2.2 - Use Case: Create a User

This use case details tasks needed to create a user with limited access.

Create a Group

We recommend that you apply permissions to groups, not users. In this example, we will create a group for users with limited access.

Enter the following command to create a group for users who will be allowed create snapshots of volumes in Eucalyptus.

euare-groupcreate -g ebs-backup

Open an editor and enter the following JSON policy:

{
  "Statement": [
    {
      "Action": [
        "ec2:CreateSnapshot"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Save and close the file. Enter the following to add the new policy name allow-snapshot and the JSON policy file to the ebs-backup group:

euare-groupuploadpolicy -g ebs-backup -p allow-snapshot -f allow-snapshot.json

Create the User

Create the user for the group with limited access.

Enter the following command to create the user sam in the group ebs-backup and generate a new key pair for the user:

euare-usercreate -u sam -g ebs-backup -k

Eucalyptus responds with the access key ID and the secret key, as in the following example:

AKIAJ25S6IJ5K53Y5GCA
QLKyiCpfjWAvlo9pWqWCbuGB9L3T61w7nYYF057l

2.3 - Accounts

Accounts

Accounts are the primary unit for resource usage accounting. Each account is a separate name space and is identified by its account number (fixed) and account alias/name (modifiable). Tasks performed at the account level can only be done by the users in the eucalyptus account.

2.3.1 - Add an Account

To add an account perform the steps listed in this topic.To add a new account:

Enter the following command:

euare-accountcreate -a <account_name>

Eucalyptus returns the account name and its ID, as in this example:

account01 	592459037010

2.3.2 - Rename an Account

To rename an account perform the steps listed in this topic.To change an account’s name:

Enter the following command:

uare-accountaliascreate -a <new_name>

2.3.3 - List Accounts

To list accounts perform the steps in this topic.Use the euare-accountlist command to list all the accounts in an account or to list all the users with a particular path prefix. The output lists the ARN for each resulting user.

euare-userlistbypath -p <path>

2.3.4 - Delete an Account

To delete an account perform the steps listed in this topic.

euare-accountdel -a <account_name> -r true

Use the -r option set to true to delete the account recursively. You don’t have to use this option if have already deleted users, keys, and passwords in this account.

Eucalyptus does not return any message.

2.4 - Groups

Groups

Groups are used to share resource access authorizations among a set of users within an account. Users can belong to multiple groups.

This section details tasks that can be performed on groups.

2.4.1 - Create a Group

To create a group perform the steps listed in this topic.Enter the following command:

euare-groupcreate -g <group_name>

Eucalyptus does not return anything.

2.4.2 - Add a Group Policy

To add a group policy perform the steps listed in this topic.Enter the following command:

euare-groupaddpolicy -g <group_name> -p <policy_name> -e <effect> -a
							<actions> -o

The optional -o parameter tells Eucalyptus to return the JSON policy, as in this example:

{"Version":"2008-10-17","Statement":[{"Effect":"Allow", "Action":["ec2:RunInstances"], "Resource":["*"]}]}

2.4.3 - Modify a Group

To modify a group perform the steps listed in this topic.Modifying a group is similar to a “move” operation. Whoever wants to modify the group must have permission to do it on both sides of the move. That is, you need permission to remove the group from its current path or name, and put that group in the new path or name.

For example, if a group changes from one area in a company to another, you can change the group’s path from /area_abc/ to /area_efg/ . You need permission to remove the group from /area_abc/ . You also need permission to put the group into /area_efg/ . This means you need permission to call UpdateGroup on both arn:aws:iam::123456789012:group/area_abc/* and arn:aws:iam::123456789012:group/area_efg/* .

Enter the following command to modify the group’s name:

euare-groupmod -g <group_name> --new-group-name <new_name>

Eucalyptus does not return a message. Enter the following command to modify a group’s path:

euare-groupmod -g <group_name> -p <new_path>

Eucalyptus does not return a message.

2.4.4 - Remove a User from a Group

To remove a user from a group perform the steps listed in this topic.Enter the following command:

euare-groupremoveuser -g <group_name> -u <user-name> 

2.4.5 - List Groups

To list groups perform the steps listed in this topic.Enter the following command:

euare-grouplistbypath

Eucalyptus returns a list of paths followed by the ARNs for the groups in each path. For example:

arn:aws:iam::eucalyptus:group/groupa

2.4.6 - List Policies for a Group

To list policies for a group perform the steps listed in this topic.Enter the following command:

euare-grouplistpolicies -g <group_name>

Eucalyptus returns a listing of all policies associated with the group.

2.4.7 - Delete a Group

To delete a group perform the steps listed in this topic.When you delete a group, you have to remove users from the group and delete any policies from the group. You can do this with one command, using the euare-groupdel command with the -r option. Or you can follow the following steps to specify who and what you want to delete.

Individually remove all users from the group.

euare-groupremoveuser -g <group_name> -u <user_name>

Delete the policies attached to the group.

euare-groupdelpolicy -g <group_name> -p <policy_name>

Delete the group.

euare-groupdel -g <group_name>

The group is now deleted.

2.5 - Users

Users

Users are subsets of accounts and are added to accounts by an appropriately credentialed administrator. While the term user typically refers to a specific person, in Eucalyptus, a user is defined by a specific set of credentials generated to enable access to a given account. Each set of user credentials is valid for accessing only the account for which they were created. Thus a user only has access to one account within a Eucalyptus system. If an individual person wishes to have access to more than one account within a Eucalyptus system, a separate set of credentials must be generated (in effect a new ‘user’) for each account (though the same username and password can be used for different accounts).

When you need to add a new user to your Eucalyptus cloud, you’ll go through the following process:

1. Create a user
2. Add user to a group
3. Give user a login profile

2.5.1 - Add a User

To add a user, perform the steps in this topic.Enter the following command

euare-usercreate -u <user_name> -g <group_name> -k

Eucalyptus does not return a response.

2.5.2 - Add a User to a Group

To add a user to a group perform the steps listed in this topic.Enter the following command:

euare-groupadduser -g <group_name> -u <user-name> 

2.5.3 - Create a Login Profile

To create a login profile, perform the tasks in this topic.Enter the following command:

euare-useraddloginprofile -u <user_name> -p <password>

Eucalyptus does not return a response.

2.5.4 - Generating User Credentials

The first time you get credentials using the clcadmin-assume-system-credentials command, a new secret access key is generated. On each subsequent request to get credentials, an existing active secret key is returned. You can also generate new keys using the euare-useraddkey command.

To generate a new key for a user by an account administrator, enter the following

euare-useraddkey USER_NAME

To generate a private key and an X.509 certificate pair, enter the following:

euare-usercreatecert USER_NAME

The cloud administrator can obtain temporary access credentials for any cloud user via the clcadmin-impersonate-user command.

2.5.5 - Uploading a Certificate

To upload a certificate provided by a user:

Enter the following command:

euare-useraddcert -f CERT_FILE USER_NAME

2.5.6 - Modify a User

Modifying a user is similar to a “move” operation. To modify a user, you need permission to remove the user from the current path or name, and put that user in the new path or name.For example, if a user changes from one team in a company to another, you can change the user’s path from /team_abc/ to /team_efg/ . You need permission to remove the user from /team_abc/ . You also need permission to put the user into /team_efg/ . This means you need permission to call UpdateUser on both arn:aws:iam::123456789012:user/team_abc/* and arn:aws:iam::123456789012:user/team_efg/* .

To rename a user:

Enter the following command to rename a user:

euare-usermod -u <user_name> --new-user-name <new_name>

Eucalyptus does not return a message. Enter the following command:

euare-groupmod -u <user_name> -p <new_path>

Eucalyptus does not return a message.

2.5.7 - List Users

To list users within a path, perform the steps in this topic.Use the euare-userlistbypath command to list all the users in an account or to list all the users with a particular path prefix. The output lists the ARN for each resulting user.

euare-userlistbypath -p <path>

2.5.8 - Delete a User

To delete a user, perform the tasks in this topic.Enter the following command

euare-userdel -u <user_name>

Eucalyptus does not return a response.

2.6 - Roles

Roles

A role is a mechanism that allows applications to request temporary security credentials on a user or application’s behalf.

2.6.1 - Launch an Instance with a Role

To create a role for a Eucalyptus instance, you must first create a trust policy that you can use for it.

Create Trust Policy

You can create trust policies in two ways:

• a file method
• a command line method

Create trust policy using a file

Create a trust policy file with the contents below and save it in a text file called role-trust-policy.json :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }
  ]
}

Create the role using the euare-rolecreate command, specifying the trust policy file that was previously created:

# euare-rolecreate --role-name describe-instances -f role-trust-policy.json
# euare-rolelistbypath 
arn:aws:iam::408396244283:role/describe-instances

Proceed with applying an access policy to a role.

Create trust policy using the command line

The other way to create the role is to use the command line options to specify the trust policy:Issue the following string on the command line:

# euare-rolecreate --role-name describe-instances --service http://compute.acme.eucalyptus-systems.com:8773/
# euare-rolelistbypath 
arn:aws:iam::408396244283:role/describe-instances

Proceed with applying an access policy to a role.

Create and apply an access policy to a role

Create a policy and save it in a text file with a .json extension. The following example shows a policy that allows listing the contents of an S3 bucket called “mybucket”:

{
  "Statement": [
    {
      "Action": [
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::mybucket"
    }
  ]
}

2.6.2 - Use a Role with an Instance Application

You can use the AWS Java SDK to programmatically perform IAM role-related operations in your Eucalyptus cloud. This example shows how to use the AWS SDK to retrieve the credentials for the IAM role associated with the Eucalyptus instance.The following program lists the contents of the bucket “my-test-bucket” using the credentials stored in the Java system properties:

import com.amazonaws.auth.*;
import com.amazonaws.AmazonClientException;
import com.amazonaws.AmazonServiceException;
import com.amazonaws.auth.AWSCredentialsProvider;
import com.amazonaws.auth.ClasspathPropertiesFileCredentialsProvider;
import com.amazonaws.services.ec2.AmazonEC2;
import com.amazonaws.services.ec2.AmazonEC2Client;
import com.amazonaws.services.s3.*;
import com.amazonaws.services.s3.model.*;

public class MyTestApp {

    static AmazonEC2 ec2;
    static AmazonS3 s3;

    private static void init() throws Exception {

        AWSCredentialsProvider credentials = new ClasspathPropertiesFileCredentialsProvider();
 
        s3 = new AmazonS3Client(credentials);
        s3.setEndpoint("http://128.0.0.1:8773/services/Walrus");
    }


    public static void main(String[] args) throws Exception {

        init();

        try {
           
            String bucketName = "my-test-bucket";           
            System.out.println("Listing bucket " + bucketName + ":");
            ListObjectsRequest listObjectsRequest = new ListObjectsRequest(bucketName, "", "", "", 200);
            ObjectListing bucketList;
            do {
                bucketList = s3.listObjects(listObjectsRequest);
                for (S3ObjectSummary objectInfo :
                        bucketList.getObjectSummaries()) {
                    System.out.println(" - " + objectInfo.getKey() + "  " +
                            "(size = " + objectInfo.getSize() +
                            ")");
                }
                listObjectsRequest.setMarker(bucketList.getNextMarker());
            } while (bucketList.isTruncated());

        } catch (AmazonServiceException eucaServiceException ) {
            System.out.println("Exception: " + eucaServiceException.getMessage());
            System.out.println("Status Code: " + eucaServiceException.getStatusCode());
            System.out.println("Error Code: " + eucaServiceException.getErrorCode());
            System.out.println("Request ID: " + eucaServiceException.getRequestId());
        } catch (AmazonClientException eucaClientException) {
            System.out.println("Error Message: " + eucaClientException.getMessage());
        }
        System.out.println("===== FINISHED =====");
    }

}                    

This application produces output similar to the following:

Listing bucket my-test-bucket:
 - precise-server-cloudimg-amd64-vmlinuz-virtual.manifest.xml  (size = 3553)
 - precise-server-cloudimg-amd64-vmlinuz-virtual.part.0  (size = 4904032)
 - precise-server-cloudimg-amd64.img.manifest.xml  (size = 7014)
 - precise-server-cloudimg-amd64.img.part.0  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.1  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.10  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.11  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.12  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.13  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.14  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.15  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.16  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.17  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.18  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.19  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.2  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.20  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.21  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.22  (size = 2570400)
 - precise-server-cloudimg-amd64.img.part.3  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.4  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.5  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.6  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.7  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.8  (size = 10485760)
 - precise-server-cloudimg-amd64.img.part.9  (size = 10485760)
===== FINISHED =====

The problem with this approach is that the credentials are hardcoded into the application - this makes them less secure, and makes the application more difficult to maintain. Using IAM roles is a more secure and easier way to manage credentials for applications that run on Eucalyptus cloud instances.

Create a role with a policy that allows an instance to list the contents of a specific bucket, and then launch an instance with that role (for an example, see Launch an Instance with a Role . An example policy that allows listing of a specific bucket will look similar to the following:

{
  "Statement": [
    {
      "Action": [
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::my-test-bucket"
    }
  ]
}             

The following line of code retrieves the credentials that are stored in the application’s credentials profile: AWSCredentialsProvider credentials = new ClasspathPropertiesFileCredentialsProvider(); To use the role-based credentials associated with the instance, replace that line of code with the following: AWSCredentialsProvider credentials = new InstanceProfileCredentialsProvider(); The program now looks like this:

import com.amazonaws.auth.*;
import com.amazonaws.AmazonClientException;
import com.amazonaws.AmazonServiceException;
import com.amazonaws.auth.AWSCredentialsProvider;
import com.amazonaws.auth.ClasspathPropertiesFileCredentialsProvider;
import com.amazonaws.services.ec2.AmazonEC2;
import com.amazonaws.services.ec2.AmazonEC2Client;
import com.amazonaws.services.s3.*;
import com.amazonaws.services.s3.model.*;

public class MyTestApp {

    static AmazonEC2 ec2;
    static AmazonS3 s3;

    private static void init() throws Exception {

        AWSCredentialsProvider credentials = new InstanceProfileCredentialsProvider();
 
        s3 = new AmazonS3Client(credentials);
        s3.setEndpoint("http://128.0.0.1:8773/services/Walrus");
    }


    public static void main(String[] args) throws Exception {

        init();

        try {
           
            String bucketName = "my-test-bucket";
           
            System.out.println("Listing bucket " + bucketName + ":");
            ListObjectsRequest listObjectsRequest = new ListObjectsRequest(bucketName, "", "", "", 200);
            ObjectListing bucketList;
            do {
                bucketList = s3.listObjects(listObjectsRequest);
                for (S3ObjectSummary objectInfo :
                        bucketList.getObjectSummaries()) {
                    System.out.println(" - " + objectInfo.getKey() + "  " +
                            "(size = " + objectInfo.getSize() +
                            ")");
                }
                listObjectsRequest.setMarker(bucketList.getNextMarker());
            } while (bucketList.isTruncated());

        } catch (AmazonServiceException eucaServiceException ) {
            System.out.println("Exception: " + eucaServiceException.getMessage());
            System.out.println("Status Code: " + eucaServiceException.getStatusCode());
            System.out.println("Error Code: " + eucaServiceException.getErrorCode());
            System.out.println("Request ID: " + eucaServiceException.getRequestId());
        } catch (AmazonClientException eucaClientException) {
            System.out.println("Error Message: " + eucaClientException.getMessage());
        }
        System.out.println("===== FINISHED =====");
    }

}

NOTE: Running this code outside of an instance will result in the following error message:

Listing bucket my-test-bucket:
Error Message: Unable to load credentials from Amazon EC2 metadata service

When the application is running on an instance that was launched with the role you created, the credentials for the role assigned to the instance will be retrieved from the Instance Metadata Service.

2.6.3 - Assume a Role

A role is assigned a specific set of tasks and permissions. Users may assume a different role than the one they have in order to perform a different set of tasks. For example, the primary administrator is unavailable and the backup administrator is asked to assume the role of the primary administrator during his or her absence. A few points to consider before assuming a role:

• A role must first be set up by an administrator.
• You must log in as an IAM user, not as an account root user.
• Once you assume another role, you temporarily give up your existing user permissions and assume the permissions of your new role.
• When you are no longer assuming another role, your usual user permissions are automatically restored.

Create Role

The scenario described in this section outlines the procedure for creating a role in order to delegate permissions to an IAM user.Create a role that allows users of an account to manage keypairs. Management of keypairs include the following EC2 actions:

• CreateKeyPair

• DeleteKeyPair

• DescribeKeyPairs

• ImportKeyPair Create a role for managing keypairs for the account. In this example, the admin user of ‘devops’ account (001827830003) is creating the role:

  cat devops-role-trustpolicy.json

  { “Version”: “2012-10-17”, “Statement”: [{ “Effect”: “Allow”, “Principal”: {“AWS”: “arn:aws:iam::001827830003:root”}, “Action”: “sts:AssumeRole” }] }

  euare-rolecreate -f devops-role-trustpolicy.json devops-ec2-keypair-mgmt-role –region devops-admin@future

Add IAM access policy for keypair management to the role:

# cat keypair-mgmt-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1445362739663",
      "Action": [
        "ec2:CreateKeyPair",
        "ec2:DeleteKeyPair",
        "ec2:DescribeKeyPairs",
        "ec2:ImportKeyPair"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

# euare-roleuploadpolicy --policy-name ec2-keypair-actions --policy-document keypair-mgmt-policy.json devops-ec2-keypair-mgmt-role --region devops-admin@future

Now that the role has been created, follow the AWS IAM best practice of using groups to assign permission to IAM users and attach an IAM access policy to the group to allow any members (example shows ‘user01’ user) to assume the ‘devops-ec2-keypair-mgmt-role’ role:

# euare-groupcreate -g Key-Managers --region devops-admin@future
# euare-groupadduser -u user01 -g Key-Managers --region devops-admin@future
# cat devops-keypair-mgmt-assume-role-policy.json
{
 "Version": "2012-10-17",
 "Statement": [{
 "Effect": "Allow",
 "Action": "sts:AssumeRole",
 "Resource": "arn:aws:iam::001827830003:role/devops-ec2-keypair-mgmt-role"
 }]
}
# euare-groupuploadpolicy -p keypair-mgmt-role-perm -f devops-keypair-mgmt-assume-role-policy.json Key-Managers --region devops-admin@future

Now that members can assume the ‘devops-ec2-keypair-mgmt-role’ role, run the following command to list all keypairs under the account:

# eval `/usr/bin/euare-assumerole devops-ec2-keypair-mgmt-role --region devops-user01@future`
# euca-describe-keypairs --region @future
KEYPAIR	devops-admin	9e:1a:bc:ac:98:b1:97:7c:65:b0:b3:7c:96:f5:d5:7b:a1:3e:36:a6

When done assuming the role, the role must be released using euare-releaserole :

# eval `/usr/bin/euare-releaserole --region devops-user01@future`

2.6.4 - Delegate Access Across Your Accounts Using Roles

A role can be used to delegate access to resources that are in different accounts that you own.Using roles to access resources across different accounts allows users to assume a role that can access all the resources in in different acccounts, rather than having users log into different accounts to achieve the same result.

Using Roles to Access Resources in Another Account

The scenario described in this section outlines the procedure for a user in Account B to create a role that provides access to a particular OSGObject Storage Gateway (OSG) bucket owned by Account B, which can be assumed by user in Account A.Using s3cmd , list bucket that will be shared through role:

# ./s3cmd/s3cmd --config=.s3cfg-acctB-user11 ls s3://mongodb-snapshots
2014-12-01 22:34 188563920   s3://mongodb-snapshots/mongodb-backup-monday.img.xz
2014-12-02 13:34 188564068   s3://mongodb-snapshots/mongodb-backup-tuesday.img.xz

Create Role in Account B with Trust Policy for User from Account A:

# cat acctB-role-trust-acctA-policy.json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::290122656840:user/user01"},
    "Action": "sts:AssumeRole"
  }]
}

# euare-rolecreate --role-name cross-bucket-access-mongodb-logs --policy-document acctB-role-trust-acctA-policy.json

Upload IAM Access Policy for Role in Account B:

# cat acctB-mongodb-snapshots-bucket-access-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::mongodb-snapshots"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::mongodb-snapshots/*"
    }
  ]
}

# euare-roleuploadpolicy --role-name cross-bucket-access-mongodb-logs --policy-document acctB-mongodb-snapshots-bucket-access-policy.json --policy-name mongodb-logs-bucket-access

Upload IAM access policy to Group (e.g. Testers) associated with user in Account A to allow for Role in Account B to be assumed. For more information, go to Amazon Web Services IAM Best Practices .

# cat acctA-assume-role-acctB-policy.json
{
  "Statement": [
    {
      "Sid": "Stmt1417531456446",
      "Action": [
        "sts:AssumeRole"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:iam::325271821652:role/cross-bucket-access-mongodb-logs"
    }
  ]
}

# euare-groupuploadpolicy --policy-name mongodb-bucket-access-role --group-name Testers --policy-document acctA-assume-role-acctB-policy.json

The example below demonstrates how to use a python script leveraging the boto library. Another way to assume this role is to run the Euca2ools command, euare-assumerole , using the AccountA/user01 credentials. For more information regarding assuming a role, see an example from the Assume a Role section. The script below performs the following actions:

• Accesses STS to get temporary access key, secret key and token

• List contents of bucket “mongodb-snapshots”

  ======================= #!/bin/env python

  import boto from boto.sts import STSConnection from boto.s3.connection import S3Connection from boto.s3.connection import OrdinaryCallingFormat

  if name == “main”: """ Assuming ‘cross-bucket-access-mongodb-logs’ role by AccountA, User01 user """ STSConnection.DefaultRegionEndpoint = “tokens.future.euca-hasp.cs.prc.eucalyptus-systems.com” sts_connection = STSConnection(aws_access_key_id="", aws_secret_access_key="", is_secure=False, port=“8773”) assumedRoleObject = sts_connection.assume_role( role_arn=“arn:aws:iam::325271821652:role/cross-bucket-access-mongodb-logs”, role_session_name=“AcctAUser01MongoDBBucketAccess”)

    s3 = S3Connection(aws_access_key_id=assumedRoleObject.credentials.access_key,
    aws_secret_access_key=assumedRoleObject.credentials.secret_key,
    security_token=assumedRoleObject.credentials.session_token,
    host="objectstorage.future.euca-hasp.cs.prc.eucalyptus-systems.com",
    is_secure=False, port=8773, calling_format=OrdinaryCallingFormat())
  
    bucket_name = "mongodb-snapshots"
    bucket = s3.lookup(bucket_name)
    if bucket:
        print "Bucket Information [%s]:" % bucket_name
        print "------------------------------------------------------------"
        for key in bucket:
            print "\t" + key.name
    else:
        print "Bucket is not available: " + bucket_name + "\n"
  

  ==================

Run the script:

# ./describe-bucket-script.py
Bucket Information [mongodb-snapshots]:
------------------------------------------------------------
	mongodb-backup-monday.img.xz
	mongodb-backup-tuesday.img.xz