Skip to content

More Mind Spew-age from Harold Spencer Jr.

Random Information – sometimes techie, sometimes not..

Menu

  • About The Author
  • Interests
  • Private Cloud Computing
  • Infrastructure
  • System Adminstration
  • Private Cloud Computing

RSS All Things Distributed – Werner Vogels

  • Monoliths are not dinosaurs
  • Can autonomous trucks transform the global supply chain?
  • How AI coding companions will change the way developers work
  • AI doesn't plant trees
  • Demystifying LLMs with Amazon distinguished scientists
  • An introduction to generative AI with Swami Sivasubramanian
  • Is Australia the new epicenter for healthtech startups?
  • Bringing Digital People to life with autonomous animation
  • Melbourne gets a Region, a big trip, and a brain mapping startup
  • An album for each year - 2022 version

RSS Elastician – Mitch Garnaat

  • Back To The Future
  • Looking at Clouds from Both Sides Now
  • Don't reboot me, bro!
  • Mapping Requests to EC2 API Versions
  • Python and AWS Cookbook Available
  • Does Python Scale?
  • Accessing the Eucalyptus Community Cloud with boto
  • Accessing the Internet Archive with boto
  • All Your Website Are Belong to S3
  • It Takes a Village...

RSS Amazon Web Services Blog

  • Announcing the latest AWS Heroes – June 2023
  • A New Set of APIs for Amazon SQS Dead-Letter Queue Redrive
  • AWS Week in Review – Amazon Security Lake Now GA, New Actions on AWS Fault Injection Simulator, and More – June 5, 2023
  • New – AWS DMS Serverless: Automatically Provisions and Scales Capacity for Migration and Data Replication
  • New – Snowball Edge Storage Optimized Devices with More Storage and Bandwidth
  • AWS Week in Review – AWS Wickr, Amazon Redshift, Generative AI, and More – May 29, 2023
  • AWS Week in Review – AWS Documentation Updates, Amazon EventBridge is Faster, and More – May 22, 2023
  • Amazon SageMaker Geospatial Capabilities Now Generally Available with Security Updates and More Use Case Samples
  • New – Simplify the Investigation of AWS Security Findings with Amazon Detective
  • Retiring the AWS Documentation on GitHub

RSS Amazon Web Services Security Blog

  • AWS Security Profile: Matthew Campagna, Senior Principal, Security Engineering, AWS Cryptography
  • 2023 ISO and CSA STAR certificates now available with 8 new services and 1 new Region
  • AWS Security Profile – Cryptography Edition: Valerie Lambert, Senior Software Development Engineer
  • Our commitment to shared cybersecurity goals
  • Updated AWS Ramp-Up Guide available for security, identity, and compliance
  • New eBook: 5 Keys to Secure Enterprise Messaging
  • Announcing the AWS Blueprint for Ransomware Defense
  • Updated whitepaper available: Architecting for PCI DSS Segmentation and Scoping on AWS
  • AWS Security Profile: Ritesh Desai, GM, AWS Secrets Manager
  • Get custom data into Amazon Security Lake through ingesting Azure activity logs

RSS Google Developers Blog

  • Google I/O Extended watch parties & upcoming meetups
  • How Google Enables Experts To Innovate Developer Tools From Food To Music
  • #WeArePlay | Meet Tessa and Saasha from the UK, founders of waste-fighting app Olio
  • AAPI Heritage Month: How Web GDE Vickie Li views the importance of diversity
  • Celebrate Google’s Coding Competitions with a final round of programming fun
  • What’s new in Google Pay
  • How web GDE Erick Wendel forever changed Node.js with the support of the open-source community
  • Using Generative AI for Travel Inspiration and Discovery
  • Jetpack Compose Buttons for Google Pay and Google Wallet
  • How Web GDE Martine Dowden approaches web design from an accessibility perspective

RSS Google Cloud Platform Blog

  • What’s new with Google Cloud
  • Four steps to managing your Cloud Logging costs on a budget
  • How an open data cloud is enabling Airports of Thailand and EVme to reshape the future of travel
  • How to easily migrate your apps to containers — free deep dive and workshop
  • At Google I/O, generative AI gets to work
  • Dialing up the impact of digital natives in the MENA region with Google Cloud
  • Committed use discounts for RHEL and RHEL for SAP now available on Compute Engine
  • Introducing BigQuery Partner Center — a new way to discover and leverage integrated partner solutions
  • Bringing our world-class expertise together under Google Cloud Consulting
  • Accelerate time to value with Google’s Data Cloud for your industry

RSS Thinking Out Cloud

  • Ravello Launches the Cloud Application Hypervisor
  • State of the Open Source Cloud
  • Cloud Adoption Patterns - Citrix Synergy 2012 Keynote
  • In the Game of Clouds, You Win Or You Die: CloudStack
  • More on Bottom-Up Adoption of Cloud Computing and SaaS

Tags

acls ami ansible appscale autoscaling aws aws compatibility aws ec2 boto cloud-init cloud administrator cloud computing cloudformation coreos coreos cluster coreos etcd docker drbd ec2 elb emi emis.eucalyptus.com Euare euca2ools euca2ools 3 eucalyptus eucalyptus 2.0 eucalyptus 3.4 eucalyptus 4.0 eucalyptus 4.0.2 eucalyptus load balancer eustore eutester git haproxy high availability hybrid cloud iaas IAM image management ipython lvm mac os x mdb neo4j openldap paas Personal precise private cloud python boto s3 s3cmd stackato ubuntu cloud image ubuntu cloud images ubuntu raring varnish walrus xcode

Follow me on Twitter

My Tweets

roles

Eucalyptus 4.0 IAM Feature: Cross-Account API Access Using IAM Roles

December 7, 2014December 11, 2014 hspencer77aws compatibility, boto, cloud computing, cross-account API access, Euare, euca2ools, eucalyptus, eucalyptus 4.0.2, IAM, rolesLeave a comment

As mentioned in my past blog, Eucalyptus has the concept of EUARE (IAM) Roles which pretty much work the same way as AWS IAM Roles.  This blog with discuss how to set up cross-account API access using EUARE (IAM) Roles in Eucalyptus 4.0.2.  Cross-account API access is very useful for use cases where there are multiple Eucalyptus EUARE accounts that need to access the same resources.  A great example of this can be found in the AWS IAM documentation regarding this same feature.

To establish cross-account access, in the trusting account (Account A), you create an IAM role that designates Account B as the trusted account. The role also defines permissions that allow Account B access to specific resources in Account A. Account B can then delegate this access to its own users (IAM users or federated users). Account B cannot delegate more access to its users than the permissions that it has been granted by Account A.

To demonstrate this feature, a user in Account A will set up a role to allow DescribeInstances API access for a user in Account B.

Prerequisites

Before getting started, the following resources are needed:

  • Eucalyptus 4.0.2 Cloud with Eucalyptus DNS enabled
  • Two non-‘eucalyptus‘ accounts created (for example, AccountA and AccountB)
  • Eucalyptus Machine Images (EMIs) available to be launched as instances
  • Running instance(s) under AccountA
  • Latest version of euca2ools

Once these prerequisites are met, the cross-account role use case can be deployed.

NOTE:  All actions are assumed to be performed by a user under the given account.  All IAM actions can be done by the cloud administrator (i.e. user under the ‘eucalyptus’ account) if so desired.

Account A EUARE (IAM) Setup

Before setting up the role in Account A, the minimal EUARE (IAM) access policy needed by the user in Account A in order to create the role.  The access policy can be found here:

  • http://cross-account-blog.s3.amazonaws.com/euare-accountA-access.policy

This policy allows the user to perform the following EUARE (IAM) API actions:

  • Create a role
  • List roles
  • Upload a policy to a role

Using IAM best practices, apply this policy to the group that has this user as a member under Account A, using the euare-groupuploadpolicy command.

Trust Policy for Role in Account A

In order for the user in Account B (in this example, the user is ‘user12’) to be able to assume the role under Account A, a trust policy needs to be associated with the role.  Below is an example of the trust policy (which can be downloaded from here):

{
 "Version": "2012-10-17",
 "Statement": [{
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::325271821652:user/user12"},
 "Action": "sts:AssumeRole"
 }]
}

This states that ‘user12’ under the Account ID ‘325271821652‘ (which maps to Account B) can assume this role.  To create the role, use the euare-rolecreate command as follows:

# euare-rolecreate --role-name cross-describe-instances --file-name euare-accountA-role-trust.policy

IAM Access Policy for Role under Account A

After creating the role, now the API access (in this case – DescribeInstances) needs to be associated by uploading an IAM access policy for the role.  Here is an example of the policy:

{
 "Statement": [
 {
 "Sid": "Stmt1417530823611",
 "Action": [
 "ec2:DescribeInstances"
 ],
 "Effect": "Allow",
 "Resource": "*"
 }
 ]
}

This policy can be downloaded from here.  Use euare-roleuploadpolicy to upload the access policy to the role.  For example:

# euare-roleuploadpolicy --role-name cross-describe-instances --policy-name describe-instances --policy-document euare-accountA-role-access.policy

Once this has been completed, all work is done under Account A.  Next, the user under Account B needs to be allowed to assume the role.  The only important information needed from Account A, is the ARN for the role – which in this use case is the following:

arn:aws:iam::290122656840:role/cross-describe-instances

Account B EUARE (IAM) Setup

Before applying the policy to allow assuming the role to the group where ‘user12’ is a member, the user needs to be able to do the following at a minimum:

  • Generate Access Keys
  • List Access Keys
  • List groups
  • Upload IAM policies to groups

An example IAM access policy of these actions can be found here:

  • http://cross-account-blog.s3.amazonaws.com/euare-accountB-access.policy

As mentioned above, apply this policy to the group that has ‘user12’ as a member under Account B, using the euare-groupuploadpolicy command.

Assume Role Access

To allow ‘user12’ under Account B to assume the role under Account A, we need to upload another policy.  This can be done to the group that has ‘user12’ as a member, or directly to ‘user12’ by using euare-useruploadpolicy.  The key information needed in the IAM policy is the ARN of the role (arn:aws:iam::290122656840:role/cross-describe-instances).  The policy should look something similar to this:

{
 "Statement": [
 {
 "Sid": "Stmt1417531456446",
 "Action": [
 "sts:AssumeRole"
 ],
 "Effect": "Allow",
 "Resource": "arn:aws:iam::290122656840:role/cross-describe-instances"
 }
 ]
}

This policy can be downloaded from here:

  • http://cross-account-blog.s3.amazonaws.com/euare-accountB-assume-role.policy

To keep consistent with IAM best practices, euare-groupuploadpolicy will be used to upload the policy to the group that has ‘user12’ as a member:

# euare-groupuploadpolicy --policy-name assume-role-run-describe-instances --group-name Testers --policy-document euare-accountB-assume-role.policy

Once the policy is uploaded, we just need to test out the cross-account access.

Testing with Python Boto

To confirm that the cross-account access works, we will use the boto – a python interface to AWS, which also works with Eucalyptus.  Below is an example script with performs the following actions:

  • Accesses the Eucalyptus STS service to obtain a temporary access key, secret key and token of the assumed role
  • Performs the DescribeInstances API call
#!/bin/env python
import boto
from boto.sts import STSConnection
from boto.ec2.connection import EC2Connection
if __name__ == "__main__":
 """
 Assuming 'describe-instances' role by AccountB, User12 user
 """
 STSConnection.DefaultRegionEndpoint = "tokens.future.euca-hasp.cs.prc.eucalyptus-systems.com"
 sts_connection = STSConnection(aws_access_key_id="<Account B User Access Key>",
                                aws_secret_access_key="<Account B User Secret Key>",
                                is_secure=False, port="8773")

 assumedRoleObject = sts_connection.assume_role(
                     role_arn="arn:aws:iam::290122656840:role/cross-describe-instances",
                     role_session_name="Acct2User12DescribeInstancesSession")

 EC2Connection.DefaultRegionEndpoint = "compute.future.euca-hasp.cs.prc.eucalyptus-systems.com"
 ec2_connection = EC2Connection(aws_access_key_id=assumedRoleObject.credentials.access_key,
                                aws_secret_access_key=assumedRoleObject.credentials.secret_key,
                                security_token=assumedRoleObject.credentials.session_token,
                                is_secure=False, port="8773")

 reservations = ec2_connection.get_all_instances()
 if len(reservations) > 0:
     print "Instance Information:"
     for reservation in reservations:
         for instance in reservation.instances:
             print "\t--------------------------------------"
             print "\tInstance ID:\t" + instance.id
             print "\tInstance State:\t" + instance.state
             print "\tPublic DNS Name:\t" + instance.public_dns_name
             print "\tLaunch Time:\t" + instance.launch_time
 else:
     print "No Instance Reservations Available."

The script can be downloaded from here:

  • http://cross-account-blog.s3.amazonaws.com/describe-instance-script.py

To use the script, the following information is needed:

  • For STSConnection.DefaultRegionEndpoint, use the Eucalyptus DNS name for Eucalyptus Token service associated with your Eucalyptus 4.0.2 cloud (e.g. “tokens.future.euca-hasp.cs.prc.eucalyptus-systems.com“)
  • For EC2Connection.DefaultRegionEndpoint, use the Eucalyptus DNS name for Eucalyptus Compute service associated with your Eucalyptus 4.0.2 cloud (e.g. “compute.future.euca-hasp.cs.prc.eucalyptus-systems.com“)
  • Access Key ID and Secret Access Key of the ‘user12’ user under Account B.

Running the Script

After downloading the script, and perform the edits to match your Eucalyptus 4.0.2 environment, make sure the executable bit is set on the script, and run it:

# ./describe-instance-script.py
Instance Information:
 --------------------------------------
 Instance ID: i-f97462d3
 Instance State: running
 Public DNS Name: euca-10-104-7-27.future.future.euca-hasp.cs.prc.eucalyptus-systems.com
 Launch Time: 2014-12-03T16:22:54.113Z

Observe how the script has listed the instance under Account A.  Confirm this by using the credentials of a user under Account A, and running euca-describe-instances:

# euca-describe-instances --region accountA-user01@
RESERVATION r-370ded0a 290122656840 default
INSTANCE i-f97462d3 emi-bdcec010 euca-10-104-7-27.future.future.euca-hasp.cs.prc.eucalyptus-systems.com euca-172-17-176-24.future.internal running account1-user01 0 m1.medium 2014-12-03T16:22:54.113Z Honest monitoring-disabled 10.104.7.27 172.17.176.24 instance-store hvm sg-525fe580 x86_64

Conclusion

Cross-account access using Eucalyptus EUARE (IAM) roles are very powerful.  It allows cloud administrators and account administrators to provide access to limited resources in different accounts without having the hassle of creating/managing users.  Please refer to the AWS IAM documentation for further examples and use cases.  Enjoy!

Eucalyptus 4.0 IAM Feature: Cross-Account API Access Using IAM Roles
Blog at WordPress.com.
  • Follow Following
    • More Mind Spew-age from Harold Spencer Jr.
    • Already have a WordPress.com account? Log in now.
    • More Mind Spew-age from Harold Spencer Jr.
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar