Topic: Understanding Custom Images & Server Hardening in Cloud Architecture

1. Default Image vs. Custom Image

Default Image (OS Provided)

When you provision a new Virtual Machine (VM) or instance in a cloud environment (such as OCI, AWS, or Azure), you typically start with a Default Image (e.g., Oracle Linux, Ubuntu, Windows Server).

• This is a "Plain Vanilla" or baseline operating system configuration.
• It contains only the core components and essential files required to run the OS.
• It does not include your organization's specific security policies, custom tools, or required packages (such as httpd, unzip, or monitoring agents).

Custom Image

A Custom Image is a personalized template created from an existing VM that already contains your specific configurations, software installations, and security patches.

• It acts as a "Golden Image" or a blueprint.
• Instead of configuring every new server from scratch, you capture the state of a fully configured VM and save it as a template.
• Any new VM launched from this Custom Image will instantly inherit all the pre-installed software and settings.

---

2. What is Security Hardening & a Hardened Server?

Security Hardening

Security Hardening is the process of securing a server by reducing its vulnerability surface (Attack Surface). A default operating system is built for general utility and may contain open ports, unnecessary services, or default credentials that pose security risks. Hardening involves:

• Disabling unnecessary services, daemons, and network ports.
• Installing and updating critical security patches and software (e.g., enterprise tools, firewalls, httpd, unzip).
• Restricting root access and enforcing strict password/SSH policies.

Hardened Server / Hardened Image

A Hardened Server is an instance where all security best practices have been successfully applied.

For example, suppose we create a new server and name it "Server with Hardened Image". This server will serve as our baseline VM—one that has been thoroughly fortified against security threats and fully complies with corporate security standards. Once this baseline server is validated, we capture its state to create our master Hardened Image, ensuring every future instance launched from it is automatically secure.

This image serves as a golden template for provisioning new instances, ensuring that every server launched from it starts with the same approved security configuration, reducing deployment time and maintaining security consistency across the environment.

---

3. The Purpose of Creating a Custom Image

Manually installing software and verifying security compliance on every single server is time-consuming, inefficient, and highly prone to human error. We create Custom Images for two primary reasons:

A. Automation & Validation

The core objective of making a Custom Image is Validation.

• Instead of running manual checks on every new instance, you manually install the required security software (httpd, unzip, etc.) on a single master VM just once.
• You validate that everything works perfectly and meets compliance standards.
• Once validated, you take a snapshot to create the Custom Image. This eliminates the need for manual validation on subsequent servers.

B. Scalability & Reusability

Once the Hardened Custom Image is ready, it becomes reusable at scale. No matter how many web servers or application servers you need to deploy in the future, you simply attach this specific Custom Image to the new VMs. This guarantees absolute consistency and uniform security across your entire cloud infrastructure.

---

4. Understanding the "Billable Size" (e.g., 8GB Billable)

When working with Custom Images in the cloud, you will often notice a metric like "8GB Billable" associated with your image.

📘 Note on Cloud Billing: While standard default OS images are often provided at no extra cost by the cloud vendor, storing a Custom Image requires dedicated cloud storage. When you install additional packages (like Apache/httpd, utilities, and security tools), the total footprint of the OS increases. The Billable Size represents the exact amount of data storage you are utilizing to save that custom configuration. You are billed for the storage space this template occupies in the cloud repository.

---

5. Comparison: Default Image vs. Custom (Hardened) Image

Feature	Default Image	Custom (Hardened) Image
Source	Provided by Cloud Vendor (Oracle, Ubuntu, etc.)	Created by You / Your Organization
Security Status	Out-of-the-box settings (Not Hardened)	Highly Secure (Fully Hardened)
Pre-installed Software	Only Core OS files	Custom Tools installed (httpd, unzip, etc.)
Deployment Time	High (Requires post-creation manual setup)	Instant (Ready for production immediately)
Validation Requirement	Must be manually validated on every server	Validated once during the master image creation

Steps to create custom image

Step 1: Before creating a custom image, install and configure all required applications, packages, and system settings on the source instance. This ensures that every new instance launched from the custom image will inherit the same pre-configured environment, reducing manual setup time and maintaining consistency across deployments.

sudo yum install -y curl zip telnet httpd

To verify the installation:

yum list installed httpd curl telnet unzip firewalld

Package Breakdown

• curl
  Command-line utility used to transfer data and interact with services over network protocols such as HTTP, HTTPS, and FTP.

• zip
  File compression and archiving utility used to package multiple files and directories into a single compressed archive.

• telnet
  Network troubleshooting tool commonly used to verify Layer 4 (TCP) port reachability and test connectivity to remote services during diagnostic and triage activities.

• httpd
  Apache HTTP Server package used to host and serve web content over HTTP/HTTPS. It is one of the most widely used web server applications for delivering websites and web applications.

Step 2: Create the Custom Image via OCI Console

After installing and configuring all required applications on the source instance, create a custom image from the OCI Console. The custom image captures the current state of the instance's boot volume, including the operating system, installed packages, configurations, and application setup. This image can then be used to quickly launch new instances with the same pre-configured environment.

Step 3: Now create a New Instance from the Custom Image

Once the custom image is available, create a new instance using the image as the source. This allows the new instance to inherit the same operating system, installed applications, configurations, and security settings captured in the custom image, ensuring consistent and repeatable deployments.

Step 4: Verify the Custom Image Configuration

Log in to the newly created instance and verify that all required software packages and configurations are already present. Since the instance was launched from the custom image, the pre-installed applications and system settings should be inherited automatically, eliminating the need for any additional installation or configuration.

Validate the setup by checking the installed packages and confirming that the required services are available and functioning as expected.

yum list installed httpd curl telnet unzip firewalld