DEV Community

Cover image for 100 Days of DevOps and Cloud (AWS), Day 18: MariaDB's Secure Install, and Why 'Read-Only' Needs More Than ec2:Describe
Nnamdi Felix Ibe
Nnamdi Felix Ibe

Posted on

100 Days of DevOps and Cloud (AWS), Day 18: MariaDB's Secure Install, and Why 'Read-Only' Needs More Than ec2:Describe

The most secure version of a fresh install is the one with its convenient defaults stripped back out. New database software ships open enough to get you started fast, which is exactly the state an attacker is hoping to find. Day 18 was about closing that gap on MariaDB, then granting its mirror image on AWS access so narrow it can only look.

One Linux task, one AWS task. Install MariaDB and secure it, then write a read-only IAM policy for EC2. The tasks come from the KodeKloud Engineer platform.

MariaDB: install, then take the defaults away

sudo yum install -y mariadb-server
sudo systemctl enable --now mariadb
Enter fullscreen mode Exit fullscreen mode

Then the step that matters most:

# Strip the insecure defaults
sudo mysql_secure_installation
Enter fullscreen mode Exit fullscreen mode

This single command is the whole security story of a fresh MariaDB. Left alone, a new install has an empty root password, an anonymous user anyone can connect as, a test database open to everyone, and remote root login switched on. mysql_secure_installation walks you through removing every one of those. Skipping it is how databases end up reachable on the internet with no password, which happens far more than it should. With that done, create the database, user, and grants:

CREATE DATABASE kodekloud_db2;
CREATE USER 'kodekloud_cap'@'localhost' IDENTIFIED BY 'securepassword';
GRANT ALL ON kodekloud_db2.* TO 'kodekloud_cap'@'localhost';
FLUSH PRIVILEGES;
Enter fullscreen mode Exit fullscreen mode

MariaDB users have two parts: the name and the host they connect from. 'kodekloud_cap'@'localhost' is a different user from 'kodekloud_cap'@'%', even with the same name and password. localhost means local connections only, % means from any host. If the app connects locally, you grant to localhost, if it connects over the network, you grant to the remote host or %. Get this wrong, and you get access-denied errors that have nothing to do with the password. And FLUSH PRIVILEGES reloads the grant tables so the changes take effect now rather than after a restart.

IAM read-only: narrow enough to only look

On the AWS side, a read-only policy for EC2. This is the least-privilege idea from Day 16 pointed at a specific job, someone who needs to see the EC2 console but must not change anything.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:Describe*",
      "elasticloadbalancing:Describe*",
      "autoscaling:Describe*",
      "cloudwatch:Describe*",
      "cloudwatch:GetMetricStatistics",
      "cloudwatch:ListMetrics"
    ],
    "Resource": "*"
  }]
}
Enter fullscreen mode Exit fullscreen mode
aws iam create-policy \
  --policy-name ec2-readonly-console-policy \
  --policy-document file://ec2-readonly-console.json
Enter fullscreen mode Exit fullscreen mode

Here is the part I did not expect. ec2:Describe* on its own gives read-only API access, but it does not make the EC2 console usable. The console page pulls in load balancers, auto scaling groups, and CloudWatch metric graphs, and each of those is a separate service. Without elasticloadbalancing:Describe*, autoscaling:Describe*, and the CloudWatch read actions, the console throws permission errors across the page even though the core EC2 data loads fine. "Read-only for EC2" in practice means read access across the handful of services the console stitches together. AWS even ships a managed policy, AmazonEC2ReadOnlyAccess, that bundles exactly these, worth reaching for unless you need something trimmed or custom.

Two sides of the same discipline

MariaDB's secure install and a read-only policy are the same instinct facing opposite directions. One takes away access that was open by default. The other grants only the access a job genuinely needs. Both start from closed and open up on purpose, which is the reverse of how most work gets done: start open and lock it down later if anyone remembers.

So here is the Day 18 question. Would you rather begin locked down and grant access deliberately, or begin open and hope you close the doors before someone else finds them?

Day 18 down. Eighty-two to go.

Top comments (0)