Google Cloud CLI Without gpgcheck=0
gcloud, gsutil and bq on EL 10 from the versioned tarball, checked against a SHA-256 pinned beside the version: Google's yum key has a SHA-1 self-signature that rpm on EL 10 refuses, so the repository only installs with the GPG check off. Usage reporting and update nagging off installation-wide, read back through gcloud config get. Original role, live-tested on Rocky Linux 10.
Verification
Live-testedReally deployed to a container sandbox, proven idempotent (a second run changes nothing), verified against the role’s assertions, then torn down.
Conformance
- Static validation (yamllint · ansible-lint)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live-tested - applied, verified, destroyed
Last verified 2026-09-19 · podman 4.9.3 · ansible 2.21.4 · how we verify
Documentation
google-cloud-cli
The Google Cloud CLI (gcloud, gsutil, bq) on EL 10 from the versioned
upstream tarball, verified against a pinned SHA-256, installed for every
user with usage reporting and update nagging off. Original role for EL 10,
live-tested with podman on Rocky Linux 10.
The repository cannot be verified on EL 10. Google publishes an EL 10
yum repository, but its signing key (F09C394C3E1BA8D5, from 2015) has a
SHA-1 self-signature, and rpm on EL 10 refuses to import it: "Policy
rejects: No binding signature". dnf install google-cloud-cli fails its
GPG check, and the fix that circulates is gpgcheck=0, which installs
whatever arrived. This role installs from the versioned tarball instead and
checks it against a SHA-256 pinned beside the version. Google publishes the
current release's checksums on its install page; the values here were taken
from the tarballs fetched over HTTPS from dl.google.com on 2026-09-19 and
match that page's release. A new version is a new pair, on purpose.
Installation-wide, not per user. The SDK's properties file applies
to every user: the role sets disable_usage_reporting and
disable_update_check there, and the live test reads both back through
gcloud config get - what the CLI runs with, not what a file says.
Pinned, replaced whole. The SDK's own component updater is not used; a different pinned version removes the tree and unpacks the new one, so the version on disk is always the one in the variable.
Proven to run. gcloud auth list runs to completion with nothing to
show; gsutil version and bq version answer through the PATH links.
License
Commercial - IaC Bazaar EULA. (c) IaC Bazaar.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Variables
- Test
Related modules
gcp-dataflow
on_delete defaults to cancel, which discards every element in flight on a streaming pipeline the moment the job is destroyed or replaced; workers get public IPs by default; and the default worker identity is the Compute Engine default account. Drain on delete, private workers with Private Google Access, a dedicated service account with the default refused, and a customer-managed key.
gcp-cloud-deploy
require_approval defaults to false on every target, so a release rolls into production the moment somebody promotes it with nobody signing off; the verify flag defaults off, so skaffold verify has never run. Treats the last stage as production and refuses a pipeline whose last target skips approval, verifies after every rollout, and refuses the Compute default service account as the runner.
gcp-cloud-build
A trigger with no service account runs every step - including code from the pull request under test - as the broadest identity in the project; a trigger that deploys on push deploys whatever lands; the shared default pool has external IPs. A dedicated runner with the defaults refused, a private worker pool with no external addresses, and approval required on any trigger marked as deploying.
gcp-composer
Managed Apache Airflow on Cloud Composer 2 with small-by-default sizing, worker autoscaling pinned for predictable cost, and an opt-in private environment posture.
gcp-workflows
A Cloud Workflows workflow that runs as a dedicated least-privilege service account instead of the broad Compute Engine default, with inline YAML, deletion protection, and call logging.
gcp-dataproc
A single-node Dataproc cluster (1 master, 0 workers), the cheapest managed Spark/Hadoop cluster that still applies and destroys cleanly, with internal-only IPs and deletion protection on.