iam on Alperen Doc

create-iam-user-and-group

Mon, 01 Jan 0001 00:00:00 +0000

Create IAM User and Group#

Navigate to the IAM dashboard. You can also use the search bar at the top of the console to find it.
Click on “Users” under “Access Management” in the menu on the left, then click “Create user.”
Give the IAM user a name like alperen-admin (using your own name).
Check the box “Provide user access to the AWS Management Console.”
Have AWS auto-generate an initial password, and leave the box checked to require a password reset on first login.
Create a new group for this user, called Administrators. Attach the AdministratorAccess policy to the group. Only the one policy is needed.
Assign the IAM user that you’re creating to the new group.
On the “Review and create” step, if everything looks right, click “Create user.”
Download the credentials CSV file. Note that AWS gives you a sign-in URL, the IAM username, and the initial password. The sign-in URL has your AWS account ID in it.

In the web console, log out of your root user, then log in as the new IAM admin user.#

Use the sign-in URL from the credentials CSV.
The account ID should be pre-populated on the sign-in page, but save the ID number in case you need it for any future logins.
Enter the username you created and the auto-generated initial password.
You’ll be prompted to set a new password for the IAM user. Create one and save it.
If prompted, set up MFA for the IAM user as well (not as critical as with the root user, but still recommended).

From this point on, use the IAM admin user unless a root user login is absolutely necessary. We’ll be learning a lot more about IAM and scoped security throughout this document.

identity-and-access-management

Mon, 01 Jan 0001 00:00:00 +0000

Identity and Access Management (IAM)#

At some stage in building a project on AWS, you’ll need to give other people (or perhaps automated systems) access to your cloud resources as well. IAM is how AWS controls access to resources: who can log in, and what they can do once they’re in.

Who are you? (Identity)
What are you allowed to do? (Access)

IAM uses a few core pieces:

create-iam-user

Mon, 01 Jan 0001 00:00:00 +0000

IAM Users#

Let’s make a new user! Each user gets a username/password or API keys to access AWS.

Users are long-lived identities: they stick around until you delete them. Once you create a user and give them credentials, those credentials will work until they expire or you revoke them.

Managing more than a handful of users manually is painful. If your company already uses something like Azure’s Active Directory or Google Workspace, you can use AWS Identity Center to integrate with those services and manage users more easily.

inline-policies-iam-user

Mon, 01 Jan 0001 00:00:00 +0000

Inline Policies#

Policies allow or deny actions on specific resources. They look something like this:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow", // <--- 1. Are we allowing or denying?
 "Action": [
 "ec2:Describe*" // <--- 2. Which API actions are affected?
 ],
 "Resource": "*" // <--- 3. Which targets are affected?
 }
 ]
}

A policy has three main parts:

Effect: Allow or Deny. Are we permitting or denying these actions?
Action: The action to allow or deny. There are thousands of these, like DescribeInstances, CreateBucket, or PutObject.
Resource: Which resources the action targets. For example, “all EC2 servers,” or perhaps the ARN of just a specific one.

Assignment#

Vincent Vega needs to see EC2 instances for a dashboard he’s building, but make sure he can’t break anything.

iam-groups

Mon, 01 Jan 0001 00:00:00 +0000

IAM Groups#

While inline policies are attached directly to a single user, the preferred way to manage permissions in AWS is to create groups and give them the policies (sometimes called customer-managed policies).

This DRYs up your permissions management and makes it much easier to ensure that everyone has only the access levels they need.

Let’s convert our inline policy into a customer-managed policy, then attach it to a group.

Assignment#

PatientPing’s CISO has “thoughts” about our inline policies. Per last week’s security review: no more inline policies on users.

iam-roles

Mon, 01 Jan 0001 00:00:00 +0000

IAM Roles#

Okay, so we can give our users (e.g. developers) access to AWS resources… but what happens when we need our application server to be able to access a resource? For example, an EC2 instance that needs to read from an S3 bucket?

We could create a user for our server, but by using a username and password, but we’ll eventually encounter this dreadful message:

Luckily, IAM has roles. A role is a temporary identity that can be used or assumed by trusted parties.

aws-iam-deny-policies

Mon, 01 Jan 0001 00:00:00 +0000

Deny Policies#

An explicit Deny policy always wins; even if other policies Allow the same action. This is your shield when you need to set absolute boundaries.

Follow the principle of least privilege: grant people and resources only the permissions they actually need, nothing more. So don’t “allow all actions by default” and then add Deny rules for dangerous actions. Prefer to add permissions as they’re needed.

That said, there are situations where Deny policies are helpful:

aws-ssm-parameter-store

Mon, 01 Jan 0001 00:00:00 +0000

SSM Parameters#

A ubiquitous problem with running applications in production is configuring servers and applications. For example:

Should the app run in debug mode?
What domain name should it expect?
Where should it send logs?

On our own machines, we often use environment variables: key-value pairs that are available to everything running in the local environment (e.g. EDITOR=nvim). In Kubernetes, we use ConfigMaps or Secrets to store configuration values.

AWS provides a vendor-specific solution in AWS Systems Manager Parameter Store (SSM parameters). It’s a centralized safe where you can keep configuration data, secrets, and parameters that your applications need. It provides:

accessing-ssm-parameters-from-ec2

Mon, 01 Jan 0001 00:00:00 +0000

Accessing SSM Parameters from EC2#

Storing parameters in the SSM Parameter Store is only half the equation. Your EC2 instances still need permission to retrieve them, which they can get through IAM. To allow an instance to access SSM parameters, you need to:

Create or attach an IAM policy that grants ssm:GetParameter permissions.
Attach that policy to the instance’s IAM role.

However, doing this for each individual parameter would get tedious, real quick. Instead, we can scope access with parameter names or path namespaces using a policy like this:

use-ssm-from-ec2

Mon, 01 Jan 0001 00:00:00 +0000

Use SSM from EC2#

At this point, everything should be in place for our Pinger server to pull its config values from SSM:

We created the params /DATABASE_URL and /CMO_NAME in the SSM Parameter Store.
We added an IAM policy patientping-ssm-access, allowing those params to be read.
That IAM policy is attached to the role patientping-ec2-readonly-role.
Our EC2 instance that runs the Pinger app is authorized to assume that IAM role.

And the Pinger app code is already configured to try to pull config from SSM before falling back to a .env file. So once we restart the app, it should “just work.”

iam on Alperen Doc

create-iam-user-and-group

Create IAM User and Group#

Create an admin-level IAM user for day-to-day account management. _This will be primary AWS login management user .#

In the web console, log out of your root user, then log in as the new IAM admin user.#

identity-and-access-management

Identity and Access Management (IAM)#

create-iam-user

IAM Users#

inline-policies-iam-user

Inline Policies#

Assignment#

iam-groups

IAM Groups#

Assignment#

iam-roles

IAM Roles#

aws-iam-deny-policies

Deny Policies#

aws-ssm-parameter-store

SSM Parameters#

accessing-ssm-parameters-from-ec2

Accessing SSM Parameters from EC2#

use-ssm-from-ec2

Use SSM from EC2#