Using AWS CodeDeploy with Eucalyptus Cloudformation for On-Premise Application Deployments

April 13, 2015April 14, 2015 hspencer77ami, autoscaling, aws codedeploy on-premise instances, cloud computing, cloudformation, eucalyptus 4.1, hp helion eucalyptus, hybrid cloud, IAM, ubuntu cloud images, userdata1 Comment

Background

Recently, Amazon Web Services (AWS) announced that their CodeDeploy service supports on-premise instances. This is extremely valuable – especially for developers and administrators to allow utilization of existing on-premise resources.

For teams who are using HP Helion Eucalyptus 4.1 (or who want to use Eucalyptus), this is even better news. This feature – along with HP Helion Eucalyptus 4.1 Cloudformation – developers can deploy applications within a private cloud environment of HP Helion Eucalyptus. This makes it even easier for developers and administrators to separate out and maintain production (AWS) versus development (HP Helion Eucalyptus) environments (or vice versa). In addition, since HP Helion Eucalyptus strives for AWS compatibility, the Cloudformation templates used on Eucalyptus, can be used with AWS – with just a couple of modifications.

The Setup

To leverage on-premise instances with AWS CodeDeploy, please reference the AWS documentation entitled “Configure Existing On-Premises Instances by Using AWS CodeDeploy“. To use these steps with an HP Helion Eucalyptus cloud, a slight change had to be done to the AWS CLI tools. When using the ‘aws deploy register’ command, AWS CLI checks to see if the instance is running on an AWS environment by confirm if the instance metadata is present. For on-premise cloud environments that provide the same service, this will cause the on-premise instance registration to fail. To resolve this issue, I updated the AWS CLI tools with a patch that checks the instance metadata variable ‘AMI ID’ – which on AWS will begin with ‘ami’. All images on Eucalyptus start with ’emi’ (i.e. Eucalyptus Machine Images). With this patch, on-premise instance registration completes without a problem.

In addition to the patch, the following is needed on HP Helion Eucalyptus 4.1 cloud environments:

A Ubuntu Server 14.04 LTS EMI (EBS-backed or Instance Store-Backed)
Eucalyptus IAM access policy actions that allow the user to use CloudFormations, AutoScaling and EC2 actions. (Along with the Eucalyptus documentation, reference the AWS IAM documentation as well.)

Once these requirements have been met on the HP Helion Eucalyptus 4.1 environment, developers can use their AWS credentials in the Eucalyptus Cloudformation templates to leverage the on-premise instances with AWS CodeDeploy.

Using Eucalyptus Cloudformation For Instance Deployment

To help get started, I provided the following example Cloudformation templates:

Each template has specific parameters that need values. The key parameters are the following:

UserKeyPair -> Eucalyptus EC2 Key Pair
UbuntuImageId -> Ubuntu 14.04 Cloud Image (EMI)
SSHLocation -> IP address range that can SSH into the Eucalyptus instances

Once there are values for these parameters, the Cloudformation templates can be utilized to deploy the on-premise instances.

Configure Existing On-Premises Instances by Using AWS CodeDeploy

After the AWS IAM prerequisites have been met for AWS CodeDeploy, use the example Cloudformation templates with HP Helion Eucalyptus. Below is an example output of both templates being used on a given HP Helion Eucalyptus 4.1 cloud:

# euform-describe-stacks --region account2-admin@eucalyptus-cloud
STACK UbuntuCodeDeployTest CREATE_COMPLETE Complete! Eucalyptus Cloudformation Example => Deploy an instance that is configured and registered as an on-premise instance with AWS CodeDeploy 2015-04-14T02:42:01.325Z
PARAMETER UbuntuImageId emi-759e12a3
PARAMETER UserKeyPair account2-admin
OUTPUT InstanceId i-df9af6f5
OUTPUT AZ thugmotivation101
OUTPUT PublicIP 10.111.75.103
STACK UbuntuCodeDeployAutoScalingTest CREATE_COMPLETE Complete! Eucalyptus CloudFormation Sample Template AutoScaling-Single AZ for AWS CodeDeploy on-premise instances. The autoscaling group is configured to span in one availability zone (one cluster) and is Auto-Scaled based on the CPU utilization of the servers. In addition, each instance will be registered as an on-premise instance with AWS CodeDeploy. Please refer to http://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-configure-on-premises-host.html for additional information. 2015-04-14T02:41:44.733Z
PARAMETER InstanceType m1.xlarge
PARAMETER UbuntuImageId emi-759e12a3
PARAMETER UserKeyPair account2-admin
PARAMETER MinSize 2
PARAMETER MaxSize 4
PARAMETER Zone theinspiration
OUTPUT AutoScalingGroup UbuntuCodeDeployAutoScalingTest-ServerGroup-211FTERKLII6T

Since both Eucalyptus Cloudformation stacks have successfully deployed, let’s check out the instances:

# euca-describe-instances --region account2-admin@eucalyptus-cloud
RESERVATION r-feeb1023 968367465792 UbuntuCodeDeployTest-CodeDeploySecurityGroup-HP5L5HRU3WI98
INSTANCE i-df9af6f5 emi-759e12a3 euca-10-111-75-103.eucalyptus.a-35.autoqa.qa1.eucalyptus-systems.com euca-10-111-75-107.eucalyptus.internal running account2-admin 0 m1.xlarge 2015-04-14T02:42:11.346Z thugmotivation101 monitoring-disabled 10.111.75.103 10.111.75.107 instance-store hvm sg-422ed69a x86_64
TAG instance i-df9af6f5 aws:cloudformation:logical-id CodeDeployInstance
TAG instance i-df9af6f5 aws:cloudformation:stack-id arn:aws:cloudformation::968367465792:stack/UbuntuCodeDeployTest/b210c81a-7e34-476f-9c59-7ea69ac9647a
TAG instance i-df9af6f5 aws:cloudformation:stack-name UbuntuCodeDeployTest
RESERVATION r-10df526e 968367465792 UbuntuCodeDeployAutoScalingTest-InstanceSecurityGroup-B2OVH0XWAFN5S
INSTANCE i-9b2b14e3 emi-759e12a3 euca-10-111-75-97.eucalyptus.a-35.autoqa.qa1.eucalyptus-systems.com euca-10-111-75-106.eucalyptus.internal running account2-admin 0 m1.xlarge 2015-04-14T02:42:05.939Z theinspiration monitoring-enabled 10.111.75.97 10.111.75.106 instance-store hvm d739a9eb-ba3c-4f16-940c-366a516cebfe_theinspiration_1 sg-556b10ce x86_64
TAG instance i-9b2b14e3 Name UbuntuCodeDeployAutoScalingTest
TAG instance i-9b2b14e3 aws:autoscaling:groupName UbuntuCodeDeployAutoScalingTest-ServerGroup-211FTERKLII6T
TAG instance i-9b2b14e3 aws:cloudformation:logical-id ServerGroup
TAG instance i-9b2b14e3 aws:cloudformation:stack-id arn:aws:cloudformation::968367465792:stack/UbuntuCodeDeployAutoScalingTest/2a5aefc6-c5c3-41e8-a9b4-a9ca095c1696
TAG instance i-9b2b14e3 aws:cloudformation:stack-name UbuntuCodeDeployAutoScalingTest
RESERVATION r-6c8a9642 968367465792 UbuntuCodeDeployAutoScalingTest-InstanceSecurityGroup-B2OVH0XWAFN5S
INSTANCE i-12f1a3a3 emi-759e12a3 euca-10-111-75-101.eucalyptus.a-35.autoqa.qa1.eucalyptus-systems.com euca-10-111-75-111.eucalyptus.internal running account2-admin 0 m1.xlarge 2015-04-14T02:42:05.872Z theinspiration monitoring-enabled 10.111.75.101 10.111.75.111 instance-store hvm 16a61ee7-d143-4f08-b926-c711ce335a1a_theinspiration_1 sg-556b10ce x86_64
TAG instance i-12f1a3a3 Name UbuntuCodeDeployAutoScalingTest
TAG instance i-12f1a3a3 aws:autoscaling:groupName UbuntuCodeDeployAutoScalingTest-ServerGroup-211FTERKLII6T
TAG instance i-12f1a3a3 aws:cloudformation:logical-id ServerGroup
TAG instance i-12f1a3a3 aws:cloudformation:stack-id arn:aws:cloudformation::968367465792:stack/UbuntuCodeDeployAutoScalingTest/2a5aefc6-c5c3-41e8-a9b4-a9ca095c1696
TAG instance i-12f1a3a3 aws:cloudformation:stack-name UbuntuCodeDeployAutoScalingTest

As we can see above, the Eucalyptus Cloudformation instances are tagged just as if they were running on AWS – again demonstrating the AWS compatibility desired by HP Helion Eucalyptus.

Now, look in the AWS Management Console, under the AWS CodeDeploy service. In the dropbox under ‘AWS CodeDeploy’, select ‘On-Premise Instances’:

Displaying the dropdown box options under the AWS CodeDeploy title — Displaying the dropdown box options under AWS CodeDeploy

Once that has been selected, the on-premise instances running on HP Helion Eucalyptus should show up as ‘Registered’:

Display of Registered On-Premise Instances for AWS CodeDeploy

Now developers can proceed with remaining steps of using AWS CodeDeploy to do an application deployment.

Conclusion

As demonstrated, the new feature in AWS CodeDeploy allows developers to gain a true sense of a hybrid cloud environment. This feature – along with HP Helion Eucalyptus’s AWS compatibility – makes it easy for developers and administrators to use the same toolset to deploy, manage and maintain both public and private cloud environments. Don’t forget – using AWS CodeDeploy with on-premise instances does have an AWS pricing cost associated with it. Check out AWS CodeDeploy Pricing for more details.

Enjoy!

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!

IAM Roles and Instance Profiles in Eucalyptus 3.4

October 15, 2013October 15, 2013 hspencer773.4, aws compatibility, aws iam tools, cloud computing, ec2-api-tools, Euare, euca2ools, euca2ools.ini, IAM, iam roles, instance profilesLeave a comment

IAM Roles in AWS are quite powerful – especially when users need instances to access service APIs to implement complex deployments. In the past, this could be accomplished by passing access keys and secret keys through the instance user data service, which can be cumbersome and is quite insecure. With IAM roles, instances can be launched with profiles that allow them to leverage various IAM policies provided by the user to control what service APIs instances can access in a secure manner. As part of constant pursuit for AWS compatibility, one of the new features in Eucalyptus 3.4 is the support of IAM roles and instance profiles (and yes, it works with tools like ec2-api-tools, and libraries like boto, which support accessing IAM roles through the instance meta data service).

This blog entry will demonstrate the following:

Set up an Eucalyptus IAM role
Create an Eucalyptus instance profile
Assign an instance profile when launching an instance
Leverage the IAM role from within the instance to access a service API (for this example, it will be the EC2 service API on Eucalyptus)

Prerequisites

To use IAM roles on Eucalyptus, the following is required:

A Eucalyptus 3.4 cloud – These packages can be downloaded from the Eucalyptus 3.4 nightly repo. For additional information regarding downloading nightly builds of Eucalyptus, please refer the Eucalyptus Install Guide (note: anywhere there is a “3.3” reference, replace with “3.4”)
User Credentials – User credentials for an account administrator (admin user), and credentials of a non-admin user of a non-eucalyptus account.

Apply an IAM policy for the non-admin user to launch instances, and pass roles to instances launched by that user using euare-useruploadpolicy. An example policy is below:

{"Statement": [
 "Effect":"Allow",
 "Action":"iam:PassRole",
 "Resource":"*"
 },
 {
 "Effect":"Allow",
 "Action":"iam:ListInstanceProfiles",
 "Resource":"*"
 },
 {
 "Effect":"Allow",
 "Action":"ec2:*",
 "Resource":"*"
 }]
}

AWS IAM CLI Tools and Euca2ools 3 – The AWS IAM CLI tools are for creating IAM roles and instance profiles; euca2ools for launching instances. There will be one configuration file for the AWS IAM CLI tools that will contain the credentials of the account admin user (for example, account1-admin.config). Euca2ools will only need the credentials of the non-admin user in the euca2ools.ini file (for example, creating a user section called account1-user01].

Creating a Eucalyptus IAM Role

Just as in AWS IAM, iam-rolecreate can be used with Eucalyptus IAM to create IAM roles. To create a IAM role on Eucalyptus, run the following command:

# iam-rolecreate --aws-credential-file account1-admin.config 
--url http://10.104.10.6:8773/services/Euare/ -r ACCT1-EC2-ACTIONS 
-s http://10.104.10.6:8773/services/Eucalyptus
# iam-rolelistbypath --aws-credential-file account1-admin.config
 --url http://10.104.10.6:8773/services/Euare/
arn:aws:iam::735723906303:role/ACCT1-EC2-ACTIONS
IsTruncated: false

This will create a IAM role called ACCT1-EC2-ACTIONS. Next, we need to add an IAM policy to the role. As mentioned earlier, the IAM policy will allow the instance to execute an EC2 API call (in this case, ec2-describe-availability-zones). Use iam-roleuploadpolicy to upload the following IAM policy file:

{
"Statement": [
{
"Sid": "Stmt1381454720306",
"Action": [
"ec2:DescribeAvailabilityZones"
],
"Effect": "Allow",
"Resource": "*"
}
]
}

After the IAM policy file has been created (e.g. ec2-describe-az), upload the policy to the role:

# iam-roleuploadpolicy --aws-credential-file account1-admin.config 
--url http://10.104.10.6:8773/services/Euare/ -p ec2-describe-az 
-f ec2-describe-az -r ACCT1-EC2-ACTIONS
# iam-rolelistpolicies --aws-credential-file account1-admin.config 
--url http://10.104.10.6:8773/services/Euare/ -r ACCT1-EC2-ACTIONS -v
ec2-describe-az
{
 "Statement": [
 {
 "Sid": "Stmt1381454720306",
 "Action": [
 "ec2:DescribeAvailabilityZones"
 ],
 "Effect": "Allow",
 "Resource": "*"
 }
 ]
}
IsTruncated: false

As displayed, the IAM role has been created, and an IAM policy has been added to the role successfully. Now its time to deal with instance profiles.

Create an Instance Profile and Add a Role to the Profile

Instance profiles are used to pass the IAM role to the instance. An IAM role can be associated to many instance profiles, but an instance profile can be associated to only one IAM role. To create an instance profile, use iam-instanceprofilecreate. Since the IAM role ACCT1-EC2-ACTIONS was previously created, the role can be added as the instance profile is created:

# iam-instanceprofilecreate 
--aws-credential-file account1-admin.config 
--url http://10.104.10.6:8773/services/Euare/ -r ACCT1-EC2-ACTIONS 
-s instance-ec2-actions
# iam-instanceprofilelistbypath --aws-credential-file acct1-user1-aws-iam.config 
--url http://10.104.10.6:8773/services/Euare/
arn:aws:iam::735723906303:instance-profile/instances-ec2-actions
IsTruncated: false

We have successfully created an instance profile and associated an IAM role to it. All that is left to do is test it out.

Testing out the Instance Profile

Before testing out the instance profile, make sure that the euca2ools.ini file has the correct user and region information for the non-admin user of the account (for this example, the user will be user01). For information about obtaining the credentials for the user, please refer to the section “Create Credentials” in the Eucalyptus User Guide.

After setting up the euca2ools.ini file, use euca-run-instance to launch an instance with an instance profile. The image used here is the Ubuntu Raring Cloud Image. The keypair account1-user01 was created using euca-create-keypair. To open up SSH access to the instance, use euca-authorize. Create a cloud-init user data file to enable the multiverse repository.

# cat cloud-init.config
#cloud-config
apt_sources:
 - source: deb $MIRROR $RELEASE multiverse
apt_update: true
apt_upgrade: true
disable_root: true
# euca-run-instances --key account1-user1 emi-C25538DA 
--instance-type m1.large --user-data-file cloud-init.config 
--iam-profile arn:aws:iam::407837561996:instance-profile/instance-ec2-actions 
--region account1-user01@
RESERVATION r-CED1435E 407837561996 default
INSTANCE i-72F244CC emi-C25538DA 0.0.0.0 0.0.0.0 pending account1-user01 0 
m1.large 2013-10-10T22:08:00.589Z Exodus eki-C9083808 eri-39BC3B99 
monitoring-disabled 0.0.0.0 0.0.0.0 instance-store paravirtualized 
arn:aws:iam::407837561996:instance-profile/instance-ec2-actions
....
# euca-describe-instances --region account1-user01@
RESERVATION r-CED1435E 407837561996 default
INSTANCE i-72F244CC emi-C25538DA 10.104.7.22 172.17.190.157 
running account1-user01 0 m1.large 2013-10-10T22:08:00.589Z Exodus eki-C9083808 
eri-39BC3B99 monitoring-disabled 10.104.7.22 172.17.190.157 
instance-store paravirtualized 
arn:aws:iam::407837561996:instance-profile/instance-ec2-actions
TAG instance i-72F244CC euca:node 10.105.10.11

Next, SSH into the instance and confirm the instance profile is accessible by the instance meta-data service.

[root@odc-c-06 ~]# ssh-keygen -R 10.104.7.22
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
[root@odc-c-06 ~]# ssh -i euca-admin.priv ubuntu@10.104.7.22
The authenticity of host '10.104.7.22 (10.104.7.22)' can't be established.
RSA key fingerprint is a1:b2:5d:1a:be:e3:cb:0b:58:5f:bd:c1:e2:1f:e3:2d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.104.7.22' (RSA) to the list of known hosts.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Welcome to Ubuntu 13.04 (GNU/Linux 3.8.0-31-generic x86_64)
* Documentation: https://help.ubuntu.com/
.....
Get cloud support with Ubuntu Advantage Cloud Guest:
 http://www.ubuntu.com/business/services/cloud
Use Juju to deploy your cloud instances and workloads:
 https://juju.ubuntu.com/#cloud-raring
0 packages can be updated.
0 updates are security updates.
ubuntu@ip-172-17-190-157:~$ curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-id
instance-type
kernel-id
local-hostname
local-ipv4
mac
placement/
public-hostname
public-ipv4
public-keys/
ramdisk-id
reservation-id
security-groups
### check for IAM role temporary secuirty credentials ###
ubuntu@ip-172-17-190-157:~$ curl http://169.254.169.254/latest/meta-data/iam/
security-credentials/ACCT1-EC2-ACTIONS
{
 "Code": "Success",
 "LastUpdated": "2013-10-11T18:07:37Z",
 "Type": "AWS-HMAC",
 "AccessKeyId": "AKIYW7FDRV8ZG5HIM91D",
 "SecretAccessKey": "sgVOgLJoc3wXjI5mu7yrYXI3NHtiq18cJuOT7Mwh",
 "Token": "ZXVjYQABQe4E4f2NnIsnvT/5jfpauKh3dClPVwPEoMepqk0lViODSgk4axiQb9rRQyU7Qnhvxb22wO201EoT6Ay/
rg+1i3+2xQLfbkh7kqy4CmqdGM3Q7LNI1dFPSz332E6us5BsSdHpiw3VGLyMLnDAkV8BMi+6lKE5eaJ+hpFI/
KXEVPSNkFMI9R+9bKPIFZvceiBE1w+kAEJC/18uCpZ0kSNy2iFBYcZ+zTwrYTgnsqNYcEIuWzEh4z1WIA==",
 "Expiration": "2013-10-11T19:07:37Z"
}

Install the ec2-api-tools from the Ubuntu Raring multiverse repository.

ubuntu@ip-172-17-190-157:~$ sudo apt-get update
Get:1 http://security.ubuntu.com raring-security Release.gpg [933 B]
Hit http://Exodus.clouds.archive.ubuntu.com raring Release.gpg
......
Ign http://Exodus.clouds.archive.ubuntu.com raring-updates/main Translation-en_US
Ign http://Exodus.clouds.archive.ubuntu.com raring-updates/multiverse Translation-en_US
Ign http://Exodus.clouds.archive.ubuntu.com raring-updates/universe Translation-en_US
Fetched 8,015 kB in 19s (421 kB/s)
Reading package lists... Done
ubuntu@ip-172-17-190-157:~$ sudo apt-get install ec2-api-tools
Reading package lists... Done
The following extra packages will be installed:
 ca-certificates-java default-jre-headless fontconfig-config
 icedtea-7-jre-jamvm java-common libavahi-client3 libavahi-common-data 
libavahi-common3 libcups2 libfontconfig1 libjpeg-turbo8 libjpeg8 liblcms2-2
 libnspr4 libnss3 libnss3-1d openjdk-7-jre-headless openjdk-7-jre-lib 
ttf-dejavu-core tzdata-java
......
Adding debian:TDC_Internet_Root_CA.pem
Adding debian:SecureTrust_CA.pem
done.
Setting up openjdk-7-jre-lib (7u25-2.3.10-1ubuntu0.13.04.2) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for ca-certificates ...
Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.
done.

Finally, run ec2-describe-availability-zones using the –url option to point to the Eucalyptus cloud being used.

ubuntu@ip-172-17-190-157:~$ ec2-describe-availability-zones 
-U http://10.104.10.6:8773/services/Eucalyptus/
AVAILABILITYZONE Legend 10.104.1.185 
arn:euca:eucalyptus:Legend:cluster:IsThisLove/
AVAILABILITYZONE Exodus 10.104.10.22 
arn:euca:eucalyptus:Exodus:cluster:NaturalMystic/

Thats it! Notice how there wasn’t a need to pass any access key and secret key. All that information is grabbed from the instance meta-data service.

IAM roles and instance profiles are quite powerful. Great use cases include enabling CloudWatch metrics, and deploying ELBs on Eucalyptus.

I hope this has been helpful. As always, any questions/suggestions/ideas/feedback are greatly appreciated.

More Mind Spew-age from Harold Spencer Jr.

Random Information – sometimes techie, sometimes not..

Menu

IAM