Cloud, Containers, Infrastructure, and Secrets

Cloud providers secure parts of the underlying service; customers remain responsible for their configurations, identities, data, application code, and chosen service model.

15.1 Cloud shared responsibility

Cloud providers secure parts of the underlying service; customers remain responsible for their configurations, identities, data, application code, and chosen service model. Exact boundaries differ by service.

15.2 Identity and permissions

Use least-privilege IAM roles and short-lived credentials.

Avoid shared administrator accounts.

Separate development, staging, and production identities.

Require stronger controls for privileged operations.

Review wildcard permissions and cross-account trust.

Log administrative changes.

Test credential revocation and recovery.

15.3 Secrets management

Keep secrets out of source code, images, client bundles, and logs.

Retrieve secrets at runtime from an appropriate secret store or workload identity.

Scope access and rotate credentials.

Avoid exposing secrets through environment dumps and crash reports.

Use different secrets across environments.

Have a documented compromise response.

Environment variables may be convenient, but they are not automatically a complete secrets-management solution.

15.4 Container security

Use trusted, minimal base images.

Pin image versions/digests when appropriate.

Scan images and dependencies.

Run as non-root where possible.

Drop unnecessary Linux capabilities.

Use read-only filesystems where feasible.

Avoid privileged containers and unnecessary host mounts.

Set CPU/memory limits.

Keep secrets out of image layers.

Sign and verify images where supported.

Rebuild and patch images regularly.

A hardened image and pod (configuration example) _Not run — no container runtime on the build machine. Pin the base image by digest in real builds, and supply secrets at runtime from the platform's secret store._

# Build stage
FROM python:3.13-slim AS build
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --require-hashes -r requirements.txt --target /app/deps
COPY src/ ./src/

# Runtime stage: minimal image, non-root user, no secrets baked in
FROM python:3.13-slim
RUN useradd --uid 10001 --no-create-home appuser
WORKDIR /app
COPY --from=build /app /app
ENV PYTHONPATH=/app/deps
USER 10001
EXPOSE 8080
CMD ["python", "-m", "src.server"]

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
resources:
  limits:
    cpu: "500m"
    memory: "256Mi"

15.5 Kubernetes and orchestration

Apply least-privilege RBAC.

Restrict service-account token use.

Use network policies where supported.

Protect the control plane and API server.

Configure pod security controls.

Encrypt and restrict access to cluster secrets.

Use resource quotas and admission policies.

Keep workloads and nodes patched.

Audit privileged workloads and host-path mounts.

Restrict egress and metadata-service access where appropriate.

15.6 Infrastructure as Code (IaC)

Review Terraform, CloudFormation, Kubernetes manifests, and equivalent configuration for:

Publicly exposed storage Overly broad firewall rules Excessive IAM permissions Disabled audit logs Public administrative endpoints Missing backup/retention policy

Use policy-as-code checks in CI and verify the deployed configuration, not only the source template.

A tiny policy-as-code check Output (CPython 3.13.1): Real tools (Checkov, tfsec/Trivy, OPA/Conftest, cloud-native policy services) apply hundreds of such rules. Check the deployed configuration too: templates and reality drift.

config = {
    "buckets": [
        {"name": "course-assets", "public": True, "encrypted": True},
        {"name": "student-uploads", "public": True, "encrypted": False},
    ],
    "firewall": [{"port": 22, "source": "0.0.0.0/0"}, {"port": 443, "source": "0.0.0.0/0"}],
    "iam": [{"role": "api", "actions": ["s3:GetObject"]}, {"role": "ci", "actions": ["*"]}],
}
PUBLIC_OK = {"course-assets"}           # documented exceptions

findings = []
for b in config["buckets"]:
    if b["public"] and b["name"] not in PUBLIC_OK:
        findings.append(f"bucket {b['name']}: public without an approved exception")
    if not b["encrypted"]:
        findings.append(f"bucket {b['name']}: encryption disabled")
for rule in config["firewall"]:
    if rule["source"] == "0.0.0.0/0" and rule["port"] not in (80, 443):
        findings.append(f"firewall: port {rule['port']} open to the internet")
for grant in config["iam"]:
    if "*" in grant["actions"]:
        findings.append(f"iam role {grant['role']}: wildcard actions")
print("\n".join(findings) if findings else "no findings")

bucket student-uploads: public without an approved exception
bucket student-uploads: encryption disabled
firewall: port 22 open to the internet
iam role ci: wildcard actions

15.7 Network and egress controls

Segment workloads, expose only required services, use private endpoints where appropriate, restrict outbound traffic, and monitor unusual egress. Network controls complement identity-based authorization.

15.8 Backup security

Encrypt backups, restrict access, isolate copies from production compromise, define retention, test restoration, and ensure backup deletion policies meet business and legal requirements. An untested backup is not a reliable recovery plan.

Lab

Create a containerized demo service with a non-root user, minimal image, resource limits, no baked-in secrets, dependency scanning, and a documented patch workflow.

Quiz

? In the cloud shared-responsibility model, who configures a storage bucket's public access?
- The cloud provider :: The provider secures the service; your configuration is yours.
+ The customer :: Configuration, identities and data remain the customer's responsibility.
- Nobody — it is private by default and cannot change :: It can be changed by anyone with permission.
- The CDN :: Unrelated.

? Which container settings reduce risk? (select all that apply)
+ Run as a non-root user :: Limits damage from a compromised process.
+ Drop all Linux capabilities that are not needed :: Shrinks what the process can do to the host.
+ Read-only root filesystem :: Prevents tampering with the image at runtime.
- Bake the database password into the image :: Secrets in layers are visible to anyone with the image.

? Are environment variables a complete secrets-management solution?
- Yes — they are not in the source code. :: They can leak through dumps, crash reports and child processes.
+ Not by themselves — access, rotation and leakage paths still need managing. :: The course says exactly this.
- Yes, if they are uppercase. :: Naming does not matter.
- Only on Kubernetes. :: Same concerns everyw
…