[{"data":1,"prerenderedAt":320},["ShallowReactive",2],{"blog-en-gitlab-auto-devops-k3s-admission-controller-gate":3,"blog-related-en-gitlab-auto-devops-k3s-admission-controller-gate":271,"blog-en-gitlab-auto-devops-k3s-admission-controller-gate-alt":259},{"id":4,"title":5,"author":6,"body":7,"date":253,"description":254,"extension":255,"image":256,"locale":257,"meta":258,"navigation":259,"path":260,"seo":261,"stem":262,"tags":263,"__hash__":270},"blog\u002Fblog\u002Fen\u002Fgitlab-auto-devops-k3s-admission-controller-gate.md","Why GitLab Auto DevOps' 'It Just Works' CI Is the Closest Threat to Your Production K3s Cluster","Kubo Team",{"type":8,"value":9,"toc":239},"minimark",[10,15,23,31,34,53,62,66,72,79,88,97,106,110,116,132,141,148,152,158,165,170,190,194,203,207,210,214,217,220],[11,12,14],"h2",{"id":13},"the-trap-of-gitlab-auto-devops-it-just-works-no-setup-needed","The Trap of GitLab Auto DevOps \"It Just Works, No Setup Needed\"",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection01.webp",[16,24,25,26,30],{},"The moment you enable ",[27,28,29],"strong",{},"GitLab Auto DevOps",", security scans like SAST (static analysis) and DAST start running automatically. Vulnerability badges line up on the merge request screen, and teams breathe a sigh of relief: \"We're already doing DevSecOps.\" But there's a classic trap hidden here.",[16,32,33],{},"Imagine a team enables Auto DevOps, and a SAST scan flags a Critical-severity vulnerability. The job itself still finishes successfully, and the pipeline stays green. The reviewer never notices the warning badge on the merge request — or prioritizes the release deadline over it — and merges anyway. The result: a container image containing the vulnerability gets built, pushed to the registry, and deployed to the production K3s cluster without a single hitch.",[16,35,36,37,44,45,48,49,52],{},"As ",[38,39,43],"a",{"href":40,"rel":41},"https:\u002F\u002Fdocs.gitlab.com\u002Fuser\u002Fapplication_security\u002Fsast\u002F",[42],"nofollow","GitLab's own SAST documentation"," explains, SAST is a tool designed to \"detect vulnerabilities early in development, when the cost of fixing them is lowest.\" In other words, SAST's role is strictly ",[27,46,47],{},"detection"," — whether that detection is wired into the pipeline's pass\u002Ffail criteria to actually ",[27,50,51],{},"enforce"," anything is left entirely to how the user designs their pipeline.",[16,54,55,56,61],{},"What makes this worse is that, as of 2026, Auto DevOps is no longer the \"we handle everything for you\" product it once was. GitLab has deprecated several of the managed applications Auto DevOps used to provide in-cluster, such as Prometheus and WAF, ",[38,57,60],{"href":58,"rel":59},"https:\u002F\u002Fgitlab.com\u002Fgroups\u002Fgitlab-org\u002F-\u002Fwork_items\u002F4280",[42],"shifting toward operators bringing their own ingress, Prometheus, Cilium, and so on",". The assumption that \"just turning it on gives you a safe pipeline\" no longer holds.",[11,63,65],{"id":64},"passing-ci-and-safe-to-deploy-are-not-the-same-thing","\"Passing CI\" and \"Safe to Deploy\" Are Not the Same Thing",[16,67,68],{},[19,69],{"alt":70,"src":71},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection02.webp",[16,73,74,75,78],{},"Why does this trap keep happening? The root cause is that ",[27,76,77],{},"the security boundary of your CI\u002FCD pipeline and the security boundary of your Kubernetes cluster are two completely separate things"," — and that fact gets overlooked.",[16,80,81,82,87],{},"Container image vulnerability risk is far from a problem limited to a handful of popular images. According to Chainguard's research, \"",[38,83,86],{"href":84,"rel":85},"https:\u002F\u002Fthehackernews.com\u002F2026\u002F04\u002Fthe-state-of-trusted-open-source-report.html",[42],"The State of Trusted Open Source Report",",\" 96.2% of detected CVE instances occur outside the top 20 most widely used images. In other words, you should assume that unknown risk is always lurking somewhere in the mix of dependencies your organization actually uses.",[16,89,90,91,96],{},"As Wiz's security analysis points out, ",[38,92,95],{"href":93,"rel":94},"https:\u002F\u002Fwww.wiz.io\u002Facademy\u002Fapplication-security\u002Fci-cd-security-scanning",[42],"CI\u002FCD scan results are simply too voluminous to meaningfully reduce risk without prioritization",". The recommended approach is staged: keep feature-branch checks fast and non-blocking, while strictly gating Critical\u002FHigh findings on pipelines heading toward production. But Auto DevOps' default configuration doesn't automatically build that \"strict gate for production\" for you. Detection on the CI side and enforcement on the Kubernetes cluster side only connect if you deliberately wire them together.",[16,98,99,100,105],{},"How you close this \"gap between CI\u002FCD and the cluster\" is a hidden but important criterion when choosing a managed Kubernetes platform. If the cluster itself is a black box full of vendor-specific extensions, retrofitting a standard gating mechanism becomes difficult on its own. With a managed K3s environment like ",[38,101,104],{"href":102,"rel":103},"https:\u002F\u002Fkubo.hexabase.io\u002F",[42],"Kubo"," that preserves Pure Kubernetes, you can directly use the CNCF ecosystem policy engines discussed below.",[11,107,109],{"id":108},"building-a-checkpoint-between-the-pipeline-and-the-cluster-gate-design-with-admission-controllers","Building a \"Checkpoint\" Between the Pipeline and the Cluster — Gate Design with Admission Controllers",[16,111,112],{},[19,113],{"alt":114,"src":115},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection03.webp",[16,117,118,119,122,123,128,129],{},"The mechanism that closes this gap is Kubernetes' standard ",[27,120,121],{},"Admission Controller",". According to the ",[38,124,127],{"href":125,"rel":126},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fadmission-controllers\u002F",[42],"official Kubernetes documentation",", an admission controller is defined as a component that \"intercepts requests to the Kubernetes API server prior to persistence of the resource, but after the request is authenticated and authorized.\" In other words — no matter how loose your CI pipeline is, ",[27,130,131],{},"you can still apply a final check the moment a request reaches the cluster's API server.",[16,133,134,135,140],{},"What can admission controllers actually enforce? According to ",[38,136,139],{"href":137,"rel":138},"https:\u002F\u002Fwww.wiz.io\u002Facademy\u002Fcontainer-security\u002Fkubernetes-admission-controllers",[42],"Wiz's explanation",", you can consistently enforce cluster-wide policies such as restricting image pulls to approved registries only, rejecting pods that run as root, and rejecting pods that expose host ports. By splitting the roles — CI scanning handles \"detection,\" admission controllers handle \"enforcement\" — you finally close the gap where something was detected but the actual harm was never prevented.",[16,142,143,147],{},[38,144,146],{"href":102,"rel":145},[42],"Kubo Cloud"," runs on a Pure Kubernetes setup that doesn't hide the API server behind a vendor-specific management layer, so you can install and run standard policy engines like Kyverno or OPA Gatekeeper (introduced next) as-is, without extra licensing constraints. GitOps support comes standard as well, making it easy to manage your policy definitions themselves under ArgoCD or Flux.",[11,149,151],{"id":150},"from-detection-to-enforcement-three-implementation-patterns","From Detection to Enforcement — Three Implementation Patterns",[16,153,154],{},[19,155],{"alt":156,"src":157},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Fsection04.webp",[16,159,160,161,164],{},"There are several admission controller options, but regardless of which you choose, there are three implementation patterns worth prioritizing. The first thing to tackle is the ",[27,162,163],{},"highest-priority blocking gate",".",[166,167,169],"h3",{"id":168},"_1-turn-image-verification-into-a-blocking-gate-top-priority","1. Turn image verification into a blocking gate (top priority)",[16,171,172,177,178,183,184,189],{},[38,173,176],{"href":174,"rel":175},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fkyverno\u002F",[42],"Kyverno, a CNCF Graduated project",", has a feature that ",[38,179,182],{"href":180,"rel":181},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Fpolicy-types\u002Fcluster-policy\u002Fverify-images\u002Foverview\u002F",[42],"verifies that the cluster only accepts signed and attested images",". Similarly, ",[38,185,188],{"href":186,"rel":187},"https:\u002F\u002Fopen-policy-agent.github.io\u002Fgatekeeper\u002Fwebsite\u002Fdocs\u002Fconstrainttemplates\u002F",[42],"OPA Gatekeeper's ConstraintTemplate"," lets you enforce policy logic written in Rego\u002FCEL as reusable Constraints across the entire cluster. Getting a single rule in place at this layer — \"reject unsigned, unscanned images\" — is the highest-ROI first step you can take.",[166,191,193],{"id":192},"_2-minimize-rbac-for-ci-service-accounts","2. Minimize RBAC for CI service accounts",[16,195,196,197,202],{},"In setups where the CI pipeline deploys directly to the cluster, that service account's permissions are often far too broad. The ",[38,198,201],{"href":199,"rel":200},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Frbac-good-practices",[42],"official Kubernetes RBAC good practices"," recommend preferring namespace-scoped RoleBindings over ClusterRoleBindings, and avoiding wildcard permissions. Limiting the blast radius to a single namespace in advance is essential in case a CI service account is ever compromised.",[166,204,206],{"id":205},"_3-never-put-secrets-in-a-plaintext-configmap","3. Never put secrets in a plaintext ConfigMap",[16,208,209],{},"API keys and DB connection info passed as CI\u002FCD variables should be managed with Kubernetes Secrets or an external secrets manager like Vault — not ConfigMaps. It's unglamorous, but combining this with an admission-controller policy that \"rejects sensitive data written anywhere other than Secrets\" gives you both halves of detection and enforcement.",[11,211,213],{"id":212},"conclusion","Conclusion",[16,215,216],{},"There's nothing wrong with GitLab Auto DevOps' \"it just works when you enable it\" convenience on its own. The problem is mistaking that convenience for \"the cluster is safe too.\" Only by clearly separating detection on the CI side (SAST\u002FDAST) from enforcement on the cluster side (admission controllers), and deliberately designing a \"checkpoint\" between the two, does a DevSecOps pipeline actually become effective.",[16,218,219],{},"Start by applying one policy to your production cluster with either Kyverno or OPA Gatekeeper that rejects unsigned images. From there, expand step by step into RBAC minimization and a review of your secrets management — and the gap between CI\u002FCD and the cluster will steadily close.",[16,221,222,223,226,227,232,233,238],{},"If you're looking for a foundation where you can run these standard policy engines without lock-in, ",[38,224,104],{"href":102,"rel":225},[42]," is a K3s-based Pure Kubernetes platform that lets you implement the same design at over 40% lower cost than EKS\u002FAKS. GitOps and Helm are supported out of the box too, so automating policy rollout is easy to get started with. Check out the ",[38,228,231],{"href":229,"rel":230},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[42],"pricing plans"," to see the cost breakdown, or ",[38,234,237],{"href":235,"rel":236},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[42],"get in touch"," to talk it through.",{"title":240,"searchDepth":241,"depth":241,"links":242},"",2,[243,244,245,246,252],{"id":13,"depth":241,"text":14},{"id":64,"depth":241,"text":65},{"id":108,"depth":241,"text":109},{"id":150,"depth":241,"text":151,"children":247},[248,250,251],{"id":168,"depth":249,"text":169},3,{"id":192,"depth":249,"text":193},{"id":205,"depth":249,"text":206},{"id":212,"depth":241,"text":213},"2026-08-17","GitLab Auto DevOps runs SAST\u002FDAST automatically the moment you turn it on. But a scan 'running' and a vulnerable image never reaching your production K3s cluster are two completely different things. Here's how to build an audit gate between CI\u002FCD and the cluster.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fgitlab-auto-devops-k3s-admission-controller-gate\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fgitlab-auto-devops-k3s-admission-controller-gate",{"title":5,"description":254},"blog\u002Fen\u002Fgitlab-auto-devops-k3s-admission-controller-gate",[264,265,266,267,268,269],"k3s","kubernetes","gitlab","ci-cd","devsecops","admission-controller","lNym59vEzdONmZlPrY-j9CltS36O4rwe6ExS2UiaXok",[272,280,288,296,304,312],{"path":273,"title":274,"description":275,"date":276,"tags":277},"\u002Fblog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain","Anyone Can Rewrite an Image Tag. Why Kubernetes Needs Sigstore-Backed Signing to Prove Provenance","Container image signing explained: tags can be overwritten by anyone, and passing CI tests doesn't guarantee the image running in production is the one you built. Learn how Sigstore and Kyverno work together to reject unsigned images on Kubernetes\u002FK3s, integrated into a GitOps workflow.","2026-08-06",[264,265,267,278,279],"gitops","security",{"path":281,"title":282,"description":283,"date":284,"tags":285},"\u002Fblog\u002Fen\u002Fqa-to-devops-kubernetes-career-transition","A QA Engineer's 'Instinct to Break Things' Transfers Directly to Kubernetes Operations: The Fastest Path from Test Automation to a DevOps Career","The quality-gate mindset and test automation skills QA engineers already have map directly onto Kubernetes operations aptitude. Here's a realistic six-month roadmap for making the switch, and how to clear the biggest obstacle in the way.","2026-07-19",[265,264,286,267,287],"devops","career",{"path":289,"title":290,"description":291,"date":292,"tags":293},"\u002Fblog\u002Fen\u002Fcanary-release-kubernetes-auto-rollback-gitops","Why Every Team Ends Up at the Same CI\u002FCD Wall — Designing 'Safe-to-Break' Kubernetes Deployments with Canary Releases and Automated Rollback","Most production incidents happen because teams deploy everything at once. This article walks through how to design canary releases, automated rollback, and monitoring on Kubernetes using Argo Rollouts and GitOps — with practical steps small teams can actually sustain.","2026-07-15",[265,264,267,294,278,295],"canary-release","argo-rollouts",{"path":297,"title":298,"description":299,"date":300,"tags":301},"\u002Fblog\u002Fen\u002Fmlops-kubernetes-devops-ai-skills-2026","\"DevOps Engineers Are Becoming Obsolete\" Is a Lie. 5 MLOps Skills Every Kubernetes Operator Must Master in the AI Era","As AI automates infrastructure, are DevOps engineers really becoming irrelevant? The reality is the opposite — demand for MLOps Kubernetes talent is surging. Here are the 5 skills you need in 2026.","2026-07-11",[265,302,286,264,267,303],"mlops","ai-infrastructure",{"path":305,"title":306,"description":307,"date":308,"tags":309},"\u002Fblog\u002Fen\u002Fcicd-pipeline-security-devsecops","ci-cd Pipeline Security: A Practical DevSecOps Guide","A practical guide to ci-cd pipeline security from a DevSecOps perspective. Covers SAST\u002FDAST, supply chain protection, the SLSA framework, and Policy as Code.","2026-05-27",[268,267,279,310,311,265],"supply-chain","slsa",{"path":313,"title":314,"description":315,"date":308,"tags":316},"\u002Fblog\u002Fen\u002Fgitlab-ci-container-deployment","How to Automate Container Deployment with GitLab ci-cd","A practical guide to automating container deployment with GitLab ci-cd and the Kubernetes Agent. Covers pipeline setup, Auto DevOps, security, and multi-environment strategies.",[266,267,265,317,318,319],"containers","auto-devops","deployment-automation",1787649515867]