DEV Community: Bishal Chapagain

ENABLE EBS ENCRYPTION BY DEFAULT IN 30 SECONDS

Bishal Chapagain — Fri, 21 Nov 2025 08:09:01 +0000

The One Security Setting Every AWS Account Needs

We have all been there. You are in a rush to launch an EC2 instance. You click through the configuration screens, hit "Launch," and then realize... you forgot to tick the "Encrypt" box for the storage volume.

In the world of cloud security, human error is the biggest risk. But what if you could "future-proof" your account so that you never have to remember to click that button again?

There is a setting in AWS that takes literally 30 seconds to turn on, costs nothing extra to enable, and ensures that every single new hard drive (EBS volume) you create is encrypted automatically. Here is how to turn it on, why it matters, and the few things you need to know.
Why should you care?

Think of EBS Encryption by Default as automatically locking your front door every time you close it.

Peace of Mind: You don’t need to rely on your team remembering to encrypt data. AWS enforces it for you.

Compliance: If you are handling sensitive data (GDPR, HIPAA, etc.), encryption at rest is usually mandatory.

How to Enable it (The 30-Second Guide)

If you are familiar with AWS CLI, use the following command and it's done.

aws ec2 get-ebs-encryption-by-default --region <region>

Else, you don’t need to be a coding wizard to do this. Just follow these steps in the AWS Console.

1. Pick your Region

Log into your AWS Console.
Select your region from the top right corner.

Crucial: This setting is Region-Specific. If you work in both us-east-1 (N. Virginia) and ap-south-1 (Mumbai), you need to do this in both places.

2. Navigate to the EC2 service.

3. Find the Settings

Look at the navigation pane on the left side.
Scroll all the way down to the bottom and click on Settings

Click on the Data Protection and Security tab.
You will see a section called EBS Encryption.
Click Manage.

Check the Enable box.

Key Selection: You can leave it as the default (aws/ebs) or pick a Customer Managed Key (CMK) if you plan to share snapshots later.

Note: While the default key is free, AWS charges approx. $1/month to maintain a Customer Managed Key.

Click Update EBS encryption.

Done. That’s it. You are now secure by default.

Things to Consider Before You Switch It On

While this setting is fantastic for security, there are a few details you should know so you aren't surprised later.

1. It doesn’t fix the past

Turning this on acts like a fresh start. It encrypts every new volume you create from this moment forward. However, for your old volumes, you can’t simply turn on encryption for drives that already exist. You have to create a snapshot and copy it to a new drive to secure them.

2. It is Region-Specific

AWS settings often apply to just one specific location (Region). If you enable this in N. Virginia, it does not automatically turn on in Mumbai or Sydney. You need to repeat this process for every Region where you have servers.

3. Be careful with "Key Selection"

Default Key: It is totally free and auto rotated every year but you cannot share snapshots encrypted with this key to other AWS accounts.

Customer Managed Key (CMK): If you plan to share disk images with a client or a different production account later, you must create and use your own Customer Managed Key. AWS charges for using CMK and you are responsible for rotating it.

4. It is "All or Nothing"

Once you enable this for a Region, it applies to everything you create in that Region. You cannot disable encryption for just one specific volume later. This is actually a good thing; it prevents accidental loopholes in your security.

5. A note on storage costs

If you decide to clean up your old data by copying unencrypted snapshots to make them encrypted, be aware that AWS creates a full copy, not a partial one. This means you will be storing more data, which might result in a small increase in your storage bill.

Final Thoughts

Security doesn't always have to be hard. By enabling EBS Encryption by Default, you are removing the chance of human error and ensuring that your data remains locked tight, no matter who launches the instance.

Go do it now,it will take less time than finishing your coffee!

For more technical details or CLI commands, you can check the official AWS Documentation.

AWS Support: "We're here to help"

Bishal Chapagain — Sat, 19 Jul 2025 04:46:47 +0000

They said they’re “here to help.”

They meant help me cry more.

From Container to Root

Bishal Chapagain — Fri, 25 Apr 2025 17:18:04 +0000

Background

In many companies, employees are often provided with limited user privileges. These accounts often lack sudo or root privileges, preventing direct access to install packages or make system-wide changes. But what if you could break through these restrictions with a Docker container?

In this article, I’ll show you how I got root access onto the host all from within a container.

About Docker

Docker makes extensive use of cgroups and namespaces to provide containerization. These are core Linux kernel features that enable Docker to isolate and manage resources for containers effectively. Even with root inside a container, you can't affect the host system unless you explicitly allow it. Docker containers are isolated environments that share the host kernel but are otherwise sandboxed.

By running containers in --privileged mode and mounting the host filesystem, we effectively give the container god-mode access to the host. This is what we exploit in this method.

This method is tested on Ubuntu 24.04.2 LTS with Docker installed on it.

Disclaimer:

This method is dangerous as it breaks the isolation model of Docker.
One wrong move and you can corrupt your host system.

Steps

1. Run a Docker Container

First, run a privileged Ubuntu container with the host root directory mounted on it.

docker run -it --rm --privileged -v /:/mnt/host ubuntu:latest

Once inside the container, you can check the contents of the host root directory.

ls /mnt/host

2. chroot into the host system

The chroot command changes the apparent root directory for the current process and its children.
The directory /mnt/host becomes the new root for the processes. Thus, host files and directories can be accessed with an isolated bash shell.

chroot /mnt/host /bin/bash

Now, we’re in the host environment and can install packages or make other modifications as if we were logged in directly.

If it fails, check for missing binaries or libraries using strace.

strace -f chroot /mnt/host /bin/bash

3. Install packages

For this demo, let’s install python3.

4. Test it from your end

We can see a running Ubuntu container using docker ps command in the new terminal.
On testing, python3 has been successfully installed on our system.

5. Fixing DNS Issues

If you face any DNS issues inside the container, you can resolve this by manually setting the DNS.

echo "nameserver 8.8.8.8" > /etc/resolv.conf

How to prevent it?

When an employee gains unauthorized root access to a company's end device, the impacts can be severe, affecting security, operations and compliance.

The following ways can be considered for prevention :

Use Rootless mode

This is the safest way to run containers without risking the host system’s security as both Docker daemon and containers runs in rootless mode.
Leverage SELinux/AppArmor

Mandatory Access Control via SELinux or AppArmor prevents containers from accessing host paths, even if privileged.

Final Thoughts

This method granted me the freedom to act as root on a machine where I didn’t have direct access. However, never test this on critical systems.

Happy hacking!