Episode 26 — Safeguard 5.3 – Disable dormant accounts
Welcome to Episode 26, Control 4 — Cloud and Container Baselines, where we extend configuration management into modern infrastructure. As enterprises migrate workloads to virtualized and cloud-hosted environments, secure configuration becomes more dynamic yet equally essential. Cloud services and containers evolve quickly, often redeployed automatically and scaled in seconds. Without defined baselines, these environments can drift into insecure states faster than traditional systems ever could. Establishing clear configuration standards for cloud accounts, virtual machines, and container platforms ensures that automation operates within safe boundaries rather than amplifying misconfigurations at scale.
Cloud configuration baselines begin with clear objectives: enforce security consistency, reduce exposure, and verify compliance across all accounts and regions. The baseline defines mandatory controls for identity, networking, storage, and logging—ensuring that every new resource inherits secure defaults. Unlike fixed servers, cloud resources are created and destroyed constantly, so security must be embedded in creation templates, not applied afterward. The baseline should specify which services are approved, which features must always be enabled, and which configurations are prohibited. These objectives keep cloud operations predictable while preserving the agility that makes the cloud valuable.
Shared responsibility must be explicitly understood among all teams. In cloud environments, the provider secures the physical infrastructure and core platform, but customers remain responsible for their configurations, data protection, and access control. Confusion in this area leads to serious gaps: encryption might be available but disabled, or identity roles might remain overly permissive because teams assume someone else controls them. Clear documentation must outline which group—cloud provider, platform administrator, or development team—owns each security element. Aligning this understanding across departments ensures that every control is actively managed by someone, not assumed to be covered elsewhere.
Identity and access management settings are the foundation of every cloud baseline. Default configurations often grant broad privileges or leave unused accounts active. Hardening means enforcing multifactor authentication for all administrative users, disabling unused root credentials, and following least-privilege principles through roles and groups. Policies should restrict the creation of access keys and require short expiration times. Logging and reviewing identity changes should be mandatory. For containers, registry and orchestration accounts must also follow the same strict controls, with role-based permissions aligned to build, deploy, and operate phases.
Network controls define how traffic moves within and between environments. Secure cloud architecture uses isolated virtual networks, explicit routing tables, and controlled ingress and egress points. Each subnet should serve a defined purpose, such as public-facing web services or private databases. Network Access Control Lists and security groups must default to deny and allow only the minimum required ports. Peering, transit gateways, and cross-region links should use encryption in transit and restricted route propagation. Baselines should also define standard firewall rules, logging of flow data, and regular review of public IP assignments to prevent accidental exposure.
Storage encryption and public exposure checks guard against one of the most common cloud failures—open storage buckets or unencrypted volumes. Every storage service should require encryption at rest using enterprise-managed keys or provider-managed options that meet compliance standards. Automatic detection of publicly accessible objects, buckets, or shares should trigger alerts and, if possible, automated remediation. Regular audits of storage permissions ensure that only authorized users and services can access sensitive data. This combination of encryption and access validation ensures confidentiality even when systems are misused or compromised.
Secrets management and key rotation prevent sensitive credentials from being hardcoded or left unprotected. Cloud services provide secret vaults and key management systems to store passwords, tokens, and certificates securely. Baselines should require that no credentials appear in scripts, source code, or container images. Automatic key rotation should occur on a fixed schedule or upon personnel changes. All keys must have defined owners and expiration dates. Using centralized secrets management ensures that access can be revoked instantly without redeploying entire workloads, reducing both operational friction and exposure.
Compute images, agents, and updates define the operational integrity of virtual machines and containers. Each baseline should specify approved images with known provenance and required security agents—such as endpoint protection, vulnerability scanners, or configuration managers—preinstalled. Auto-patching or scheduled updates must be enabled where possible. Images should be versioned and stored in controlled repositories to ensure that new instances always launch from validated, up-to-date sources. This practice mirrors golden images in traditional environments but applies continuously through automated pipelines in the cloud.
Container registries, scanning, and provenance controls ensure that every image introduced to production is trusted. Registries must enforce authentication, restrict public access, and integrate vulnerability scanning tools that evaluate images for outdated packages and known exploits. The baseline should define minimum scanning frequency, severity thresholds for blocking deployment, and the process for remediating findings. Provenance—the chain of custody from source code to deployed container—must be documented through digital signatures or attestation metadata. This guarantees that only verified, signed images are allowed to run within orchestration platforms.
Runtime policies govern how containers and workloads behave after deployment. Isolation, resource limits, and least privilege are key. Containers should run as non-root users, with file systems marked read-only whenever possible. Network access between containers must be restricted to necessary communications, ideally through service mesh or network policies. Runtime security tools can enforce these rules and detect deviations, such as privilege escalation or unexpected system calls. Establishing clear resource limits prevents denial-of-service conditions and ensures fairness in shared environments. The goal is containment—each container should operate securely on its own, without influencing others.
Serverless functions, though lightweight, still require secure baselines. Permissions must follow the same least-privilege logic as traditional systems: functions should have access only to the specific resources they need. Environment variables, triggers, and event sources must be reviewed for potential data leakage. Logging and metrics should remain enabled for every invocation. Because serverless workloads scale automatically, misconfigurations can multiply instantly. A baseline that defines safe defaults for function roles, network restrictions, and input validation keeps this flexibility under control without impeding innovation.
Validation pipelines and policy as code convert security expectations into automated enforcement. Continuous integration and deployment tools can evaluate configurations against approved baselines before any change reaches production. Policy as code frameworks allow rules—such as “all storage must be encrypted” or “no public subnets without approval”—to run automatically during deployment. Violations block the release until corrected. This automation ensures that security controls keep pace with rapid development and eliminates the reliance on manual checks after the fact. It also produces audit trails showing that compliance was verified before deployment, not assumed afterward.
Evidence of cloud and container baselines often includes configuration snapshots, compliance dashboards, and automated reports from cloud security posture management tools. Reviewers expect to see proof that encryption, logging, and access controls are enforced across all accounts and environments. Screenshots or exports from policy-as-code pipelines show pre-deployment validation in action. When properly organized, this evidence demonstrates not only adherence to standards but the maturity of automation and monitoring processes that maintain those standards continuously.
Cloud and container baselines mark the evolution of configuration management from static templates to dynamic, self-enforcing systems. They combine automation, visibility, and accountability in an environment where change is constant. By embedding security into every creation pipeline, organizations prevent drift before it begins. In the next stage, we will focus on drift detection—how to spot and correct the subtle changes that erode these protections over time, ensuring that cloud and container security remains not only configured, but continuously verified.
