Manage Regions
This section provides information about regions and identity federation.
This is the multi-page printable view of this section. Click here to print.
This section provides information about regions and identity federation.
Eucalytpus provides support for the notion of federation of identity.Federation of identity information means that a Cloud Administrator can create a federation of (otherwise independent) Eucalyptus “clouds” where a Cloud User, using the same credentials as always, can use any of these federated Eucalyptus cloud regions. For the parts of Identify Access Management (IAM) and Security Token Service (STS) that Eucalyptus implements, the experience exposed to the Cloud User is the same as that seen by an AWS user working across AWS regions.
A user can interact with any region using the same credentials, subjected to the same policies, and having uniformly accessible and structured principals (Accounts, Users, Groups, Roles, etc.). The globality also includes the STS service functionality, the temporary credentials produced by the STS service also work globally.
Notably, this feature is restricted to IAM/STS and does not include other services which have pseudo-global characteristics, such as global bucket name space for S3. The following are general principles associated with regions:
This section describes the necessary configuration properties that need to be addressed.For federation to be successfully configured, each cloud (i.e. region) that will be part of the federated cloud needs to have the following properties set (at a minimum):
Property Name | Description |
---|---|
region.region_name | This cloud property identifies the local region. This is required and should be valid for use in a DNS name. |
region.region_configuration | This property is a JSON document that will be the same for all federated regions. |
In this example, there will be two clouds used (10.111.5.32 and 10.111.1.1). Before setting up federation, the clouds must meet the following requirements:
This section outlines the differences between AWS and Eucalyptus with respect to federation in the following platforms:
This section is presented in a Q&A format to provide a quick reference to the most frequently asked questions.
Can Cloud Administrators federate existing clouds (i.e. clouds that already have non-system Eucalyptus accounts)? A. No, this is currently not supported. If a cloud administrator wants to federate an Eucalyptus clouds, this must be done prior to any non-system Eucalyptus account/user/group creation.
Is Eucalyptus DNS required for federating Eucalyptus clouds? A. No, however its highly recommended to enable it.
Are supported for more granular IAM access policies per region? A. As of 4.2, no. IAM policies apply globally (for all regions). In order to get more granular IAM access, use availability zone restrictions under each region. For more information, see Restrict Image to Availability Zone .
What services/resources span globally? Which span regionally? A. Currently, only Eucalyptus IAM and STS are global services/resources. All other services/resources are region-based (i.e. Eucalyptus cloud-specific). The only resource that can be either global or regional are keypairs. This is because users can import the same keypair to each region, therefore, the keypair is globally accessible. For additional information, please refer to the AWS EC2 Documentation regarding Resource Locations .
Are Eucalyptus system accounts global in a federated setup? A. No. Any Eucalyptus system account is limited to that region. Examples of Eucalyptus system accounts are as follows:
Is and supported? A. No. There have been no improvements associated with Object Storage Gateway (OSG) regarding cross-regional behavior similar to AWS.
If a user uploads an object to an Object Storage Gateway in one region, will copies show up in other regions (similar to the behavior on AWS)? A. No, this is currently unsupported.
Do federated Eucalyptus clouds follow the same globally? A. No, Eucalyptus IAM limitations are regionally scoped.