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.

A problem with AWS: IAM Policies

Today I had an issue where I wanted to create a Power Developer user.
So I promptly went to the managed roles and used the Developer Power User and clicked apply.
It seemed ok until I attempted to look at Lambdas and I hit issue after issue with missing roles.
So I have created this policy and it seems ok so far:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "iam:ListRolePolicies",
               "iam:GetRole",
               "iam:ListAttachedRolePolicies",
               "iam:GetPolicy",
               "iam:GetPolicyVersion",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

The items in bold are the additional rights the policy needed for the Lamda console to work.

Ideally, this should be 'LambdaConsoleRole' or some such but I am still learning.

How To Use SSH to Connect to a Remote Server in Ubuntu VIA a BASTION

What Is SSH?

One essential tool to master as a system administrator is SSH.

SSH, or Secure Shell, is a protocol used to securely log onto remote systems. It is the most common way to access remote Linux and Unix-like servers, such as VPS instances.

In this guide, we will discuss how to use SSH to connect to a remote system.

It is often good practice to set up a Bastion server which is essentially a Gateway to other servers.

If you do this then you can configure your otheer servers to only allow SSH access from your Bastion ONLY.

This post is to help with that process...

 If stuck completly read this first ... https://www.digitalocean.com/community/tutorials/how-to-use-ssh-to-connect-to-a-remote-server-in-ubuntu

SSH connection via the Bastion

SSH into any instance should be done via the Bastion server.

SSH-ing from the Bastion server into a different server generally requires the Bastion public key to be in the authorized_keys in the target server.

Connecting to a new instance, where the Bastion public key is not in authorized_keys

Ensure that the security group for the new instance allows connection from the Bastion.

You can use SSH agent forwarding. This technique allows you to use a keypair to connect from the Bastion, without the private key needing to be on the Bastion.

You should know the keypair the new instance is created with. Open Pageant (on your PC) and import the keypair corresponding to your new instance.

Note: You know Pageant is running if you check the Notification Icons on your PC's task bar.

The other way you know it isn't running is if your Linux server gives the following error following issuing the ssh-add -L command:

In putty, connect to the Bastion using its private key, but in ”Connection → ssh → auth” check the box for Allow agent forwarding.

On the Bastion server, you can check that the key is available by calling:

  ssh-add –L

Now from the Bastion server, ssh into the target instance:

  ssh [PRIVATE IP OF TARGET INSTANCE]

Once you are here, add the Bastion public key to authorized_keys so that agent forwarding won't be required for future connections from the Bastion.

Or leave it as is to make things easy.

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.