As containerization becomes the standard for modern application deployment, securing Docker and Kubernetes environments on self-hosted infrastructure has never been more critical. A single misconfigured container can expose your entire infrastructure to attacks, data breaches, and compliance violations.

This guide covers enterprise-grade container security practices for organizations running self-hosted infrastructure in Switzerland and beyond, with specific focus on compliance, isolation, and threat prevention.

Understanding the Container Security Landscape

Container security differs fundamentally from traditional VM or bare-metal security. Containers share the host kernel, making kernel vulnerabilities particularly dangerous. The attack surface includes:

• Container images: Vulnerable base images, outdated dependencies, embedded secrets
• Container runtime: Docker daemon, containerd, CRI-O configuration issues
• Orchestration layer: Kubernetes API exposure, RBAC misconfigurations, admission controls
• Network: Service mesh security, network policies, inter-pod communication
• Host security: Kernel vulnerabilities, shared resources, privilege escalation

1. Image Security and Supply Chain Protection

Use minimal base images: Start with distroless or Alpine images. Google's distroless images contain only your application and runtime dependencies—no package managers, shells, or unnecessary binaries.

FROM gcr.io/distroless/python3
COPY --chown=nonroot:nonroot app/ /app/
USER nonroot
CMD ["app.py"]

Scan images for vulnerabilities: Integrate Trivy, Clair, or Grype into CI/CD pipelines. Fail builds if critical vulnerabilities are detected:

trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest

Sign and verify images: Use Sigstore's Cosign or Docker Content Trust to cryptographically sign images and verify signatures before deployment:

cosign sign --key cosign.key registry.example.com/myapp:v1.0
cosign verify --key cosign.pub registry.example.com/myapp:v1.0

Private registry best practices: Host your own registry (Harbor, GitLab Container Registry) on Swiss infrastructure. Enable vulnerability scanning, access controls, and audit logging. Never pull images from untrusted public registries in production.

2. Runtime Security and Process Isolation

Implement least privilege: Run containers as non-root users. Drop unnecessary Linux capabilities:

apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true

Use AppArmor or SELinux: Enforce mandatory access controls. Define profiles that restrict system calls, file access, and network operations. For Kubernetes, use Pod Security Standards (restricted profile).

Runtime threat detection: Deploy Falco or Sysdig to detect anomalous behavior—unexpected shell spawns, modified binaries, privilege escalations, or suspicious network connections:

- rule: Terminal shell in container
  condition: spawned_process and container and proc.name = bash
  output: Shell spawned in container (user=%user.name container=%container.name)

Resource limits: Prevent denial-of-service attacks by enforcing CPU and memory limits. Use Kubernetes LimitRanges and ResourceQuotas to restrict resource consumption cluster-wide.

3. Network Security and Micro-segmentation

Network policies: Implement zero-trust networking with Kubernetes Network Policies or Calico. Deny all traffic by default, then explicitly allow required connections:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Service mesh encryption: Deploy Istio, Linkerd, or Cilium to enforce mTLS between services. All inter-service communication should be encrypted without application changes.

Egress controls: Restrict outbound traffic. Only allow connections to approved external services (package registries, APIs). Block all other internet access to prevent data exfiltration.

API gateway security: Use Kong, Traefik, or NGINX Ingress with rate limiting, authentication, and WAF capabilities. Deploy in Swiss data centers to keep all traffic within jurisdiction.

4. Secrets Management

Never embed secrets in images: Use external secret stores—HashiCorp Vault, AWS Secrets Manager, or Kubernetes External Secrets Operator. Rotate secrets automatically.

Kubernetes secrets best practices: Enable encryption at rest for etcd. Use RBAC to restrict secret access. Consider sealed-secrets for GitOps workflows:

kubeseal --format=yaml < secret.yaml > sealed-secret.yaml
kubectl apply -f sealed-secret.yaml

Workload identity: Use service accounts with minimal permissions. For cloud-native apps, leverage OIDC federation to eliminate static credentials entirely.

5. Kubernetes Security Hardening

Control plane security: Disable anonymous authentication. Enable audit logging. Use admission controllers (PodSecurityPolicy successor: Pod Security Admission).

RBAC least privilege: Grant minimum necessary permissions. Regularly audit roles with kubectl-who-can or rbac-tool. Avoid cluster-admin for service accounts.

API server hardening: Restrict access to the Kubernetes API. Use certificate-based authentication. Enable mutual TLS. Never expose the API server directly to the internet—use VPN or bastion hosts.

Node security: Keep nodes updated with security patches. Use hardened OS images (Bottlerocket, Flatcar Linux). Enable kernel security features (seccomp, AppArmor).

6. Compliance and Audit for Swiss Hosting

FADP compliance: Log all API access and mutations. Store audit logs in immutable storage for 12 months minimum. Ensure containers processing personal data remain within Swiss jurisdiction.

Data residency guarantees: Pin workloads to Swiss nodes using node selectors or taints. Verify cloud provider regions. For multi-cloud deployments, use geo-fencing policies.

Audit logging: Enable comprehensive Kubernetes audit logs. Forward to SIEM (Splunk, ELK) or compliance platforms. Track who deployed what, when, and with what permissions:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  verbs: ["create", "update", "patch", "delete"]

Vulnerability disclosure: Implement a responsible disclosure program. Monitor CVE databases for container-related vulnerabilities. Patch within 30 days of publication for critical issues.

7. CI/CD Security Integration

Shift-left security: Scan Dockerfiles for misconfigurations (hadolint), check IaC for security issues (Checkov, tfsec), run SAST on application code before building images.

Admission control: Use OPA Gatekeeper or Kyverno to enforce policies—block unsigned images, require resource limits, validate labels, prevent privileged containers.

GitOps security: Store Kubernetes manifests in Git with branch protection. Require code review for changes. Use ArgoCD or Flux with RBAC and SSO integration.

8. Incident Response and Recovery

Container forensics: Use sysdig capture or kubectl-debug to investigate compromised containers. Never restart suspicious containers—preserve evidence for analysis.

Automated response: Integrate Falco with response engines (Falco Sidekick, Lambda, Kubernetes Jobs) to automatically quarantine suspicious pods or revoke credentials.

Disaster recovery: Back up etcd regularly. Use Velero for cluster-level backups. Test restore procedures quarterly. Document incident response runbooks.

Container Security on SwissLayer Infrastructure

SwissLayer's Swiss-hosted dedicated servers provide an ideal foundation for secure container deployments:

• Data sovereignty: All infrastructure in Switzerland, subject to FADP (stronger than GDPR in many aspects)
• Network isolation: Private VLANs, 40Gbps connectivity for secure service mesh communication
• Compliance support: ISO 27001 certified data centers, audit logs, legal jurisdiction advantages
• Performance: NVMe storage for fast image pulls, high CPU core counts for parallel container workloads
• Control: Full root access, no hypervisor overhead, ability to implement custom kernel security modules

Self-hosting in Switzerland gives you complete control over the security posture, data residency, and compliance requirements that cloud providers cannot guarantee.

Key Takeaways

1. Defense in depth: Layer security controls—image scanning, runtime protection, network isolation, audit logging
2. Least privilege everywhere: Drop capabilities, run as non-root, restrict RBAC, enforce network policies
3. Automate security: Integrate scanning into CI/CD, use admission controllers, enable runtime threat detection
4. Compliance first: Swiss hosting for FADP compliance, immutable audit logs, data residency guarantees
5. Continuous improvement: Regular vulnerability scans, security audits, incident response drills

Container security is not a one-time configuration—it's an ongoing process of monitoring, updating, and responding to threats. With proper controls and Swiss-hosted infrastructure, you can achieve both agility and security.

Ready to deploy secure containers in Switzerland? Explore SwissLayer dedicated server plans with NVMe storage, 40Gbps connectivity, and Swiss data protection.