Access Overview

• 1: Access Concepts
• 1.1: User Identities
• 1.2: Special Identities
• 1.3: Credentials
• 1.4: Account Creation
• 1.5: Special User Attributes
• 1.6: Roles
• 2: Policy Overview
• 2.1: Default Permissions
• 2.2: Quotas
• 2.3: Algorithms
• 2.4: Sample Policies

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 - 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.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.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.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.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.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

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.

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.

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.

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.

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/*"
    }
  ]
   
}