DEV Community: Deepak Gupta

AWS IAM Management Best Practices: Structured Approaches for Scalable Access Control

Deepak Gupta — Mon, 16 Jun 2025 07:58:48 +0000

Today, let’s explore some practical approaches and best practices for managing AWS IAM. These recommendations aren’t mandatory but serve as strong foundational methods to structure both new and existing access management systems effectively.

To understand the core components and the importance of managing IAM beyond surface-level permissions please refer to [https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html]

Let’s dive into common patterns that are often overlooked, their limitations, and how to improve upon them.

1. Avoid Attaching Policies Directly to IAM Users
While AWS allows policies to be attached directly to IAM users, it’s not considered a best practice. Why?

Limitations:

AWS enforces a quota: only 10 managed policies (AWS-managed or customer-managed) can be directly attached to a user.

Even if raised via a support ticket, this can only be increased to 20, which isn’t scalable in larger environments.

Better Alternatives:

IAM Groups: Assign users to groups and attach policies to those groups. A user can be part of up to 10 groups, each of which can have 10 attached policies. This drastically increases policy flexibility and improves organization.

Inline Policies: These are tightly coupled with a specific IAM resource (user, role, or group). Although inline policies are not reusable, they offer flexibility when attaching unique or highly specific policies.

2. Group-Based Approach for Better Manageability
Beyond quota limitations, user-based policy assignments are harder to audit and manage.

Example Use Case:
Imagine needing to revoke a specific policy from several users at once. With direct attachments, you’ll need to update each user manually. With a group-based model, a single change at the group level can update permissions across multiple users.

Groups also allow you to categorize users by teams, environments, or responsibilities, making your access control setup more logical and maintainable.

3. Use Naming Conventions Wisely
While not enforced by AWS, standardized naming conventions are a powerful organizational tool.

Benefits:

Makes it easy to identify the purpose of a policy, role, or group at a glance.

Helps in filtering, sorting, and troubleshooting.

Simplifies tracking temporary or environment-specific resources.

Examples:

EC2Access-Prod-TeamA

S3ReadOnly-QA-temp-20240601

Naming Limits:

IAM resource names are limited to 128 characters.

Allowed characters include alphanumerics and a few special ones: +, =, ,, ., @, _, -.

4. Leverage Tags for Dynamic Filtering
Tags act as metadata in key-value format and are natively supported in AWS IAM.

Benefits:

Easily filter and group IAM users, roles, policies, and groups.

Enable cost tracking, auditing, and environment segregation in dashboards like CloudWatch.

Common Tags:

env=production

team=frontend

type=temporary

createdBy=automation

Tag Limits:

Up to 50 tags per IAM resource.

Keys: 128-character limit

Values: 256-character limit

Tags are especially helpful when naming conventions fall short, or when dynamic tracking and automation is involved.

Summary of Key Practices

Practice	Why It Matters
Avoid direct user policy attachments	Limited scalability, difficult to manage
Use IAM Groups	Simplifies bulk permission changes, scalable
Apply Inline Policies selectively	Useful for tightly scoped, unique access needs
Follow Naming Conventions	Improves readability, filtering, and governance
Use Tags	Enhances resource categorization and automation

Conclusion

These are some of the foundational best practices to consider when managing AWS IAM. While AWS provides the tools, how you use them defines your security posture, team efficiency, and scalability.

These strategies may not be mandatory, but they lay the groundwork for secure, flexible, and audit-friendly IAM architectures.

In the upcoming blog, we’ll dive into policy types, real-world use cases, and advanced IAM management techniques for large-scale setups.

Have a tip, lesson, or story around IAM? Share it in the comments—we’d love to learn how you’ve tackled IAM at scale!

aws #awscommunity #security #iam #enterprise #bestpractices #roles #policies

Docker BuildKit : Faster Builds, Mounts and Features

Deepak Gupta — Mon, 16 Jun 2025 07:50:54 +0000

It was like any other day working on micro-services project, running on Docker environment. In general, we’ve had worked on making our Image Builds more efficient, secure, and faster following basic aspects that significantly affect building and working with Docker.

Understanding Docker layers and structuring the Dockerfile to maximize their efficiency.
Reducing the weight of the Docker image, by being specific about our Base Image Tags which comes up with minimal packages.
Bringing the multi-stage builds concept, etc.
But keeping the spirits of being highly productive and improving more, I landed upon Docker BuildKit. Docker BuildKit is the next generation container image builder, which helps us to make Docker images more efficient, secure, and faster. It has been lingering in the background of Docker builds for some time. Moreover to enable and unleash some massive performance is to set the DOCKER_BUILDKIT=1 environment variable when invoking the docker build command, such as:

$ DOCKER_BUILDKIT=1 docker build .

In this post, we’ll walk through with some of its powerful features which I have explored and came up to these results as below :

Parallelism
Considering a Multi-stage Build, when BuildKit comes across a multi-stage build it get concurrency, it analyzes the docker file and create a graph of the dependencies between build steps and uses this to determine which elements of the build can be ignored; which can be executed in parallel; and which need to be executed sequentially. For example, the stages as build 1 and build 2 can be run in parallel as they don’t depend on each other however the final build stage depends on the other two so it will be build afterwards when both the other two stages are completed.

`FROM alpine AS build1
RUN touch /tmp/dee.txt
RUN sleep 10

FROM alpine AS build2
RUN touch /tmp/sandy.txt
RUN sleep 10

FROM alpine AS final
COPY --from=build1 /tmp/dee.txt /tmp/
COPY --from=build2 /tmp/sandy.txt /tmp/`

And for more checks I’ve added a delay of 10s to the build 1 and build 2 stages. When using the legacy build engine it executes top to bottom so it will execute two separate sleep commands of 10s which accumulates to a wait time of 20s, nevertheless using BuildKit it will execute both the sleep commands at the same time and therefore only accumulate a sleep time of 10s.

Hence, the standard Docker comes without concurrency in which build command performs builds on Dockerfile sequentially, which means it reads and builds each line or layer of the Dockerfile at a time and as a result it took 49.135s. Whereas BuildKit, allows for parallel build processing resulting in better performance and faster build times thus it only took 27.2s to build it.

Build Secrets Volumes
Sometimes we need some secret keys or password to run our build, just like credentials to access AWS S3 repository. In classic Docker builds there is no good way to do this; the obvious methods are insecure, and the workarounds are hacky. Therefore, BuildKit adds support for securely passing build secrets, which allows build container to access secure files such as secret access keys without baking them into the image.

syntax = docker/dockerfile:1.2

`FROM python:3

RUN pip install awscli

RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://walletprodtest/terraform ./ --recursive`

To build the image,

$ DOCKER_BUILDKIT=1 docker build --secret id=aws,src=/root/.aws/credentials .

The way BuildKit secrets work is that a file with the secret gets mounted to a temporary location during the RUN command, e.g. /root/.aws/credentials. Since, it’s only mounted during a particular RUN command, it doesn’t end up embedded in the final image.

BuildKit mount types doesn’t end only with secret, we have few more :

Cache Mount : Sick of re-downloading all external dependencies every time when there’s a change to only one of them, the cache mount can help us save time in the future. Inside of our Dockerfile, add a mount flag, specifying which directories should be cached during the step.
RUN --mount=type=cache,target=/var/lib/apt/lists …

SSH Mount : This mount type allows the build container to access SSH keys via SSH agents, with support for passphrases.
RUN --mount=type=ssh … etc.

Using these mount types features, makes it easier for us to pass build-time secrets, handle SSH credentials, and cache directories in between builds even if the layer needs to be rebuilt.

Remote Cache
This feature is an upgraded version from the --cache-from which was having problems such as images need to be pre-pulled, no support for multi-stage builds, etc. With BuildKit, you don’t need to pull the remote images before building since it caches each build layer in your image registry. Then, when you build the image, each layer is downloaded as needed during the build.

For example, keeping the Dockerfile same as used in Build Secrets Mount, we build the image using,

$ DOCKER_BUILDKIT=1 docker build -t dgupta9068/demo --secret id=aws,src=/root/.aws/credentials --build-arg BUILDKIT_INLINE_CACHE=1 .

$ docker push dgupta9068/demo
Now will make a small change in the Dockerfile by adding one more RUN command which will create a test directory. After this, prune the Docker system and try to rebuild the image using

$ DOCKER_BUILDKIT=1 docker build --cache-from dgupta9068/demo .

To use an image as a cache source, cache metadata needs to be written into the image on creation which was done by setting --build-arg BUILDKIT_INLINE_CACHE=1 when building the image.

After that, for the second fresh image build, we used dgupta9068/demo image as cache source by which BuildKit automatically pulled up all the cached layers and just executed the last RUN layer of creating a directory. And hence, ended in a faster build of the Docker Image.

In Conclusion
I hope this article will give a kickstart to use and knowing more about BuildKit and its features which will help you to simplify and speed up your Docker build workflows. If you want to learn more about fasten-docker-build , besides BuildKit – do checkout !

Till then keep building 🙂

Triggering Jenkins Jobs From Slack

Deepak Gupta — Thu, 15 Oct 2020 05:19:15 +0000

What about triggering your builds once you get an update from the Development Team on Slack and from their itself you triggered the job, so that all the needful can be done and reports added in your job configuration can be mailed back to developers!!!

So here we go :

In Jenkins go to configure page and create API token, which helps you to configure your Job to Trigger Build remotely where you mention your token name.
Coming to slack, in apps search for Slash Commands where you can configure and add to trigger build of your job from slack
In configuration, choose a command name of your choice and then click on add slash command integration.
Here you will make the entry in the URL mentioning your https://jenkins-user:token_no@jenkins_url/job/job_name/build?token=token_name
And at last, you can add an Autocomplete help task which helps you to find your added command easily while triggering, Click save. Go back to Slack and try run your command with the given name and your build will be triggered.

Hope You gonna try and make your builds easy to trigger. Keep Building

Code Coverage

Deepak Gupta — Mon, 21 Sep 2020 21:28:28 +0000

An introduction to code coverage

In this blog, you'll learn what is code coverage, in what stages does it help us and what is the need of it??

Code Coverage is a parameter under software testing which tells you the no. of lines of code that are successfully validated under a test procedure, which in turn, help us in analyzing/verifying the quality of our software code.

To Calculate :

Code Coverage Percentage = (Number of lines of code executed by a testing algorithm/Total number of lines of code in a system component) * 100.

Code coverage criteria :

1.Function Coverage -- The functions in the source code that are called and executed at least once.

2.Statement Coverage -- The number of statements that have been successfully validated in the source code.

3.Path Coverage -- The flows containing a sequence of controls and conditions that have worked well at least once.

4.Branch or Decision Coverage -- The decision control structures (loops, for example) that have executed fine.

5.Condition Coverage -- The Boolean expressions that are validated and that executes both TRUE and FALSE as per the test runs.

So does it mean higher the code-coverage % better is the code quality of your software program.

Noooh!!!

If we take 100% code coverage for any software program it says no bug, no defect and indicates that the test cases have covered all the criteria and requirements of software application.

But in this case we are clueless and blank to evaluate if the test case has met all range of possibilities or not, did the test cases cover the incorrect requirements or might have missed any important ones??!!

So if we see the software product is built on 100 % irrelevant code coverage then undoubtedly we're gonna compromise on quality.

Then what should we focus on?? Our focus should be on writing test scripts that aren’t fuzzy. Don’t focus on achieving 100% coverage , focus on how the analysis can be clubbed out with your robust test scripts which are gonna cover every functional and non-functional area of source code.

Where I Read

Feel free to connect and correct if wrong anywhere.

Branching Strategies

Deepak Gupta — Fri, 18 Sep 2020 10:55:58 +0000

Have new ideas but directly implementing them won’t bring the expected results always!!! Bugs , vulnerabilities can be anywhere so here BRANCHING STRATEGIES comes in the picture where different ideas and concepts are widely accepted and when all are tested and implemented on other environments then are finally merged to the master and released for production.

GIT FLOW : Firstly Designed by Vincent Driessen. In Driessen model ,there are 2 permanent branches :

· Master Branch : From where software is released for production

· Develop/Dev Branch : Branch where developers works on

Other Non-Permanent branches :

· Feature : Branch to develop new features

· Release : Branch support preparation of new production release

· Hotfix/Patch : Production issues branch that need immediate fix
before planned release.

So the workflow initially starts from the single develop branch. Developers create feature branches for each new feature and group of features. We can name feature branches based on the feature we are working on. These branches are merged with the develop branch. Once a mass or set of related features are built and merged , a new release branch is created. Release branch is now tested and defects are logged which are fixed over here itself and merged back to the develop branch. Once the team is confirmed with the quality of the release is good, a new master branch is created from the release branch. The master branch is tagged with the version and deployed to production. If any defect or bug comes then a hotfix branch is created from master to fix all those issues and merged back into master and released.

I hope this makes a bit of clear understanding. Feel free to connect and correct if wrong anywhere.

Security Matters!! ( SSL )

Deepak Gupta — Tue, 15 Sep 2020 16:39:25 +0000

SSL CERTIFICATE

Why and How???

Short Introduction

Security Do Matter!!!
As taking today’s real world scenario every other person, companies and organizations offer and do more online services and transactions, internet security becomes both a priority and a necessity of their online transactions to ensure that sensitive information – such as a credit card number, data,personal informations – is only being transmitted to legitimate online businesses and the person who could access it.
So,in order to keep customer information private and secure, companies and organizations need to add SSL certificates to their websites to enable secure online transactions.

What are SSL Certificates and Why do I Need Them?
SSL certificates are an essential component of the data encryption process that make internet transactions secure.They are who, which provide authentication to protect the confidentiality and integrity of website communication with browsers. In simple words,
1.SSL Certificate secures the data which is in transit between server and browser
2.It keeps the information private and secure.

The SSL certificate's job is to initiate secure sessions with the user’s browser via the secure sockets layer (SSL) protocol. This secure connection cannot be established without the SSL certificate, which digitally connects company information to a cryptographic key.

How SSL Certificates Work
1.A browser or server attempts to connect to a website (i.e. a web server) secured with SSL.
2.A copy of its SSL certificate is send by web server to the browser/server
3.The browser/server checks whether to trust the SSL certificate or not. If so, it sends a message to the web server.
4.The web server sends back a digitally signed acknowledgement to start an SSL encrypted session.
5.And finally, encrypted data is shared between the browser/server and the web server.

Benefits of Using SSL Certificates
1.First of all it utilizes, HTTPs
2.Safer experience
3.Protect both customer and internal data and personal information
4.Encrypt browser-to-server and server-to-server interaction and transmission
5.Increase security

Hope you got the basic understanding, feel free to connect and correct if wrong anywhere.

Basic Linux Commands

Deepak Gupta — Sat, 12 Sep 2020 18:17:45 +0000

File Management Commands:
1.ls (To list the files and directories stored in the current directory)
The command ls supports the -l and –a option which would help you to get more information about the listed and hidden files

2.cd ( To enter into a directory)
3.pwd ( to show print working directory)
4.mkdir ( to make a new directory)
5.cat (to print the content of the file)
6.head ( to print the lines from the top of a file, in default it prints 10 lines can use –n flag to print respective number of lines)
7.tail ( print lines from bottom of a file , similarly –n respective number of lines)
8.touch ( to create a text file)
9.rm (to remove file) and rmdir (to remove a directory)
These commands works when file or directory are empty. But if you want to forcefully remove a directory/file then use command
rm –rf name of directory/file
But be cautious while using this command as it completely delete the object. Preferably it’s not considered to be use.
10.cp ( to copy a file from source destination to a different destination)
cp /home/dee/file1.txt /home/deepak
(Source) (Destination)
11.mv ( to move a file from source to destination or to rename)
mv /home/dee/file1.txt /home/Deepak
(Source) (Destination)

     mv  /home/dee/file1.txt  /home/Deepak/files.txt
               (Old Name)             (New Name)

File Permissions Command:

Every file in Linux has the following attributes −
• Owner permissions − The owner's permissions determine what actions the owner of the file can perform on the file.
• Group permissions − The group's permissions determine what actions a user, who is a member of the group that a file belongs to, can perform on the file.
• Other (world) permissions − The permissions for others indicate what action all other users can perform on the file.

chmod o+wx testfile (permission given to other’s of write and execute for testfile)
chmod u+rw testfile (permission given to users of read and write for testfile)

The second way to modify permissions with the chmod command is to use a number to specify each set of permissions for the file.

0 || No permission || ---
1 || Execute permission || --x
2 || Write permission || -w-
3 || Execute and write permission: 1(execute)+2(write)=3 || -wx
4 || Read permission || r--
5 || Read and execute permission: 4(read)+1(execute)=5 || r-x
6 || Read and write permission: 4(read)+2(write)=6 || rw-
7 || All permissions: 4(read)+2(write)+1(execute)=7 || rwx

chmod 755 testfile

2.setfacl & getfacl : The command "setfacl" refers to Set File Access Control Lists and "getfacl" refers to Get File Access Control List. Each file and directory in a Linux filesystem is created with a specific set of file permissions for its access. Each user can have different set of file access permissions.

setfacl -m u:deepak:rwx 2.txt ( -m= modify , u=user )

getfacl 2.txt

Processes Management:

1.ps (easy to see your own processes by running the ps (process status)
Most used flag –f ( f for full) option, which provides more information

2.top (command is a very useful tool for quickly showing processes sorted by various criteria).
It is an interactive diagnostic tool that updates frequently and shows information about physical and virtual memory, CPU usage, load averages, and your busy processes.

3.kill (to kill the process running in background)]
$kill 6738 ( 6738 Process ID)
Terminated
Or
If a process ignores a regular kill command, you can use kill -9 followed by the process ID.

Search Commands (Pipes and Filters)

1.grep (to search for a particular string/word in a text file)

Sr.No. Option & Description
1 -v Prints all lines that do not match pattern.
2 -n Prints the matched line and its line number.
3 -l Prints the names of files with matching lines (letter "l")
4 -c Prints only the count of matching lines.
5 -i Matches either upper or lowercase.

2.find (can be used to find files and directories and perform subsequent operations on them)

find [where to start searching from] [expression determines what to find] [-options] [what to find]

3.locate (used to find the files by name)