We put up "guardrails" to warn developers when they're about to do something that may not be secure and "paved roads" to make it easy for them to work and be effective in a secure way. This requires a lot of thought on the part of the various Security teams at Shopify. We ensure that our products are secure, but we also trust our developers and don't unnecessarily impede development flows. This culture of trust flows down into development practices and protocols. One of the reasons I love working at Shopify is our policy to default to open internally, which means we trust our employees to make smart decisions. Just as GCP gives us the computing power we need to run all of those shops, Kubernetes helps us deploy, manage, and scale our applications to use that power. You can read more about how Shopify works with Google in this post about Shopify’s infrastructure collaboration with Google. GCP provides compute resources when we need them to power our workloads (over one million shops and counting). I will briefly explain each of these before we dig into the details of building SSH-Pruner. This post touches on concepts around Google Cloud Platform, Google Kubernetes Engine, Security Practices at Shopify, and Secure Shell Protocol. Google makes it easy to block project-wide SSH keys from a given VM, but there's currently no automatic management of these keys, so they persist indefinitely.
How does this relate to SSH keys? When a user SSHs into any VM in a Google Cloud Platform Project, their public key is added to the project’s metadata, meaning this key could be used to access any VMs running in that project.
0 kommentar(er)
