TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
🛠 TOOL OF THE DAY
docsify - A magical documentation site generator. Unlike GitBook, it smartly loads and parses your Markdown files and displays them as a website.
🧠 USE CASE
Designing Least Privilege AWS IAM Policies
Long before cloud infrastructures and AWS IAM policies existed, Jerome H. Saltzer and Michael D. Schroeder introduced the Principle of Least Privilege (PoLP) in their 1975 paper, The Protection of Information in Computer Systems.
This timeless work is a must read for any cloud engineer.
Designing least privilege AWS IAM policies requires precision, and I would like to establish the framework with the below flow glimpse.
Stage 1. Understand the IAM Policy Structure
An AWS IAM policy consists of:
Effect: Allow or Deny.
Action: Specifies the AWS service operations (e.g.,
s3:GetObject).Resource: Defines the AWS resources to which the policy applies (e.g.,
arn:aws:s3:::example-bucket).Condition (Optional): Adds restrictions based on IP, time, or tags.
You can find a greater variety of IAM policy examples here.
Stage 2. Start by Defining Roles
Roles group permissions for specific use cases. Use these examples as a starting point:
Viewer Role
Purpose: Read-only access for viewing resources.
Actions:
Describe*,List*
PowerUser Role
Purpose: Perform operations like reading and writing data but restricted from administrative tasks.
Actions:
Get*,Put*,Update*
Administrator Role
Purpose: Full access to manage resources, used sparingly for critical tasks..
Actions:
*
Stage 3. Define Actions with Granularity
Avoid using wildcards like * for actions.
Instead, specify only the required actions. For example:
Instead of: Action": "s3:*
Use:
"Action": [
"s3:ListBucket",
"s3:GetObject"
]Stage 4. Scope Permissions to Resources
Narrow permissions to specific resources:
Broad Resource: "Resource": "*"
Scoped Resource:
"Resource": "arn:aws:s3:::techops-bucket/*"For multiple resources, use arrays:
"Resource": [
"arn:aws:s3:::bucket1/*",
"arn:aws:s3:::bucket2/*"
]Stage 5. Use Conditions to Enforce Restrictions
Apply conditions to control when and how permissions are used:
By IP:
"Condition": {
"IpAddress": {
"aws:SourceIp": "192.0.2.0/24"
}
}By Time:
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2024-01-01T00:00:00Z"
}
}By MFA:
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}Stage 6. Test Policies
Example: Test whether
PowerUsercan accesss3:PutObjecton a specific bucket.
Debug AccessDenied errors with AWS CloudTrail to see blocked actions.
Stage 7. Map Roles to Users
Assign roles based on job functions:
Developers: Assign PowerUser for development accounts.
Ops Teams: Assign Viewer or PowerUser roles for monitoring and troubleshooting.
Admins: Assign Administrator role but limit access via session duration or MFA.
Use AWS Identity Center (IAM Identity Center) for centralized role assignments.
Stage 8. Monitor and Adjust Permissions
Audit roles periodically:
Identify unused permissions using CloudTrail.
Remove actions not accessed in the past 90 days.
On top of this, implement guardrails with Service Control Policies (SCPs).
You may even like:
Looking to promote your company, product, service, or event to 50,000+ TechOps Professionals? Let's work together.
