cloud-sql-proxy
gke-policy-automation
cloud-sql-proxy | gke-policy-automation | |
---|---|---|
4 | 8 | |
1,231 | 508 | |
1.1% | 0.2% | |
9.2 | 6.9 | |
2 days ago | 10 days ago | |
Go | Go | |
Apache License 2.0 | 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-proxy
- How do I connect a local Docker container to a Cloud SQL instance?
-
Cloud SQL with Private IP vs Public IP (Cloud SQL Auth Proxy only)?
Yep I managed to get it working with a Public IP DB (with no IPs allowed) + this tunnel-like thing https://github.com/GoogleCloudPlatform/cloud-sql-proxy
-
Tell HN: CloudSQL cause random 5xx, GCP DevRel shutdowns feedback
Where XXXX is the the IP address of our machine and YYYY is the IP address of CloudSql. Upon Google searching, we discovered this thread of other people experiencing this same issue with GCP CloudSQl.
https://github.com/GoogleCloudPlatform/cloud-sql-proxy/issues/343
-
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?
cloudsql-proxy - A utility for connecting securely to your Cloud SQL instances [Moved to: https://github.com/GoogleCloudPlatform/cloud-sql-proxy]
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.
popeye - 👀 A Kubernetes cluster resource sanitizer
OPAL - Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)