Containers / Cloud · Morocco & remote
Container & cloud security
Securing the layer your services actually run on: container images, Dockerfiles, Kubernetes workloads and the cloud account underneath them. Image scanning and vulnerability management with Trivy and Clair, hardening reviews for Docker and Kubernetes, and a look at the IAM and network paths that turn one compromised container into an account-level problem. Built for a production microservices estate at Invygo. Based in Morocco, available on-site and remote.
01 · What I test
The attack surface, end to end.
A container is only as contained as the host and the cloud identity around it. I assess the whole chain — from the base image in your registry to the IAM role the pod can assume.
IMAGE
Image & dependency scanning
Trivy and Clair wired into build and registry, tuned so the critical findings are visible instead of buried under base-image noise, with a vulnerability-management process attached.
BUILD
Dockerfile hardening
Root users, baked-in secrets, bloated base images, build-arg leakage and missing multi-stage builds — the defaults that quietly widen every container you ship.
K8S
Kubernetes workloads
Privileged containers, hostPath and hostNetwork, missing security contexts, Pod Security admission, resource limits, and the escape paths they open.
RBAC
RBAC & cluster identity
Over-permissive roles and service accounts, exposed dashboards and kubelet endpoints, and the service-account tokens that make lateral movement trivial.
NET
Network policy & segmentation
Default-allow east-west traffic, missing network policies, exposed ingress, and whether one compromised pod can reach everything else in the namespace.
CLOUD
Cloud IAM & exposure
AWS IAM roles and trust policies, over-broad permissions on pod identities, exposed storage buckets, metadata-service access and secrets handling.
Mapped to the CIS Docker and Kubernetes Benchmarks, NIST SP 800-190 and the OWASP Kubernetes Top 10.
02 · How an engagement runs
Scoped, manual, reproducible.
Inventory & scope
What's actually running: images, registries, clusters, namespaces and the cloud accounts behind them — including the workloads nobody has rebuilt in a year.
Image & configuration review
Scanning images and reviewing Dockerfiles, manifests, Helm charts and IaC against the CIS benchmarks, with findings prioritised by what's reachable and exploitable.
Cluster & IAM assessment
RBAC, service accounts, admission policy, network policy and cloud IAM — mapped as paths, so you see the chain from a compromised pod to the account, not just a config list.
Escape & lateral-movement testing
Where it's safe and in scope, proving the paths from inside a container: host access, cross-namespace reach and cloud credential theft.
Remediation & scanning handover
Hardened configuration and scanning integrated into your pipeline, with a vulnerability-management process your team can keep running after I'm gone.
03 · What you get
A report you can act on.
- A risk-ranked report covering images, workloads, cluster configuration and cloud IAM
- Attack paths drawn end to end, from a compromised container to the cloud account
- Hardened Dockerfile, manifest and policy recommendations you can apply directly
- Image scanning integrated into the pipeline with a tuned, triaged baseline
- A vulnerability-management process and a walk-through with your platform team
04 · Standards & who runs it
Grounded in the frameworks that matter.
- CIS Docker & Kubernetes Benchmarks
- NIST SP 800-190
- OWASP Kubernetes Top 10
- MITRE ATT&CK for Containers
At Invygo I built container image scanning and vulnerability management with Trivy and Clair, and worked with cross-functional teams on secure container deployment strategies for microservices running in production on AWS. It sits alongside the application-security side of the same role — 50+ vulnerabilities closed — which is what makes the container-to-cloud attack path readable rather than theoretical.
05 · FAQ
Questions worth asking first.
- What does a container security assessment cover?
- The full chain: the images you build and pull, the Dockerfiles that produce them, the Kubernetes workloads and cluster configuration that run them, and the cloud IAM and network paths around them. The output is prioritised by what an attacker could actually reach, not by raw CVE counts.
- We already scan our images. Isn't that enough?
- Scanning finds known vulnerabilities in packages. It says nothing about a privileged pod, an over-permissive service account, a default-allow network or an IAM role a container can assume. Those are the findings that turn one vulnerable image into a cluster-wide or account-wide incident.
- Which platforms and tools do you work with?
- Docker and Kubernetes, with Trivy and Clair for image scanning, and AWS as the primary cloud. The methodology — image, workload, cluster, identity — transfers to other managed Kubernetes and cloud providers.
- Is testing safe to run against a production cluster?
- Configuration and IAM review is read-only and safe to run against production. Active escape and lateral-movement testing is agreed up front and kept to a staging cluster or an agreed window, with a stop condition throughout.
- Can you help us manage vulnerabilities, not just find them?
- Yes — that's the part most teams actually need. I integrate scanning into the pipeline, triage the existing backlog into a workable baseline, and leave a process for owning new findings as base images change.
- Do you work with companies in Morocco?
- Yes. I'm based in Morocco, available on-site across the country and remote for clients anywhere. Reporting can be delivered in English or French.
One vulnerable image shouldn't cost you the cloud account.
Images, Dockerfiles, Kubernetes workloads, RBAC and the IAM role behind them — reviewed as one attack path. Tell me what you're running and I'll scope it.