cloud-sql-jdbc-socket
gke-policy-automation
| cloud-sql-jdbc-socket | gke-policy-automation | |
|---|---|---|
| 1 | 8 | |
| - | 508 | |
| - | 0.2% | |
| - | 6.9 | |
| - | 11 days ago | |
| Go | ||
| - | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cloud-sql-jdbc-socket
-
Google Kubernetes clusters config checker tool
I wish they would reuse the pattern of Cloud SQL where you can get temporary access without manually handling the Authorized Networks setting. The Cloud SQL API lets you exchange your API access token for a short lived TLS client certificate. This is done client side by things like [cloudsql-proxy](https://github.com/GoogleCloudPlatform/cloudsql-proxy) and [the cloud-sql-jdbc-socket-factory java library](https://github.com/GoogleCloudPlatform/cloud-sql-jdbc-socket...). This way, I can access my Cloud SQL instance from my IDE, even though my list of authorized networks is empty.
I feel like the gke-gcloud-auth-plugin cloud do something very similar.
gke-policy-automation
-
Google Kubernetes clusters config checker tool
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: validate your cluster configurations
GKE Policy Automation is a tool and a policy library for validating Google Kubernetes Engine clusters against set of configuration best practices.
What are some alternatives?
ksonnet - A CLI-supported framework that streamlines writing and deployment of Kubernetes configurations to multiple clusters.
cerbos - Cerbos is the open core, language-agnostic, scalable authorization solution that makes user permissions and authorization simple to implement and manage by writing context-aware access control policies for your application resources.
cloud-sql-jdbc-socket-factory - A collection of Java libraries for connecting securely to Cloud SQL
OPAL - Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)
cloud-sql-proxy - A utility for connecting securely to your Cloud SQL instances
policy-enforcer - Represent your rego rules programmatically.
reposaur - Open source compliance tool for development platforms.
tanka - Flexible, reusable and concise configuration for Kubernetes
popeye - 👀 A Kubernetes cluster resource sanitizer
OPA (Open Policy Agent) - Open Policy Agent (OPA) is an open source, general-purpose policy engine.