Securing MariaDB Defaults
Fresh database installations often ship with permissive defaults, a common opening for attackers. Day 18 of the 100 Days of DevOps and Cloud challenge focused on hardening MariaDB on an EC2 instance and implementing a precisely scoped read-only IAM policy. The first step involves installing MariaDB Server on a Linux instance. For systems using YUM package manager, this is accomplished with the command:
sudo yum install -y mariadb-server
sudo systemctl enable --now mariadb
Enabling and starting the MariaDB service ensures it runs immediately and persists across reboots. However, this default installation is not secure. The critical follow-up step is to remove the convenience features that also represent security vulnerabilities. This is typically done using the mysql_secure_installation script. This script guides users through several essential security configurations:
- Setting a root password for MariaDB.
- Removing anonymous user accounts.
- Disallowing remote root login.
- Removing the test database and its access privileges.
- Reloading privilege tables to apply the changes.
Running mysql_secure_installation is paramount. It transforms a default, open-to-attack database into a more hardened system. The script's interactive prompts ensure that each security measure is considered and implemented, reducing the attack surface significantly. Without these steps, the database remains vulnerable to unauthorized access and data breaches, especially in a cloud environment where exposure can be amplified.
Granular AWS IAM for 'Read-Only' Access
The second part of the challenge addresses AWS Identity and Access Management (IAM), specifically creating a read-only policy for an EC2 instance. The common pitfall, as highlighted by the prompt, is that a policy labeled 'read-only' can still be too broad. Simply granting ec2:Describe* permissions allows an entity to view a wide range of EC2 configurations, which might be more than strictly necessary for a read-only role. True granular control requires defining permissions with extreme specificity. For a truly read-only scenario on EC2, one might only need to list instances, describe their state, and perhaps view basic network configurations, but not necessarily modify them or access sensitive details like instance metadata that could be leveraged for further exploitation.
A more appropriate read-only policy would focus on specific Describe* actions and potentially Get* actions that do not imply modification. For example, if the goal is simply to monitor the status of EC2 instances, the policy might include:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeVolumes",
"ec2:DescribeNetworkInterfaces"
],
"Resource": "*"
}
]
}
This policy allows describing instances, their tags, associated volumes, and network interfaces. It is still quite broad with "Resource": "*", and for even tighter security, one would apply resource-level permissions using ARNs. The key takeaway is that 'read-only' is a spectrum. A truly secure read-only role minimizes the information an entity can access, preventing it from being used as a pivot point for further attacks. This principle of least privilege is fundamental to secure cloud operations. It's not just about preventing writes; it's about limiting the visibility of sensitive configuration details that could inform an attacker's strategy. The challenge underscores the need to critically evaluate default permissions and to craft IAM policies that reflect the absolute minimum access required for a given task.
This approach contrasts with simply granting a broad wildcard like ec2:Describe*, which could inadvertently expose more than intended. For instance, details about security groups, VPC configurations, or even specific instance metadata might be accessible, providing an attacker with a more comprehensive map of the AWS environment. By specifying only the necessary Describe* actions, administrators ensure that the read-only role provides only the data essential for its intended function, thereby enhancing the overall security posture.