AWS - Cross Account access using #IAM

Access multiple AWS accounts

Amazon says that you should have an account for different services, projects and clients.

This can get confusing very quickly, as you may end up with many many user ids and passwords.

There are many tutorials and follow-me videos on this topic but they can very confusing.

Personally I have found these two useful:

- https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

- https://www.youtube.com/watch?v=n1r9Fp7GKvk

How to do it?

Let's assume you have two accounts ROOT and CLIENT. (Most examples have dev and prod and the like, but that does not give the relationship).

The ROOT account is where you control all the users and the account that is your main account. The account that pays for everything.

The CLIENT project could be where you host some lambdas for a specific client. An account you want to keep separate.

Step #1 - Root account number

Take note of your ROOT account number.
This can be found at the top of this page in the console: https://console.aws.amazon.com/billing/home?#/account

Do the same for your other account.

Step #2 - Set up cross-account access in the ROOT

Log into your ROOT account.

In IAMS create a policy called CrossAccountAssumeRole.

All this role needs to do is allow all actions on STS and for all resources.

Create a group called CrossAccount with this role attached to it.

Place the users who you wish to be allowed cross-account access the new group.

Step #3 - Allow your other account to connect to the ROOT

Log in to your other account CLIENT.

Create a new policy for your cross-account user to be assigned when it assumes its role.

This is important as this is the role that will define what your other account is allowed to do.

It will not be a Group or User ... its a role!

A useful AWS defined policy for cross-account admin is ... AdminsitratorAccess ... so we will use this.

Click create Role;

Select the trusted entity as "Another AWS account";

This will ask you for an account id. This is the id of the ROOT account (step #1).

This is important as it is to establish trust between the CLIENT and the ROOT. 

And no I don't know why sub-accounts don't trust the ROOT account implicitly.

There are two checkboxes on that screen for MFA and external ID ... either ignore them or add MFA.

Attach as many or as few policies as you need the role to have.

You will be asked what the users who can have this are ... ignore this for now.

Call the role "MainAccountAdminRole".

You can create many roles this way and as you might create User groups the Roles can be for any purposes.

Step #4 - Assume the Position role

Now log out and back into the ROOT account;

On the menu bar under your login name will be the option "Switch Role";

You will be presented with a screen asking for Account.
This is the account CLIENT Id from step #1, ... type it in.

You are asked for the role ... this is the role you just created in step #3, .. "MainAccountAdminRole".

Add a nice display name ... "Client" and a colour.

Then click switch role.

And you are in!

Beware!

There are some bear traps along the way here so be mindful:

- The role in the CLIENT account can do anything it is assigned to do. So admin access could be dangerous

- The "Switch role" settings exist in your browser cache. So you will need to set up the switch roles for new browsers, etc.

-- Enjoy!

Cloud Usage Guidance

Cloud environments are great - they enable us to do things faster, experiment, work collaboratively, etc, etc. However, without care, cloud environments can also become security risks and burn through cash quickly.

Two of the most important principals are:
Security: Apply a least-privilege approach to cloud resources, i.e. only allow access to the people that need it. This means consideration of ports, IP addresses and user permissions that need to be granted access
Cost: Understand the cost of resources that you're creating and ensure they are destroyed when they're no longer required and, ideally, turned off or scaled-down (vertically and horizontally) when not in use

The following sections provide some guidance to consider when creating and using cloud resources. The principals behind the recommendations are agnostic of the cloud provider, albeit the implementation might differ slightly for each and examples given are more focused on AWS.
The intention is for everyone to be aware of the various considerations that apply to the use of cloud environments, even if you're just spinning up a single VM to learn about the cloud.

Security

We are not re-inventing the wheel, as there are many existing security practices for AWS and Azure, e.g. for AWS, it's worth checking these out:
https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf
http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

Network Security Considerations

It is critical that network security controls, especially Security Groups (in AWS) and Network Security Groups (in Azure), are implemented correctly and consistently to avoid creating holes, or vulnerabilities, in the security posture of your environments. This will also ensure that in the nightmare scenario of a security breach of a VM, the damage can be as limited as possible.

A few considerations, which mostly relate to IaaS, but should be considered for all environments are:

• Traffic should only be permitted to travel within and between networks on a least-privilege basis, particularly for those environments that contain client data or are connected to a client  network, only granting access to those security groups, IPs and protocols that are known, understood and trusted
• There should never be any Security Groups created with the default 0.0.0.0/0 for ALL protocols for outbound traffic. This applies to public and private subnets. For example, if a VM was hacked, it would be harder (i.e. slow them down, if not stop them) for the attacker to jump from that VM to another or use it for other nefarious activities, if non-essential outbound ports are not permitted - considering that SG rules are stateful, it's unlikely that you'll need outbound SSH (port 22) permitted on any server other than a jump/bastion server.
• Routing tables should ensure that traffic is only routed between subnets and VPCs that require it. Where possible, Security Groups should reference other Security Groups, rather than IP addresses directly when setting rules for the same or peered VPCs
• Inbound security group rules should IP whitelist all traffic unless there is a very strong reason not to,
  AND a comment should be added to describe exactly what that IP refers to. Usually, all traffic originating from a Client's office network or the client VPN will have the same IP address, so this should be used on all externally accessible ports/endpoints.
• In a more mature environment, it is preferable for security group rules to be scripted and regularly reapplied/enforced via automation to force people to formalise and document network access in scripts any avoid manually added rules that could adversely affect the security posture of the environment.
• When designing environments, or even doing PoCs with any kind of sensitive data or other information, use subnets to segregate public and private networks and consider how the servers and services are accessed, e.g. via jump/bastion servers, rather than directly connecting all servers to the internet (in an ideal world, automation of deployment, configuration, log access, etc would eliminate virtually all need for a user to log on to a server)

IAM Best Practices

• For EC2 instances always use IAM roles, never use regular access keys.
• Always grant least privilege. Build your policies as specific as possible. Avoid wildcard permissions. Also, see http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege.
• Do not use IAM users when using an account that has company SSO setup to access AWS
• Follow or create naming conventions

VPC Best Practices

• Always assign security groups to instances
• Consider using existing security groups before creating new ones, however, only re-use SGs across similar instances/services to avoid confusion and inadvertently adversely affecting the security of another instance by changing a shared SG
• For Security Groups, open only ports you really need to be opened and restrict access to these ports
• Avoid exposing instances to the Internet whenever possible
• Consider enabling Flow Logs (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
• Restrict egress traffic, avoid allowing outbound connections for any port to anywhere

EC2 Best Practices

• For opening access to the instance from the Internet use Elastic Load Balancer
• Always use HTTPS for publicly exposed HTTP-type services
• Enable access logs collection for your ELBs (https://aws.amazon.com/blogs/aws/access-logs-for-elastic-load-balancers/)
• For inter-service communication always route traffic only via a private network (meaning either instanceA→internal ELB→ instanceB or instanceA→InstanceB, but no instanceA→Public ELB→InstanceB)
• Use bastion servers to access instances via SSH/RDP

S3 Best Practices

• Always grant least privilege permissions to the bucket (http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html)
• Enable access logging (http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
• Use encryption whenever possible and makes sense (http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
• For accessing S3 buckets from inside the private network, use VPC S3 endpoint (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html)

Cost

• Some cloud services are effectively free with low usages, such as AWS Lambdas and Azure Functions, but others aren't. Therefore, please be mindful of the cost of the resources being created. The considerations should include:
• The size of the resource (e.g. for a VM, it's the number of CPUs and size of RAM; for disks, it's the type/speed and capacity)
• Whether the resource is charged all the time (see below)
• Whether the resource can be scaled down / turned off, when not in use
• Whether there are more cost-effective ways of achieving the same thing

This does not mean don't try or use certain services, it just means be mindful of the consequences.

AWS and Azure provide comprehensive pricing pages and calculators to help with this.

For example, for VMs:

• https://azure.microsoft.com/en-gb/pricing/details/virtual-machines/
• https://aws.amazon.com/ec2/pricing/

As mentioned above, the pricing models for cloud resources vary, here are a few different types:

• Charged whilst running - VMs are a good example of this (but their storage is usually billable even when the VM is shut down)
• Charged when used - Lambdas / Functions are a good example
• Charged until destroyed - RDS is a good example

It is also worth checking whether there are any free credits that are available.

Word of the Day

I read this today and thought it was very poignant after a conversation with my son & father.
One knew how digital systems operated & the other was scared of them. Interestingly neither knew or cared how they worked.

Born digital, In reference to people, is a description of individuals who have grown up with the current state of ubiquitous computing and communications, typified by technology like smartphones, social media and near-continuous Wi-Fi networks.
These individuals are sometimes described as "digital natives" - people for whom the current state is a natural and comfortable environment because they were born into that scenario and have known no other world. The term contrasts with "digital settlers" - people who didn't grow up with the current technologies but who have adopted them and adapted to the changing environment -- and "digital immigrants" - people who grew up without the current technologies and who have come to them so late that they are still largely baffled by them.
Demographics for digital natives are usually considered to include the Millennial generation (sometimes referred to as "Generation Y"), who came of age roughly around the turn of the 21st century, and the generation following them, sometimes referred to as Generation Z. Some researchers also include later-born members of Generation X, which preceded the Millennials.
Authors John Palfrey and Urs Gasser popularized the term in their 2008 book, Born Digital. According to Palfrey and Gasser, for digital natives, there is less recognition of geographical, cultural and workplace boundaries. The BYOD (bring your own device) trend, for example, is usually thought to be a result of the Millennials' desire to be constantly connected. The authors maintain that the traits, habits and expectations of digital natives mean that they require a new approach to education and workforce management.
The term born digital is also used in reference to things other than people. Born digital resources, for example are materials that were created in a digital format rather than created in an analog format and digitized, and a born digital company is one that has always used and embraced the same technologies that digital natives take for granted.

See: Born digital 

generatedata.com - Fake Your Data

Sometimes you need fake data for things like testing software, populating databases, creating realistic-looking mockups and so on. For text, we have lorem ipsum; but for everything else you have to do a bit of legwork. Human-data especially - like names, addresses, town names etc. - are particularly hard to fake because you need a semi-realistically looking data set.

Try the script online at generatedata.com

The AWS Well-Architected Framework

A repost from InfoQ but with a good PDF for later reading.

---

Amazon has published the AWS Well-Architected Framework (PDF), a guide for architecting solutions for AWS, with design principles that apply to systems running on AWS or other clouds.


Amazon has based the AWS Well-Architected Framework on four pillars and a number of design principles as outlined in short bellow.

Security. 

According to Amazon, security in the cloud regards 4 areas - Data Protection, Privilege Management, Infrastructure Protection, Detective Controls – and they recommend the following design principles to strengthen the security of a system:

• Apply security at all levels 
• Trace everything 
• Automate responses to security events 
• Secure the system at the application, data and OS level 
• Automate security best practices 

Reliability. 

This pillar represents a system’s ability to “recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.” The areas covered by reliability are Foundations, Change Management and Failure Management, and the paper recommends the following design principles:

• Test recovery procedures 
• Automatically recover from failure 
• Use horizontal scalability to increase availability 
• Automatically add/remove resources as needed 

Efficiency. 

This is about efficient use of CPU, storage, and database resources. It also covers the space-time trade-off, i.e. consuming more memory and disk space to solve a problem quicker or using less resources but solving it in more time. The design principles recommended are:

• Use advanced technologies 
• Deploy the system globally for lower latency 
• Use services rather than servers 
• Try various configurations to find out what performs better 

Cost Optimization. 

This is evidently about optimizing costs, eliminating unneeded or suboptimal resources. Cost optimization should consider matching supply with demand, using cost effective resources, keeping an eye on expenses, and lowering the costs over time. This can be done by:

• Transparently attribute expenditure 
• Use managed services 
• Buy computing resources in the cloud rather than hardware 
• Use the cloud for its pay-as-you-go policy 
• Do not invest in data centers 

The framework includes a list of questions to be used when assessing a proposed architecture, such as “How are you encrypting and protecting your data at rest?” or “How are you planning your network topology on AWS?”. The authors also provide their recommendations for addressing each of the problems mentioned in these questions, some of them applying only to AWS, others being valid for any cloud computing architecture.


This article has extracted the main points from the 56-pages whitepaper on architecting solutions for the cloud. For a detailed explanation of all the best practice.