Romulo Santos soeirosantos

Shared VPC with GKE and Cloud Memorystore

Note: You can see an improved version of this tutorial on the Google Cloud community website: https://cloud.google.com/community/tutorials/shared-vpc-gke-cloud-memorystore

In this lab we are going to configure a Shared VPC between two service projects. One project will contain a GKE cluster and the other one will contain managed services that would be accessed from applications deployed to the GKE cluster.

Linux tips for developers: find

find is a handy utility in the Linux user's toolbelt. It can be a very useful tool for diagnostic and debugging when you need to find core files or application-specific configuration files. It is also often used to find and remove temp files and other volatile files/directories that have not been accessed recently.

find searches the directory tree rooted at each given file name by evaluating the given expression from left to right, according to the rules of precedence, until the outcome is known, at which point find moves on to the next file name. - https://linux.die.net/man/1/find

Common arguments

-name - search by file name pattern
-iname - same as above but ignore case

Workload Identity in Practice

302 :) This tutorial has been permanently moved to https://deployment.properties/posts/devsecops/workload-identity-getting-started/

Terraform GKE example / security best practices

This is an example of how to create a GKE cluster with some sensible defaults and best practices for security.

Please, notice that this example contains the minimum security configuration that you can get without impacting other features, requiring additional network config, or the installation of third-party tools.

Security items covered in this example:

Auto upgrades using regular release channel
Shielded GKE Nodes
Hardened node image with the containerd runtime

This content has been permanently moved to https://deployment.properties/posts/devsecops/vault-eks-irsa/

Terraform Version of HashiCorp Vault AWS Auth with Amazon EKS and IAM Roles for Service Accounts

This gist is the Terraform configuration for the previous tutorial on HashiCorp Vault AWS Auth with Amazon EKS and IAM Roles for Service Accounts.

This Terraform configuration replaces all the AWS and Vault CLI commands in the previous tutorial.

Before running the next steps make sure you have started Vault and ngrok locally. Take a look at the previous tutorial for more details.

	package br.com.soeirosantos.twitter

	import com.github.kittinunf.fuel.Fuel
	import com.github.kittinunf.fuel.core.ResponseDeserializable
	import com.google.gson.Gson
	import org.slf4j.Logger
	import org.slf4j.LoggerFactory
	import twitter4j.*
	import java.io.File
	import kotlin.math.roundToInt

	apiVersion: audit.k8s.io/v1
	kind: Policy
	rules:
	# high-volume and low-risk
	- level: None
	users: ["system:kube-proxy"]
	verbs: ["watch"]
	resources:
	- group: "" # core
	resources: ["endpoints", "services", "services/status"]

	---
	apiVersion: v1
	kind: ServiceAccount
	metadata:
	name: vault-secrets-store-csi-driver-upgrade-crds
	namespace: default
	labels:
	app.kubernetes.io/instance: "csi"
	app.kubernetes.io/name: "secrets-store-csi-driver"
	app.kubernetes.io/version: "1.2.4"