DevOps/SRE Best Practices: Hiding Provider Addresses, Minimal Dependencies, Service/Port Management, and Bastion Host Protection

This series shares DevOps/SRE best practices gathered from various project maintenance experiences, aiming to help both project stability and newcomers improve their operational skills.

Hide Service Provider Resource Addresses

Expose only proxy or load‑balancer endpoints instead of direct provider URLs or IPs, using CNAME or alias records to abstract the real resources; this enhances security, flexibility, and maintainability.

Pros:

High performance via CDN or proxy caching.

Improved security by obscuring backend details.

Scalability through unified entry points.

Better user experience with simple domain names.

Cons:

Increased system complexity.

Additional cost for load‑balancing services.

Implementation Tips:

Use load balancers that support TLS termination to avoid certificate mismatches (e.g., AWS ELB, GCP Load Balancing).

Design load balancers considering traffic, request types, geographic distribution, server types, and security requirements.

Install Only Necessary Dependencies and Tools

Keep systems minimal by installing only required packages, using minimal base images, package managers, and virtual environments; verify tool integrity via signatures or hashes.

Pros:

Higher performance and lower resource consumption.

Reduced storage costs.

Enhanced security by shrinking attack surface.

Easier maintenance.

Cons:

Increased operational complexity to identify essential components.

Potential functional limitations and higher maintenance effort.

Implementation Tips:

Choose minimal base images (e.g., slim Docker images) and use layered builds.

Clearly define system/application requirements before installing.

Leverage package managers (yum/apt, pip/poetry, npm/yarn, Maven/Gradle).

Use virtual environments to isolate dependencies.

Regularly audit and remove unused packages.

Run Only Necessary Services and Ports

Disable or uninstall services that are not needed and restrict external access to required ports; separate business and management ports.

Pros:

Reduced attack surface and improved security.

Better system performance by freeing resources.

Higher reliability with fewer failure points.

Simplified maintenance.

Cons:

May limit certain use cases (e.g., remote management).

Requires re‑evaluation and configuration when adding new features.

Analysis and testing needed to identify essential services, adding complexity.

Implementation Tips:

Only enable required services; uninstall or disable others.

Restrict external access using firewalls or ACLs.

Separate business and management ports and control access per port.

Use bastion hosts for internal resource access.

Use Bastion Host to Protect Internal Resources

A bastion host (jump server) acts as a secure gateway, allowing only authorized users to reach internal systems, while providing logging, auditing, and centralized access control.

Pros:

Enhanced security through authentication and authorization.

Simplified remote access management and audit logging.

Risk reduction by monitoring and isolating threats.

Improved compliance with standards such as PCI DSS and HIPAA.

Cons:

Potential single point of failure.

Performance impact if under‑provisioned.

Training requirements for administrators.

Complex deployment and integration with existing security tools.

Implementation Scenarios:

Remote access control for multi‑site enterprises.

Cloud security management for protecting cloud instances.

Third‑party access control for vendors and partners.

Internal access control for employee workloads.

Implementation Tips:

Design network architecture to place bastion hosts between external and protected networks.

Select appropriate bastion software based on features and scalability.

Apply strong authentication, password policies, and MFA.

Configure granular authorization and ACLs.

Enable comprehensive logging and audit trails.

Set up monitoring and alerting for abnormal activity.

Conduct testing and performance evaluation before production deployment.

Thanks to the contributors for authoring this chapter.