AWS secret key and ID can be thought of as a username/password and should be carefully managed, rotated, secured as described in Best practices for managing AWS access keys. However, if you need to invoke AWS from remote systems which do not provide ambient federation (eg on GCP using OIDC tokens), then you must either utilize an AWS credentials file or set them dynamically as an environment variable.
This repo provides two ways…
Shell alias script that will print the active in-use account for GCP application default credentials (ADC).
For example, if you run either
gcloud config list
gcloud auth list
this script will print the gcloud cli credentials as well as the application default credentials that are in use. This script will also transparently pass and apply parameters to the actual gcloud cli (meaning the alisas it acts as if its gcloud)
This script is not supported by Google
As background, users can configure gcloud to use two different credential sets: one for the gcloud cli and one for any google cloud…
This article basically talks about a simple docker container with openssl
1.1.1i which has TLS trace flags enabled.
What that allows you to do see is the very low-level TLS traffic between a client and server for both TLS, mTLS and OCSP traffic.
I recently needed to find out if the TLS Server i was connecting to would unilaterally support client-side certificate stapling (which is in of itself incredibly rare)…but in the course of doing that bit, i create the following repo and here the corresponding article:
The dockerhub image for the bit above is docker.io/salrashid123/openssl s_server
Anyway, before you…
I spent the last day trying to setup and test Secure Boot locally on a VM with debain 10
The real goal i had in mind it so use my own keypairs to ensure and bootstrap my own signed OS….As a first step, i’ll just setup Debian 10 with Secure Boot locally.
Consider this post as just a log and setup for your own testing
for ref: SecureBoot VirtualMachine
To use this, first download debian 10 and have KVM QEMU installed locally somewhere
This repo is scratchpad for setting up and testing SecureBoot VirtualMachine with QEMU. Its…
JSON logging on GKE with various golang logging libraries.
This is just a simple http application which emits JSON strings to stdout/stderr from go using
For each log type, there is an endpoint to invoke them where the various handler will emit a JSON string:
gcloud container clusters create cluster-1 --machine-type "n1-standard-2" \
--zone us-central1-a \
--num-nodes 2 --enable-ip-alias \
A simple way to embed/associate audit logged metadata to GCP API calls.
Or in other words, whenever you make any GCP API call like GCS, PubSub, you can automatically attach metadata to the call which will show up in audit logs. One usecase is to attach information about why the request is being made. For example, if you run a SaaS service that uses GCP APIs and you make calls to services on behalf of your customers, you can attach information to that call indicating who it was made for.
Also included in this repo is the basic ‘helloworld’ for…
Simple gRPC client/server for GCP API Gateway and Cloud Run…now with with authentication and authorization!
Basically you deploy a gRPC server on Cloud Run, then an API gateway which brokers requests. The gateway is protected by JWT authentication while the Cloud Run backend will only allow requests originating from the gateway’s service account identity
Cloud Run API Server
You can find the source here
Set environment variables
A simple tutorial on how to setup envoy and istio such that per method statistics are emitted to prometheus+grafana.
There are several techniques to emitting and collecting gRPC stats shown here:
server: Envoy will surface prometheus stats endpoint
server: Istio (envoy) will again surface a prometheus endpoint
client(native prometheus gRPC): Use gRPC built in prometheus stats endpoint
client(opencensus prometheus): Use Opencensus's Prometheus exporter for gRPC
server: Deploy a GKE gRPC service and allow a prometheus server to scrape each gRPC server eposing
A really basic implementation of envoy External Processing Filter. This capability allows you to define an external gRPC server which can selectively process headers and payload/body of requests (see External Processing Filter PRD. Basically, your own unrestricted filter!
ext_proc (redact header from client to upstream)
client -> envoy -> upstream
NOTE, this filter is really early and has a lot of features to implement!
You can find the full source here:
All we will demonstrate in this repo is the most basic functionality: simply remove a specific heder sent by the client. I know, there are countless easier…
This is a sample procedure that will exchange an arbitrary OIDC
id_token for a GCP credential.
You can use the GCP credential then to access any service the mapped principal has GCP IAM permissions on.
This article and repo is the second part that explores how to use the workload identity federation capability of GCP which allows for external principals (AWS,Azure or arbitrary OIDC provider) to map to a GCP credential.
The two variations described in this repo will acquire a Google Credential as described here: