Kubernetes Engine
Last updated
Was this helpful?
Last updated
Was this helpful?
.
.
.
Creating roles with kubectl
Name of the lab
Quest link
Deploy Kubernetes to cloud
Optimize costs for GKE
GKE best practices: security
Google Cloud's operation suite on GKE
Kubernetes solutions
Options
bootcamp
status:Builtin Type
Usage
Opaque
arbitrary user-defined data
kubernetes.io/service-account-token
service account token
kubernetes.io/dockercfg
serialized ~/.dockercfg
file
kubernetes.io/dockerconfigjson
serialized ~/.docker/config.json
file
kubernetes.io/basic-auth
credentials for basic authentication
kubernetes.io/ssh-auth
credentials for SSH authentication
kubernetes.io/tls
data for a TLS client or server
bootstrap.kubernetes.io/token
bootstrap token data
kubectl config view
For creating basic nodal cluster
to drain the node pool nodes use
StorageClass creation
Persistent Volume Claim
Cluster credentials
K8s docs
Grafeas - API spec for managing metadata about software resources such as container images, virtual machines, Jar files, scripts.
Kritis - API for ensuring the deployment is prevented unless the artifact is conformant to central policy.
Persistent volume claim resize
--metadata=disable-legacy-endpoints=true
Anthos service mesh 1.8 can be used for a single shared VPC, even across multiple projects.
TLS termination for external requests is supported with Anthos Service Mesh 1.0. Doing so requires modifying the Anthos Service Mesh setup files.
Anthos Service Mesh has inherent security features (and limitations).
ASM inherently implements istio security best practices, such as namespaces and limited service accounts. Workload identity is an optional GKE-specific service account, limited to a namespace.
The Istio ingress gateway needs to be secured manually.
GKE cluster network policies allow you to define workload access across pods and namespaces. This is built on top of Kubernetes NetworkPolicy API.
Securing container workloads in GKE - involves a layered approach to node security, pod/container security contexts and pod security policies.
Use cos_containerd runtime for GKE clusters using Anthos Service Mesh.
Cloud SQL is external to GKE, thus requiring GKE to do SSL termination for external services. With Anthos Service Mesh, you can use an Istio ingress gateway, which allow SSL passthrough, so that the server certificates can reside in a container.
PostgreSQL uses application-level protocol negotiation for SSL connections. The Istio proxy currently uses TCP-level protocol negotiation. This causes the Istio proxy sidecar to error out during the SSL handshake, when it tries to auto-encrypt the connection with PostgreSQL.
Anthos Service Mesh 1.8 can federate multiple GKE clusters. Taken as managed Istio
in a single VPC, this container orchestration model takes GKE to its full potential, and can be configured using tools like terraform and shell scripts.
.
.
.
For node pools
.
Draining node-pool
.
.Understanding and Combining GKE Autoscaling Strategies -
. Binary Authorization
.
.
.
.
Anthos Service Mesh can be setup with . A custom istio-operator.yaml file can be used by running install_asm with the --custom_overlay option.
In order for Istio (i.e., Anthos Service Mesh) to allow access to external services, change the egress policy to REGISTRY_ONLY.
.
.
.