Federation Differences Between AWS and Eucalyptus

This section outlines the differences between AWS and Eucalyptus with respect to federation in the following platforms:

Euca2ools vs. AWS EC2 API Tools

Eucalyptus OSG vs. AWS S3

Eucalyptus Resource-Level vs. AWS Resource-Level Permissions

Global Cloud Administration (Local vs. Federated)

Euca2ools vs. AWS EC2 API Tools

Euca2ools uses the --region option to read information from a configuration file.
For a user to be able to access resources from different regions using Euca2ools, the -U URL,
--url URL option has to be used. This behavior is different when compared to AWS API tools.
With the AWS API tools, the --region option is used to access resources in different regions.
Examples are as follows:

Eucalyptus OSG vs. AWS S3

Eucalyptus OSG for each region is a separate entity (i.e. if you want to have the same bucket across all regions,
you need to create that bucket across each region). With AWS S3, once you create a bucket in one region, it is replicated to
all regions. This is the same for objects as well.

ARN Resources

This behavior is extremely important when dealing with IAM access policies regarding S3 (OSG) resources.
When defining a resource using an ARN:

arn:partition:service:region:namespace:relative-id

Per AWS S3 documentation, when specifying a resource in a policy, you don't specify region
and namespace in the ARN. The S3 (OSG) ARN resource will look like the following:

arn:aws:s3:::bucket_name
arn:aws:s3:::bucket_name/key_name

If a user tries to specify a region and/or namespace in an ARN associated with an S3 (OSG) resource on Eucalyptus,
the following error will be displayed:

error (MalformedPolicyDocument): Error in uploaded policy: net.sf.json.JSONException: 'arn:aws:s3:region-1::*' is not a valid ARN

The only valid ARNs for S3 (OSG) resources on Eucalyptus are as follows:

"Resource": "arn:aws:s3:::*"
"Resource": "arn:aws:s3:::*/*

Eucalyptus vs. AWS Resource-Level Permissions

There are some services that AWS supports resource-level permissions to be used in AWS IAM access policies.
A list of them can be found in the AWS IAM Guide - AWS Services that work with IAM. Two services that do not support resource-level
permissions on AWS are the following:

On Eucalyptus, these services do support resource-level permissions, as well as the implemented services
that support resource-level permissions in AWS. Below are example IAM policies for each service:

Auto Scaling

Eucalyptus IAM policy to allow all Autoscaling actions against any AutoScaling group under a given account:

Note: AWS services that do support resource-level permissions have different behaviors depending upon the service API call
(for example, AWS ELB doesn't support any Describe* service API calls if a resource-level permission is defined).
This wasn't done as part of a security feature, and may just mean that AWS has not yet implemented support for that API call.
Eucalyptus supports resource-level permissions for all API service calls. This means that the more restrictive AWS IAM access
policy for the service that is supported on Eucalyptus should work seamlessly.

Global Cloud Administration (Local vs. Federated)

On AWS, there isn't a concept of a global cloud administrator (on AWS public cloud, AWS is the
'global cloud administrator'). Eucalyptus has the concept of a global cloud administrator. This
is represented by the 'eucalyptus' account. This account, along with other Eucalyptus system
accounts, are default on each Eucalyptus cloud. Currently, these Eucalyptus system accounts
cannot be 'synced' when setting up a federated cloud environment. In order to have the concept
of a 'global cloud administrator', one must leverage cross-account roles. Regarding the
Eucalyptus IAM policy associated with the global cloud administrator, you can leverage an
existing policy that is used by the ResourceAdministrator privileged persona (i.e. role), which
is present on each cloud. Below are the high-level steps:

Create a non-Eucalyptus account (i.e. global cloud account)

Under each 'eucalyptus' account on each cloud (i.e. region), do the following:

Using the credentials of the user that has been granted access to the ResourceAdministrator
role, there are a couple of ways to access the ResourceAdministrator role ― through Euca2ools
or programmatically.

Using Euca2ools

Use euare-assumerole to assume the role of the ResourceAdministrator of that
region (i.e. cloud).

Note: The ARN associated with the ResourceAdministrator will be the same
for each cloud (e.g. eucalyptus:role/eucalyptus/ResourceAdministrator). To use the role for
different regions (i.e. clouds), leverage the endpoints for that region. For
example:

Leverage python boto STS for a given region to acquire Access Key ID, Secret Key,
and Security Token that can be used with any AWS service API implemented by Eucalyptus. Make
sure that the given service endpoint URL matches the region that provided the STS credentials.
For example:

In [1]: import boto.sts
In [2]: sts_connection = boto.sts.connect_to_region('asap-rocky-2013', port=8773)
In [3]: assumedRoleObject = sts_connection.assume_role(role_arn="arn:aws:iam::000560243913:role/FederatedCloudAdministrator", role_session_name="FederatedDescribeELBPolicyTypes")
In [4]: assumedRoleObject.credentials.access_key
Out[4]: u'AKIACY7V4ZGDNKCEXLQK'
In [5]: assumedRoleObject.credentials.secret_key
Out[5]: u'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'
In [6]: assumedRoleObject.credentials.session_token
Out[6]: u'ZXVjYQABHk7WVPi6w8keQpDWM4dlKFDFro3HRZ35asSDoHmWCEqTFNWLk/4xX2AgvmMQ1A6TvGtsRtj4ozQ34IKCtfofE2BNOdijk0oi6xrmvFs8HV3gxbCz3AA/uw8Scgk3NgB0FCsIFLyrcEYMvtdSZOdmh1m0EV5ld8HNonph1yfjZlQIRIO8mxVeDxzOa+9EfJWzD30Do/X5UbBl2PvlceK+dwwZPFgt25NwRCZnxPRndYrCJ2LPSkv0YQ=='
# eulb-describe-lb-policy-types -I AKIACY7V4ZGDNKCEXLQK -S 3VWnfDyBrCqtUAAiZqfvQjACLpdRrReHSkX6gLFu --security-token ZXVjYQABHk7WVPi6w8keQpDWM4dlKFDFro3HRZ35asSDoHmWCEqTFNWLk/4xX2AgvmMQ1A6TvGtsRtj4ozQ34IKCtfofE2BNOdijk0oi6xrmvFs8HV3gxbCz3AA/uw8Scgk3NgB0FCsIFLyrcEYMvtdSZOdmh1m0EV5ld8HNonph1yfjZlQIRIO8mxVeDxzOa+9EfJWzD30Do/X5UbBl2PvlceK+dwwZPFgt25NwRCZnxPRndYrCJ2LPSkv0YQ== -U http://loadbalancing.c-40.autoqa.qa1.eucalyptus-systems.com:8773/
POLICY_TYPE SSLNegotiationPolicyType Listener policy that defines the ciphers and protocols that will be accepted by the load balancer. This policy can be associated only with HTTPS/SSL listeners.
POLICY_TYPE LBCookieStickinessPolicyType Stickiness policy with session lifetimes controlled by the browser (user-agent) or a specified expiration period. This policy can be associated only with HTTP/HTTPS listeners.
POLICY_TYPE BackendServerAuthenticationPolicyType Policy that controls authentication to back-end server(s) and contains one or more policies, such as an instance of a PublicKeyPolicyType. This policy can be associated only with back-end servers that are using HTTPS/SSL.
POLICY_TYPE ProxyProtocolPolicyType Policy that controls whether to include the IP address and port of the originating request for TCP messages. This policy operates on TCP/SSL listeners only
POLICY_TYPE AppCookieStickinessPolicyType Stickiness policy with session lifetimes controlled by the lifetime of the application-generated cookie. This policy can be associated only with HTTP/HTTPS listeners.
POLICY_TYPE PublicKeyPolicyType Policy containing a list of public keys to accept when authenticating the back-end server(s). This policy cannot be applied directly to back-end servers or listeners but must be part of a BackendServerAuthenticationPolicyType.