Comparison of IAM Between Eucalyptus and AWS


Eucalyptus Versions: 3.3.0 and Greater

This article is focused on explaining the differences between IAM on Eucalyptus 3.3/3.4 and AWS.

Eucalyptus IAM is influenced by the implementation of IAM on AWS.  The features of AWS IAM that Eucalyptus IAM provides are as follows:

  • Central control of users and security credentials—You can control creation, rotation, and revocation of each user's AWS security credentials (such as access keys)

  • Central control of user access—You can control what data in the AWS system users can access and how they access it

  • Shared AWS resources—Users can share data for collaborative projects

  • Permissions based on organizational groups—You can restrict users' AWS access based on their job duties (for example, admin, developer, etc.) or departments. When users move inside the organization, you can easily update their AWS access to reflect the change in their role

  • Central control of AWS resources—Your organization maintains central control of the AWS data the users create, with no breaks in continuity or lost data as users move around within or leave the organization

  • Control over resource creation—You can help make sure that users create AWS data only in sanctioned places

Eucalyptus IAM leverages these features in the following ways:

Central Control of Users and Security Credentials

Eucalyptus has the concept of the "eucalyptus" account, which is has unrestricted access to the cloud.  The framework regarding there being an admin user of each account still applies - similar to AWS - but any user/group part of this account currently aren't restricted by IAM policies. This account is currently recommended for cloud admins where there are special auditing, user management (such as password expiration, and enable/disable accounts), and/or resource management needs for the cloud. Any user of this group can use the --as-account option with the euare commands (IAM-compatible commands of euca2ools) to manage identity and access control for other accounts running on the cloud. All other accounts have the same behavior as experienced with AWS. For more information, please refer to the Default Permissions section of the Eucalyptus 3.3 Administration Guide. For recommendations regarding best practices on using IAM on Eucalyptus, please refer to the IAM Best Practices guide for AWS. (NOTE: not all best practices in the AWS IAM guide apply to Eucalyptus.  Please use what recommendations best fit your cloud needs).

Central Control of User Access

Just as in AWS, Eucalyptus uses IAM to control how users access data and what data they can access.  When a user is first created, they have permission to do no actions. The admin of the account must grant access to user(s) in order for them to utilize any resource on Eucalyptus. How Eucalyptus differs is that the "eucalyptus" account can set quotas. Quotas are be leveraged by the "eucalyptus" account (for account-level quotas), and admins of accounts (for user-level quotas). For some example policies, please refer to the Eucalyptus 3.3 Administrator's Guide.  For additional IAM policies, check out the AWS Policy Generator for creating more custom policies. (NOTE:  not all actions are supported on Eucalyptus. Please reference the Eucalyptus 3.3 Release Notes and Eucalyptus 3.3 Administration Guide to see which actions are currently supported).

Additionally, Eucalyptus has LDAP/AD integration, which will map users and groups based upon either dynamic accounts (group of groups) or static accounts defined by the cloud administrator.  For more information on LDAP/AD integration, please refer to the LDAP/AD Integration section of the Eucalyptus 3.3 Administration Guide.

Shared Eucalyptus Resources

Eucalyptus does allow access to shared resources - very much the same way that AWS IAM operates, but its only associated with Walrus. The major difference is allowing access to buckets.  AWS supports the following ACLs for buckets:

Eucalyptus 3.3 currently supports S3 IAM policies, and bucket ACLs. By using S3 IAM policies and bucket ACLs, users from one account can allow access (based upon the ACL set) from users of another account to the specified bucket.  Although bucket policies aren't supported in Eucalyptus 3.3/3.4, bucket ACLs with S3 IAM policies can be utilized to achieve similar restrictions.

Permissions based on Organizational Groups

A feature that is currently in beta right now is the support for IAM Roles.  This helps provide restrictions based upon a user's role within an organization.  Eucalyptus IAM supports  the AWS IAM Actions related to Roles.  Eucalyptus IAM has also extended policy support regarding Roles to help administrator's enforce quotas. Currently, full support for AWS IAM Roles will be released in Eucalyptus 3.4.

Central Control of Eucalyptus Resources and Control over Resource Creation

Eucalyptus IAM also allows control of resources.  Besides supporting EC2 and S3 IAM policies, Eucalyptus 3.3 introduced Autoscaling, Elastic Load Balancing and CloudWatch.  Since Eucalyptus has the "eucalyptus" account and the admin user of accounts, there are two levels of control that can be utilized to help control user data and resources in Eucalyptus.  Documentation regarding IAM support and extensions for AutoScaling, ELB and Cloudwatch, please reference the following resources:

For additional information regarding IAM policies associated with these new services for Eucalyptus, please refer to the AWS documentation for Autoscaling, Elastic Load Balancing and Cloudwatch.

In closing, Eucalyptus IAM is quite powerful given its similarities to AWS IAM, and also its differences.  For additional information regarding the design features of Eucalyptus 3.3, please check out the architecture designs on Github.


This article originally covered Eucalyptus 3.3.0 - 3.3.2.  Eucalyptus 3.4 supports this, as well as additional features as well.  Please refer to the following resources that provide information on these additional 3.4 IAM features:

Have more questions? Submit a request


Powered by Zendesk