berglas VS kubernetes-the-hard-way

Secret Manager: secure storage for sensitive data e.g passwords.

Google Secret Manager

API keys are easy to "leak" or compromise, so best to not only use the restrictions presented to you when you create them but physically protect them as well. Don't code them in plain-text, don't check them into GitHub, etc. Store them in a secure database or use a service like GCP Secret Manager.

I've been looking at Google Secret Manager which sounds promising but I've not been able to find any examples or tutorials that help with the actual practical details of best practice or getting this working. I'm currently reading about Cloud Functions which also sound promising but again, I'm just going deeper and deeper into GCP without feeling like I'm gaining any useful insights.

In this post, I described how to build secure GitHub Actions workflows by pull_request_target event instead of pull_request event. Using pull_request_target, you can prevent malicious codes from being executed in CI. And by managing secrets in secrets management services such as AWS Secrets Manager and Google Secret Manager and access them via OIDC, you can restrict the access to secrets securely. To migrate pull_request to pull_request_target, several modifications are needed. And pull_request_target has a drawback that it's difficult to test changes of workflows, so it's good to introduce pull_request_target to repositories that require strong permissions in CI. For example, a Terraform Monorepo tends to require strong permissions for CI, so it's good to introduce pull_request_target to it.

If you want to make these secrets more secure and get versioning and access logs for them, you may want to switch to Secret Manager later on. They can still be exposed as environment variables to your code. It's a little more setup work, so start with the simple approach at the top.

https://cloud.google.com/secret-manager https://aws.amazon.com/secrets-manager/

As I delved into the world of Kubernetes, I opted for what seemed like the scenic route—until reality hit. With determination and a sprinkle of naivety, I plunged into crafting a Kubernetes cluster from scratch. Little did I know, I was in for a wild ride of commands, configurations, and complexities. But fear not! With the guiding light of a course based on the notorious "Kubernetes The Hard Way" GitHub repository, albeit customized for AWS instead of Google Cloud, I embarked on my journey to build my digital fortress, one step at a time.

Another resource that I found pretty helpful was "Kubernetes the Hard Way" by Kelsey Hightower despite its complexity.

https://github.com/kelseyhightower/kubernetes-the-hard-way

I recently published Kubernetes the Harder Way, a guide loosely based on Kelsey Hightower's Kubernetes the Hard Way, but lenghtier, more explanatory, broader in scope, and - most importantly - harder, by targeting a local machine instead of Google Cloud Platform.

How about this? It will setup a kubernetes cluster on GCP with 3 worker nodes?

https://github.com/kelseyhightower/kubernetes-the-hard-way

Some costs here but click on the google cloud calc as it seems to have gone up since he wrote this:

If you wanna go all in: https://github.com/kelseyhightower/kubernetes-the-hard-way

Oh, and both: "Kubernetes up and Running" and "Production Kubernetes" are great books.

Using Kubernetes The Hard Way is a great way to learn it deeply and quickly.

If you wanna learn it deeply and quickly, Kelsey Hightower's Kubernetes the hard way is fantastic!