ksonnet VS gke-policy-automation

There was a tool called ksonnet for this (jsonnet + a default library for k8s configs), but the company behind it got bought and it's no longer maintained: https://github.com/ksonnet/ksonnet

HybridK8s Droid - Intelligence foor your favourite Delivery Platform Devtron - Software Delivery Workflow for Kubernetes Skaffold - Easy and Repeatable Kubernetes Development Apollo - Apollo - The logz.io continuous deployment solution over kubernetes Helm Cabin - Web UI that visualizes Helm releases in a Kubernetes cluster flagger - Progressive delivery Kubernetes operator (Canary, A/B Testing and Blue/Green deployments) Kubeform - Kubernetes CRDs for Terraform providers https://kubeform.com Spinnaker - Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence. http://www.spinnaker.io/ werf - GitOps tool to deliver apps to Kubernetes and integrate this process with GitLab and other CI tools Flux - GitOps Kubernetes operator Argo CD - Declarative continuous deployment for Kubernetes Tekton - A cloud native continuous integration and delivery (CI/CD) solution Jenkins X - Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Tekton, Knative, Lighthouse, Skaffold and Helm KubeVela - KubeVela works as an application delivery control plane that is fully decoupled from runtime infrastructure ksonnet - A CLI-supported framework that streamlines writing and deployment of Kubernetes configurations to multiple clusters CircleCI - A cloud-based tool that helps build continuous integration and continuous delivery pipelines to Kubernetes.

KSonnet

https://github.com/google/gke-policy-automation/blob/main/gk...

What's the point of requiring the control plane to be locked down to authorized networks (IP address ranges)? Isn't Google responsible for DDoS protection, enforcing authentication controls (i.e. logging in with a Google account in the right Google group), patching the control plane ASAP for any security vulnerabilities?

If you have a VPN, if you have heavy-duty network monitoring on your VPN endpoint, sure, limit it to the VPN. For the rest of us? Is every startup running GKE without heavy-duty VPN / network monitoring fundamentally insecure? That doesn't sound right to me. Security is supposed to be a spectrum, and it seems like black-and-white automated config checkers like these are more likely to provoke arguments internally ("but the tool said it's bad!!") than to help reach a nuanced understanding of why tradeoffs are made. No?

GKE Policy Automation is a tool and a policy library for validating Google Kubernetes Engine clusters against set of configuration best practices.