Gitops is breaking down boundaries between the CI and CD processes for infrastructure projects, ensuring that your cloud resources are always in sync with your coding base. The injection of IAC scans after code commit in CD phase causes disruption.
Prancer is a static code analyzer that verifies the security settings of Kubernetes configuration files in a non-disruptive way, even if they are deployed using GitOps. Prancer platform can connect to git repositories and perform security scans in CI phase before code commit to master. This move reflects Prancer’s commitment to extend the security through multiple platforms and “shift the security to the left” at the hand of developers. Now, let’s review some background information.
What is Kubernetes Config Connector (KCC) ?
The Kubernetes Config Connector (KCC) is a library that enables you to use the Google Cloud Platform (GCP) services from your Kubernetes clusters. The KCC provides a set of APIs and tools that make it easy to manage resources in GCP, such as instances, disks, and networks. Config Connector provides a collection of Kubernetes Custom Resource Definitions (CRDs) and controllers. The Config Connector CRDs allow Kubernetes to create and manage Google Cloud resources when you configure and apply Objects to your cluster. To get more information about KCC, review this link: https://cloud.google.com/config-connector/docs/overview
What is K8s admission controller?
The k8s admission controller is a piece of software that screens requests to the Kubernetes API server before the persistence of the object occurs, but after authentication and authorization have been achieved. It uses a Webhook and performs validations against the Kubernetes API Server. The webhook is an external service that receives requests for validation. The admission controller then calls this webhook if it requires information about a request, such as whether to allow or reject the request based on some custom logic implemented by you.
To get more information about Kubernetes Admission Controller, review this link: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
Challenges with KCC policy Controller
Many companies are using Kubernetes Gatekeeper and admission control project to apply security guardrails to the Kubernetes Object files. but they see some problems that we want to address here.
First of all, the GitOps approach is not scaling as the policy scanning happens at the CD instead of CI. With modern Shift-Left DevSecOps tools available from Prancer and other vendors, DevOps engineers now need a fast response. The way Gatekeeper project is working is at the CD time. it means when we are deploying the Kubernetes Object Files to the Kubernetes cluster, the admission controller kicks in and check for misconfiguration. This GitOps approach takes time and does not scale in a way the team can work in an agile manner.
The second problem is If multiple resources are getting deployed policy controller checks the resources in a sequence, deploys the resources with good config, and blocks the deployment when policy fails. This creates a limbo and operational nightmare to roll back the working state.
The last item we want to cover here is all of these things are adding additional loads on the KCC clusters. The cluster computing power should support the main functions and respond to the cluster users, but we are wasting that power for the controls and guardrails, which can easily be offloaded to the Static Code Analysis phase of KCC.
How Prancer can solve problems of the Kubernetes Admission Controller for KCC
Prancer Static Code Analysis engine can understand the details of the GCP KCC files and is the only provider capable of scanning KCC files. Prancer can scan the KCC files BEFORE you deploy them to the Kubernetes cluster. The scans will happen in the CI phase before handing over the code to CD for deployment. This is a new way of security integration with GCP and Kubernetes, allowing developers and DevOps engineers to catch misconfigurations at an early stage in the process, rather than waiting for the CD process to begins.
Since the code scanning is happening at the CI level, if a problem exists in the code, the pipeline fails and prevents any resource to be deployed to the Kubernetes cluster and GCP subsequently.
This early detection of misconfigurations and security vulnerabilities in the code gives developers a lot more control over their Kubernetes Configuration.
Prancer Static Code Analysis tool can understand KCC files and provide the list of issues before deployment to your GCP account. This approach is extremely effective when it comes to reducing operational overhead while increasing the productivity of developers.
To understand the current test cases related to GCP KCC files, you can review the Prancer compliance database at this link: https://github.com/prancer-io/prancer-compliance-test/tree/master/google/kcc