Browsed by
Month: September 2016

AWS get the current users ARN – Python

AWS get the current users ARN – Python

In writing scripts it is good to know who is running them. I create a lot of AWS python scripts. These examples are using python3 and boto3. I prefer to use the aws config profile for creating the sessions. It is easier on users and allows for multiple key pairs to be used and switched out easily.

devAWSSession = boto3.Session(profile_name=args.devProfile)

That works great for setting up a session, but what if you want to log the user behind that profile? Sometimes the profile names are not helpful. (I am looking at you “default”) The aws iam command has a get_user function that works great, if you have iam access. What if you don’t want all of your profiles to have IAM access, and you shouldn’t.

AWS provides another set of classes called “sts” or “Security Token Service”. With this service you can call get_caller_identity. This will give you back the account number, arn, and userid. However that is not the userid is not the user name you would expect, it actually returns the unique AWS user id. But the username is part of the arn. First let’s get the data, using the session from above:

mySts = myAWSSession.client('sts').get_caller_identity()
myArn = mysts["Arn"]

Now we have the complete arn “arn:aws:iam::123456789012:user/Bob”. So now we can do a normal split and get Bob from the arn:

myUser = myArn.split('/')[-1]

Now myUser = Bob

Super simple and easy

import boto3
import argparse

parser = argparse.ArgumentParser()

parser.add_argument("-m", "--my-profile", dest = "myProfile", default = "default", help="My AWS Profile")

args = parser.parse_args()

myAWSSession = boto3.Session(profile_name=args.myProfile)

mySts = myAWSSession.client('sts').get_caller_identity()
myArn = mySts["Arn"]
myAccount = mySts["Account"]
myUser = myArn.split('/')[-1]

print("My profile user: {}".format(myUser))
How to increase the root volume size using the aws cli

How to increase the root volume size using the aws cli

I love using the AWS CLI. It makes everything completely recreatable. I can add the commands to a run book, and presto, next time we need to spin something up we have the commands. No fumbling through the GUI, wondering which security groups or subnets to use. When the gremlins attack you will be in a lot better place with the cli commands documented.

Recently when spinning up a server I immediately got a warning about disk space on the root partition. That is odd, it did not come up in dev, but then again we don’t have Datadog running for our dev instances. I checked it out and it turns out that we install a lot of packages in this recipe. Just enough to put us over the 80% mark. My standard root partition is 8G. So now what? I couldn’t just leave it so I needed to figure out how to increase the root volume. I terminated the instance, and went back into our dev environment.

I am used to doing block mappings, and add them all the time:

aws ec2 run-instances \
--subnet-id subnet-99999999 \
--security-group-ids sg-99999999 \
--image-id ami-99999999 \
--key-name mykey \
--iam-instance-profile Name=my-default-ec2-role \
--instance-type t2.micro \
--block-device-mappings '[{"DeviceName":"/dev/sdb","Ebs":{"VolumeSize":5}}]' \
--output json

With the key there being the block device mappings. All root volumes are ebs volumes now, so it should be easy enough to change that, right?

Not sure if this would work I tested this in our dev account. It turns out it really is that simple, Just add another block mapping  for xvda and boom. It works like a champ

--block-device-mappings '[{"DeviceName":"/dev/sdb","Ebs":{"VolumeSize":5}}, {"DeviceName": "/dev/xvda", "Ebs": { "VolumeSize": 12 }}]'

When the instance booted it took the new setting and made the root partition 12G instead of the 8G that is default.