IAM aws-user management: Users, Groups, Polices, Login-Alias

Great question:

why is it not the best practice for users to always use the root account, and why is IAM user account recommended. 

This touches the heart of AWS security best practices.

 Why it's not best practice to use the root account:

1. Too Powerful:
   The AWS root user has unrestricted access to everything in the AWS account. It can delete resources, shut down services, close the account, and bypass all IAM policies. It's like having the keys to the kingdom.
2. No Granular Control:
   Yous can’t apply IAM policies or permissions boundaries to the root account. That means you can’t limit its actions or scope — it's all or nothing.
3. Audit and Monitoring Risks:
   It's harder to track actions if multiple people share the root credentials. IAM users and roles can be monitored and logged with CloudTrail, so it's easier to know who did what.
4. Security Risk:
   If the root credentials are leaked or compromised, an attacker gets full access. Since the root user can’t be restricted like an IAM user, it's game over.

Why an IAM user or role is recommended:

1. Least Privilege Principle:
   IAM allows twtech-cloud engineer to assign only the permissions needed for a user or role to do their job. That reduces the blast radius if those credentials are compromised.
2. Fine-Grained Access Control:
   IAM policies give users precise control over what a user or service can do — from read-only access to full admin rights.
3. Auditing and Logging:
   IAM activities are logged in AWS CloudTrail, so you can trace actions back to a specific user or role.
4. Temporary Credentials:
   When using IAM roles with services like EC2, Lambda, or AWS SSO, organization can avoid long-term credentials and use temporary ones, reducing the risk of credential leaks.

Best Practices Summary:

•  Lock away your root credentials (enable MFA and store securely).
•  Don’t use the root user for everyday tasks.
• Create IAM users or roles with only the permissions they need.

Great question:  what is the difference between IAM group policy and inline policy?

Understanding the difference between IAM group policies and inline policies is crucial for managing AWS permissions effectively. Here's a breakdown:

IAM Group Policy (Managed Policy)

• Definition: A group policy is an AWS managed or customer managed policy that you attach to an IAM group.
• Reusable: These are standalone policies that can be reused across multiple groups, users, or roles.
• Easier to manage: Since they're centralized, it's easier to maintain, update, or audit.
• Examples:
• twtech can create a policy like AllowS3ReadAccess and attach it to multiple IAM groups.
• AWS also provides many pre-built managed policies like AmazonEC2ReadOnlyAccess.

Inline Policy

• Definition: An inline policy (for Tony who does belong to any group) is embedded directly into a single IAM user, group, or role.
• One-to-one relationship: It's tied specifically to the entity (e.g., a user, group, or role) and cannot be reused elsewhere.
• Use Case: Good for defining permissions that are unique to one entity or that should be tightly coupled to that entity.
• Lifecycle-bound: If you delete the user/group/role, the inline policy is deleted automatically.

 Key Differences at a Glance

Feature	Group Policy (Managed)	Inline Policy
Reusability	Reusable across entities	Bound to one entity only
Management	Easier to manage centrally	Harder to track and audit
Policy Type	Managed (AWS/customer created)	Embedded (inline)
Use Case	Shared/common permissions	Unique/tightly scoped permissions
Deletion	Separate from entity	Deleted with the entity

 Example Scenario:

• If twtech wants all developers to have access to read from S3 → twtech will attach a managed policy to a group like twtech-DevGroup.
• If twtech wants a specific developer (engineer-foncha) to have access to a particular S3 bucket → twtech will use an inline policy attached.

Project:

How twtech creates IAM User in aws.

search for aws service: IAM

select user , then create user:

Assign name to user and provide user access to the aws management console;

Create the Group (twtech-admin-group) and attach Permissions (Administrative permissions):

Assign name (twtech-admin-group) and policy (administrativeAccess) then create group.

verify that group is created:

Add users into the group (twtech-admin-group), so that assigned users inherit the policies defined for the group.

How twtech may add tags : (optional

Review  configuration and create user (twtech-pat)

Verify that user (twtech-pat) is created: UI

twtech-admin-group has one user (twtech-pat) 

NB: for this project, twtech-pat inherits the Permission policies of the group(twtech-admin-group policy)

How twtech-pat sign in with the created IAM user account 

Go to IAM Dashboard: 

How twtech Creates aliases for IAM users (twtech-pat)

we need the url to sign in as IAM user. (twtech-pat)

Using another browser, ( or another private windows of same browser) we can login with as IAM user with the alias url created: https://twtech-pat-v1.signin.aws.amazon.com/console

If the root account was login with google chrome, we may user mizilla firefox to login as IAM user (twtech-pat@ twtech-pat-v1)

twtech Successfully created: user, group, attach user and policies to the group, created an alias and use it to login to aws console. 

Addendum:

what happens when an IAM user is removed from the group initially assigned to?

When an IAM user is removed from a group, the following happens:

 Loss of Group-Attached Permissions

• The user immediately loses all the permissions that were granted via that group’s policies (both managed and inline).
• Any actions the user could previously perform due to group membership will now be denied, unless:
• The user has individual policies attached (inline or managed), or
• Is part of another group with relevant permissions.

What Remains Unchanged

• The user still exists in IAM.
• Any inline policies or managed policies directly attached to the user remain unaffected.
• The user's access keys, console login, MFA, roles, etc., are unchanged.

twtech-Example Scenario:

Before removal:

• twtech-foncha is in DevGroup.
• DevGroup has a policy: AmazonS3ReadOnlyAccess.
• twtech-foncha can read S3 objects.

After removal:

• twtech-foncha is removed from DevGroup.
• twtech-foncha can no longer read from S3, unless another policy (user-specific or via another group) grants that permission.

How twtech Protects IAM-users and IAM-Groups from being compromised.

Securing IAM users and groups is absolutely critical in protecting twtech AWS environment. Here are the best practices and strategies twtech uses to reduce the risk of compromise:

1. Use IAM Roles Instead of Users Where Possible

• Why: IAM roles are temporary, auditable, and often more secure.
• Use Case: EC2, Lambda, CI/CD pipelines — use roles instead of long-term credentials.

 2. Enable Multi-Factor Authentication (MFA)

• MFA is a must for all users, especially those with console access or privileged permissions (e.g., Admins).
• MFA for root user should be enabled immediately.

3. Least Privilege Principle

• Grant users only the permissions they need, nothing more.
• Avoid giving * permissions or AdministratorAccess unless absolutely required.

 4. Regularly Audit and Rotate Credentials

• Use AWS IAM Access Analyzer or Access Advisor to identify unused permissions.
• Rotate access keys at least every 90 days, and disable/delete unused keys.

 5. Monitor with AWS CloudTrail & CloudWatch

• Track all IAM activity via CloudTrail logs.
• Set up CloudWatch alarms for suspicious behavior:
• New user creation
• Policy changes
• Unusual login times or IPs

 6. Use Service Control Policies (SCPs) with AWS Organizations

• Use SCPs to limit what users/groups/roles can do across accounts, even if they have Admin permissions in a child account.
• Great for enforcing guardrails.

 7. As much as possible, avoid Inline Policies.

• Inline policies are harder to track and audit.
• Prefer managed policies for better visibility and reuse.

 8. Never Use Root Account for Daily Tasks

• Only use it for initial setup or break-glass scenarios.
• Lock it down with strong password + MFA.

9. Use Password Policies

• Enforce strong password requirements:
• Minimum length (12+ characters)
• Complexity
• Expiration period
• No password reuse

10. Automate with Infrastructure as Code (IaC)

• Use tools like Terraform or CloudFormation to control IAM at scale, prevent drift, and ensure consistent security posture.

twtech-insights:

Use IAM Access Analyzer

• Detects resources shared with external principals and gives twtech visibility into potential misconfigurations.

A good password policy balances strong security with usability — and AWS lets you enforce it through IAM password policy settings.

Here’s an example of a secure and practical AWS IAM password policy:

 Example: Good Password Policy Settings

Setting	Recommended Value	Why It Matters
Minimum password length	14 characters	Increases entropy (harder to crack)
Require uppercase letters	✅ Enabled	Ensures complexity
Require lowercase letters	✅ Enabled	Ensures complexity
Require numbers	✅ Enabled	Defends against dictionary attacks
Require symbols	✅ Enabled	Adds further randomness
Allow users to change password	✅ Enabled	Necessary for user self-service
Password expiration	90 days	Limits exposure if compromised
Prevent password reuse	Remember last 5 passwords	Prevents cycling old passwords
Hard expiry (optional)	❌ (can be enabled if stricter policy)	Forces password change on expiry

 

 AWS CLI Example to Set This Policy:

# bash

 aws iam update-account-password-policy \

  --minimum-password-length 14 \

  --require-symbols \

  --require-numbers \

  --require-uppercase-characters \

  --require-lowercase-characters \

  --allow-users-to-change-password \

  --max-password-age 90 \

  --password-reuse-prevention 5

Combine With MFA
Even with strong passwords, enabling MFA is
crucial — passwords alone are no longer enough to protect sensitive accounts.

Here is how Multi-Factor-Authentication (MFA) of key benefit to twtech environment

MFA (Multi-Factor Authentication) is one of the most powerful yet simple ways to enhance security in AWS (and anywhere, really). Here's why:

 Advantages of MFA

1. Extra Layer of Security

• MFA requires something you know (password) and something you have (MFA device/code).
• Even if a password is compromised, an attacker can't access the account without the MFA code.

2. Protects Against Credential Theft

• Phishing, keylogging, credential stuffing — all become far less effective when MFA is enforced.
• Especially important for accounts with sensitive access or admin rights.

3. Mandatory for Root Account Security

• AWS recommends enabling MFA for the root user as a top priority.
• The root account has full, unrestricted access, so compromising it is a huge risk.

4. Helps Meet Compliance Requirements

• MFA is often required for compliance with:
• HIPAA
• PCI-DSS
• SOC 2
• ISO 27001
• Enabling MFA can help you pass audits and avoid penalties.

5. Low Cost, High Impact

• AWS offers virtual MFA for free (e.g., Google Authenticator, Authy, etc.).
• Very little setup effort for a huge increase in security.

6. Can Be Enforced by Policy

• Use IAM policies or AWS Organizations SCPs to enforce MFA use for users performing sensitive actions.
• Can block actions unless MFA is authenticated:

# json

"Condition": {

  "BoolIfExists": {

    "aws:MultiFactorAuthPresent": "true"

  }

}

 twtech Real-Life Analogy

Think of it like a debit card:

• Your PIN is the password,
• The card is the second factor. Someone may know your PIN, but without the card — no access.

Here’s twtech solid rundown of IAM.

(Identity and Access Management)

 Guidelines and Best Practices in AWS—essential for security, compliance, and smooth operations in any cloud environment, especially in DevOps/DevSecOps-heavy setups:

 IAM Best Practices

1. Use Least Privilege Principle

• Only grant permissions needed to perform a task—no more, no less.
• Regularly review IAM policies and eliminate unused or overly broad permissions.

Use Access Analyzer to identify over-permissive policies.

2. Enable MFA (Multi-Factor Authentication)

• MANDATORY for all IAM users, especially root users and admins.
• Adds a crucial layer of protection against credential compromise.

3. Avoid Using the Root Account

• Use it only for initial setup or account-wide tasks like changing billing info.
• Create an IAM user or role with admin privileges for daily work.
• Lock down the root account with MFA and strong passwords.

4. Use IAM Roles Instead of IAM Users

• Roles are temporary, assumable identities—ideal for apps, services, and federated access.
• Use roles for:
• EC2 instance profiles
• Cross-account access
• AWS Lambda permissions
• Federated identity providers (SSO, AD, etc.)

5. Group Users and Assign Permissions to Groups

• Avoid assigning policies directly to users.
• Use groups (e.g., DevOps, Developers, Auditors) and attach policies to them.

6. Use Managed Policies Strategically

• Start with AWS managed policies to speed up setup.
• Move to custom managed policies as you define specific needs.
• Avoid inline policies unless absolutely necessary (they’re harder to track and audit).

7. Tag IAM Resources

• Use tags to track ownership, environments, or teams (e.g., Team:DevOps, Env:Prod).
• Helpful for audits, access reviews, and automation.

8. Rotate Credentials Regularly

• For access keys (if used), enable automatic rotation or rotate them manually.
• Monitor unused keys and deactivate/remove them.

9. Use IAM Access Analyzer

• Identifies resources that are shared publicly or with external accounts.
• Helps catch unintended access exposures early.

10. Audit with CloudTrail and IAM Reports

• Enable AWS CloudTrail to log all IAM activities.
• Use IAM Credential Reports and Access Advisor to monitor usage and tighten controls.

11. Implement Conditions in IAM Policies

• Use policy conditions like:
• aws:SourceIp to restrict IP ranges
• aws:MultiFactorAuthPresent to enforce MFA
• aws:RequestTag / aws:TagKeys for tag-based controls

12. Set Session Timeouts

• Define shorter session durations for high-privilege roles via DurationSeconds.
• Helps reduce the risk window if credentials are compromised.

 Tools to Help

• IAM Credential Report (Account-level)
• IAM Last Accessed (User-level)
• IAM Access Analyzer
• IAM Policy Simulator
• AWS Config + CloudTrail
• AWS Organizations SCPs
• AWS SSO with Identity Center