If you use jq, you’ll know that, its documentation uses examples that you can try locally or using the excellent jqplay: printf "[1,2,3]" | jq .[1:] [ 2, 3 ] And here If you use Google Cloud Platform (GCP) CLI, gcloud, this powerful tool includes JSON output formatting of results (--format=json) and YAML (--format=yaml) etc. and includes a set of so-called projections that you can use to format the returned data.

Recently, I described how to configure Golang logging so that user-defined key-values applied to the logs are parsed when ingested by Google Cloud Logging. Here’s an example of what we’re trying to achieve. This is an example Cloud Logging log entry that incorporates user-defined labels (see dog:freddie and foo:bar) and a readily-querable jsonPayload: insertId: 616dbf8e000892de40c4cc4e jsonPayload: level: 0 logger: MyName msg: something ts: '2021-10-18 00:00:00.000000' labels: dog: freddie foo: bar instanceId: 00bf4bf0.

I’ve been on a digression (gcp-oidc-token-proxy) this week. Yesterday I began exploring Podman and wrote briefly about running gcp-oidc-token-proxy on my localhost using it. This morning while walking with my dog, I listened to Google’s Dan Lorenc explain Sigstore (blog](https://blog.sigstore.dev/)) on The Kubelist Podcast1 The plan today is to try to sign the gcp-oidc-token-proxy container images in GitHub Container Registry. NOTE I decided against trying the hardware key approach. I have a Google Titan key and only Yubikeys are well-tested by go-piv

I’ve read about Podman and been intrigued by it but never taken the time to install it and play around. This morning, walking with my dog, I listened to the almost-always-interesting Kubernetes Podcast and two of the principals behind Podman were on the show to discuss it. I decided to install it and use it in this week’s project. Here’s a working Podman deployment for gcp-oidc-token-proxy ACCOUNT="..." ENDPOINT="..." # Can't match container name i.

I’ve written a solution (gcp-oidc-token-proxy) that can be used in conjunction with Prometheus OAuth2 to authenticate requests so that Prometheus can scrape metrics exposed by e.g. Cloud Run services that require authentication. The solution resulted from my question on Stack overflow. Problem #1: Endpoint requires authentication Given a Cloud Run service URL for which: ENDPOINT="my-server-blahblah-wl.a.run.app" # Returns 200 when authentication w/ an ID token TOKEN="$(gcloud auth print-identity-token)" curl \ --silent \ --request GET \ --header "Authorization: Bearer ${TOKEN}" \ --write-out "%{response_code}" \ --output /dev/null \ https://${ENDPOINT}/metrics # Returns 403 otherwise curl \ --silent \ --request GET \ --write-out "%{response_code}" \ --output /dev/null \ https://${ENDPOINT}/metrics Problem #2: Prometheus OAuth2 configuration is constrained

I’ve multiple components in an app and these are deployed across multiple Google Cloud Platform (GCP) services: Kubernetes Engine, Cloud Functions, Cloud Run, etc. Almost everything is written in Golang and I started the project using go-logr. logr is in two parts: a Logger that you use to write log entries; a LogSink (adaptor) that consumes log entries and outputs them to a specific log implementation. Initially, I defaulted to using stdr which is a LogSink for Go’s standard logging implementation.

This is very useful: I am building an application that comprises multiple repos. I continue to procrastinate on whether using multiple repos vs. a monorepo was a good idea but, an issue that I have (had) is the need to ensure that the repos' contents are using current|latest modules. GitHub can help. Most of the application is written in Golang with a smattering of Rust and some JavaScript. Aside Even though I’m more proficient with Golang, I want to become more proficient in Rust and I contemplated trying to write the entire application in Rust.

TL;DR I’m working on a project that includes multiple Cloud Run services. I’ve been putting my gcloud head on to deploy these services thinking that it’s curious there’s no way to write the specs as YAML configs. Today, I learned that there is: gcloud beta run services replace. What prompted the discovery was some frustration trying to deploy a JSON-valued environment variable to Cloud Run: local FIREBASE_CONFIG="{ apiKey: ${FIREBASE_API_KEY}, authDomain: ${FIREBASE_AUTH_DOMAIN}, projectId: ${FIREBASE_PROJECT}, storageBucket: ${FIREBASE_STORAGE_BUCKET}, messagingSenderId: ${FIREBASE_MESSAGING_SENDER}, appId: ${FIREBASE_APP}}" gcloud run deploy ${SRV_NAME} \ --image=${IMAGE} \ --command="/server" \ --args="--endpoint=:${PORT}" \ --set-env-vars=FIREBASE_CONFIG="${FIREBASE_CONFIG}" \ --max-instances=1 \ --memory=256Mi \ --ingress=all \ --platform=managed \ --port=${PORT} \ --allow-unauthenticated \ --region=${REGION} \ --project=${PROJECT} gcloud balks at this.

Problem I’m building an application that comprises: Kubernetes¹ Kubernetes Operator Cloud Firestore Cloud Functions Cloud Run Cloud Endpoints Stripe Firebase Authentication ¹ - I’m using Google Kubernetes Engine (GKE) but may include other managed Kubernetes offerings (e.g. Digital Ocean, Linode, Oracle). GKE clusters are manageable by gcloud but other platforms require other CLI tools. All are accessible from bash but are these supported by e.g. Terraform (see below)?

I’ve written before about a project in which I’m using Firebase Authentication in combination with Google Cloud Endpoints and a gRPC service running on Cloud Run: Firebase Authentication, Cloud Endpoints and gRPC (1of2) Firebase Authentication, Cloud Endpoints and gRPC (2of2) This works well with one caveat, the ID tokens (JWTs) minted by Firebase Authentication have a 3600 second (one hour) lifetime. The user flow in my app is that whenever the user invokes the app’s CLI: