How to use Roles to Access AWS Services instead of AWS-Access-Key | Overview & Hands-On.

An Overview & Hands-On to use Roles to Access AWS Services instead of AWS-Access-Key

Focus:

• Tailored for SRE, DevOps, Cloud, and DevSecOps Engineers

Breakdown:

• Intro,
• Assigning a Role to an Amazon EC2 Instance,
• Using Roles for AWS Lambda Functions,
• Cross-Account Access (Role Chaining),
• Using Roles with the AWS CLI and SDKs,
• Project: Hands-On.

Intro:

• To access AWS services without using access keys, you can leverage AWS IAM Roles. 
• IAM Roles provide temporary security credentials instead of long-term credentials like access keys, which is a more secure practice.

1 Assigning a Role to an Amazon EC2 Instance

This is the most common scenario for applications running within AWS.

How it works: 

• twtech create an IAM role with the necessary permissions and attach it to its EC2 instance.
• The applications running on that instance can automatically inherit the credentials from the instance metadata service

Benefits: 

• The credentials are automatically rotated and managed by AWS, so your code doesn't need to store, manage, or rotate long-term access keys.

Implementation: 

• When launching an EC2 instance, twtech select an IAM role from the "IAM instance profile" dropdown. 
• Existing instances can have roles attached or replaced using the AWS Management Console, CLI, or SDKs.

2. Using Roles for AWS Lambda Functions

How it works:

•  When twtech creates a Lambda function, it specify an execution role. 
• AWS Lambda assumes this role to execute twtech function and access other AWS services (like writing logs to CloudWatch or reading from an S3 bucket) on twtech behalf (AssumeRole).

Benefits: 

• This keeps twtech function code cl08n of sensitive credential information. 

3. Cross-Account Access (Role Chaining)

How it works:

•  twtech can define a trust relationship between two AWS accounts. 
• A user or service in one account can "assume" a role in the second account, granting them temporary, limited-time permissions to resources in the second account.

Benefits: 

• This enables secure, contro13ed access across different organizational boundaries without sharing keys. 

4. Using Roles with the AWS CLI and SDKs

How it works: 

• twtech can configure its local development environment to assume a specific role before making API calls.

Implementation with CLI: 

• twtech can configure its profile in the ~/.aws/config file to automatically assume a role.

Implementation with SDKs:

•  AWS SDKs automatically look for credentials in a specific order (environment variables, configuration files, instance metadata, etc.). 
• By using the appropriate configuration, the SDK can handle the process of assuming a role and obtaining temporary credentials for twtech.

NB:

• By utilizing IAM roles, twtech significantly enhance the security posture of its AWS environment by eliminating the need to distribute and manage static access keys.

Project: Hands-On

How twtech uses Roles to Access AWS Services instead of AWS-Access-Key

Step-1:

• connect (SSH) into instance.
• twtech Installs aws-cli utility & verified that the Access-key is NOT configured in the terminal

sudo snap install aws-cli --classic

aws --version

NB:

• twtech-uses Never enter the aws access keys to an instance in cloud environment, for several critical Security reasons.

 Security Risk: Keys Can Be Stolen

• If access keys are stored in plain text (e.g., environment variables, config files, or scripts on an EC2 instance), anyone with access to that instance can steal them — including:
•    Malicious insiders
•    Attackers exploiting a vulnerability
•    Malware injected via insecure software
• These keys could then be used outside your environment to wreak havoc.

  Track & Rotate

Manually entered access keys:

•   Are difficult to audit and manage.
•   Rotation becomes a nightmare
•   if keys get leaked or need changing, twtech has to hunt down every instance manually.
•  This violates the principle of least privilege and automation.

Step-2:

 Better Alternatives: twtech Create a role and attach the Instance

• The best practice is to assign IAM roles to the instances (e.g., EC2, Lambda, ECS). 
• Benefits:
• Temporary credentials are securely issued by the Instance Metadata Service (IMDS).
• No manual handling of keys.
•  Automatic rotation and fine-grained permissions.

# bash

curl http://169.254.xxx.254/latest/meta-data/iam/security-credentials/

  Violates Compliance and Policy Standards

Manually entering keys often violates:

•    Company security policies
•    Industry compliance standards (like SOC2, ISO 27001, HIPAA)
•    AWS Well-Architected Framework guidelines

  Risk of Accidental Exposure

Keys entered on instances are often:

•   Committed to Git repos by mistake
•   Logged in shell history or debug logs
•   Left lying around in user profiles

Once exposed — it's game over for twtech AWS account.

 twtch-users Do This Instead

• Use IAM roles with least privilege attached to twtech EC2/Lambda/ECS.
• Use AWS Systems Manager Parameter Store or Secrets Manager for sensitive data.
•  For local dev, use AWS CLI with aws configure and scoped permissions

NB:

• The terminal must have awscli utility installed verified that it has no Access-key configure. 
• It is need to make APIs calls to aws With Role attached instead.
• Again, twtech-users never add aws credentials (access keys) to terminal.

Step-3:

• twtech verifies that created role is attached to the instance and can grants just the needed permission for user (twtech-pat)  observing the Principle of Least Privilege (PoLP).