DEV Community: Ganesh Boggarapu

What are Distroless Images

Ganesh Boggarapu — Fri, 10 Jul 2026 05:50:10 +0000

Traditional container images are often large because they include many components such as operating system packages, system dependencies, runtime libraries, application binaries, package managers, and shells. These additional components increase the image size and expand the attack surface, potentially introducing security vulnerabilities.

As image size increases, one of the primary benefits of containers—being lightweight and portable—is diminished. Larger images require more storage space, take longer to transfer across networks, and can increase deployment times.

Distroless images address this problem by including only the components required to run the application, such as runtime libraries and application dependencies. They typically exclude unnecessary tools such as shells, package managers, and debugging utilities. By reducing the number of installed components, distroless images are smaller, have a reduced attack surface, and provide a more secure and efficient runtime environment.

How is Ansible different from Chef & Puppet

Ganesh Boggarapu — Tue, 23 Jun 2026 07:59:44 +0000

Ansible is one of the widely used tools in DevOps automation for configuration management, especially when compared with Chef and Puppet. There are several reasons for its popularity.

Agentless approach: One of Ansible’s key features is its agentless model, which avoids the overhead of installing and maintaining agents on managed systems. It is easy to get started with, and it typically uses SSH key-based authentication for Linux/Unix systems.

YAML-based playbooks: Ansible playbooks are written in YAML, which is human-friendly and does not require learning a new programming language. This lowers the learning curve for DevOps engineers and fits well with tools such as Kubernetes and Docker.

Disadvantages: There are also some limitations when compared with Chef and Puppet.

Less declarative enforcement: Unlike Puppet, Ansible is often more task-oriented than declarative. This gives users more control over execution flow, but it is less focused on continuous state enforcement.

No continuous drift correction by default: Ansible does not continuously monitor and reconcile system state on its own. If someone changes a server manually, Ansible will not correct that change until you run automation again.

What is an .env file and why is it so important?

Ganesh Boggarapu — Fri, 12 Jun 2026 19:36:52 +0000

The .env file has all the critical details which we generally do not pass in the source code like API keys, passwords, secrets, environment variables, tokens. It is extremely important that we make sure we do not push .env files to public repositories as there is a strong chance of credentials and API keys going into the wrong hands.

Always add your .env files to your .gitignore file in to ensure they are kept safe. This will not let git push .env files to the github repository. The .env files will be kept in the .gitignore file whcih can be accessed by other teammates

Basics of AWS IAM: How to setup a Cloud Trail in your organization?

Ganesh Boggarapu — Tue, 14 Jun 2022 20:18:34 +0000

In this blog post, I am going to show you how to create a simple CloudTrail in AWS.

Cloud Trail: Cloud Trail is a service in AWS that logs in the activity of an event in an account. The logging can be done by anyone user/service/role and it generally logs management and data events.

Cloud Trail is activated by default and can store the latest 90 days events. If you want to log the trail in an S3 bucket then we need to create a trail.

Except for global services like STS, IAM and Cloud front the cloud trail is regional.

Now let us see a simple way to create a Cloud Trail.

2) Click on the 3 bars at the Top left corner and select trails. Then click on the new trail and enter the name of the trail you wish you give. There is an option to select "Enable for all accounts in my organization" use this if you wish you log the events across your organization in a single place. This can be done only if you create this trail in your management account.

3) I have chosen to untick both the log file SSE KMS Encryption and log file validation. Click Next.

4) I have left everything as default as I only want to log Management events.

5) Verify all the details mentioned in the next step and click create trail.

Give a few minutes for the cloud trail to collect logs on the activity done inside the AWS account.

6) Click on the S3 bucket to see the cloud trail logs that are generated in the account.

7) Over time logs get created in the S3 bucket and you can see the contents when you open them. Below is an example of the same.

This blog post was originally published on https://www.ganeshboggarapu.com/how-to-setup-a-cloud-trail/

Basics of AWS IAM: Users, Groups, Policies

Ganesh Boggarapu — Sat, 04 Jun 2022 12:22:38 +0000

This Blogpost is a simple primer or refresher on the basics of IAM like users, groups and policies.

IAM is a tool inside AWS that helps in managing all the aspects of your architecture related to identities, policies, etc.

Let us begin with IAM Policies.

IAM Policies: A policy is an object in AWS that when associated with an identity or resource defines its permissions.

For Eg: When a user Sam is Assigned an IAM policy he may get many new powers(permissions) and limitations as well. He may have access to many services and resources inside AWS at the same time his access can be limited at how he can use them.

There are two types of IAM policies:

Inline Policies
Managed Policies

Inline Policies are used only when special or exceptional permissions need to be applied. If a permission or policy needs to be applied only to a particular user/group then we assign an inline policy to it either at the time of creation of the identity or after its creation.

Managed Policies are of two types:

AWS Managed Policies: Managed by AWS
Customer policies : Managed by customers

When a policy is to be applied to a large no. of users or identities applying policies to each individual becomes difficult so we apply Managed policies.
Managed policies are reusable in the sense once they are created they can be applied to any user or group but when it comes to inline policies it is user/group-specific and it cannot be used elsewhere.

Another important aspect when it comes to applying policies is the order of precedence.

Explicit Deny
Explicit Allow
Deny

Explicit Deny>>Explicit Allow>>Deny

If a particular policy explicitly denies a user access to a resource that takes precedence over anything else where the user is explicitly allowed.
If there is no mention of explicit allow or deny AWS by default denies access to the resource.

IAM Users:- They are an identity used for anything requiring long-term AWS access. Eg:- Humans, Applications, or Service Accounts.

There can be 5000 IAM users per account. If you need more users then you can send an email to the AWS support to increase the no. of users.
An IAM user can be a part of 10 groups.

IAM Groups: IAM groups are containers for users.

There can be 300 groups per account. A resource policy cannot grant access to a group.
There is no default group as such with all users in one group. You can add all users in an A/C to one IAM group. There is no nesting of groups allowed in AWS.

IAM Roles

A role is an identity assumed for a small period of time.
IAM role is used when the identity(user/application) has multiple entities.
IAM role represents a level of access inside the AWS account.

There are two parts of an IAM Role

Trust Policy
Permission Policy

Trust Policy: This decided which identities assume a particular role.
If an identity is allowed to assume roles by the IAM then it gives them temporary security credentials.

These credentials are time limited. So everytime the temporary credentials are used, the access is checked against this permission policy.
We use IAM roles when external on-premise accounts try to access the AWS resources. They assume a role that gives temporary credentials to access these resources.