You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for access tokens for isolated environments
To run tc-logview without gcloud auth available or permanent service
account key, one could issue OAuth2 access token with gcloud and
impersonate some limited service account
`TC_LOGVIEW_ACCESS_TOKEN` would be used if present
Copy file name to clipboardExpand all lines: CHANGELOG.md
+13Lines changed: 13 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,18 @@
1
1
# Changelog
2
2
3
+
## v1.3.0 - 2026-05-28
4
+
5
+
### Added
6
+
7
+
- Pre-issued OAuth2 access tokens via the `TC_LOGVIEW_ACCESS_TOKEN` env var. Intended for containers/agents that should run without access to the host's `gcloud` session or a long-lived service account key. The host mints a short-lived, SA-scoped token (e.g. `gcloud auth print-access-token --impersonate-service-account=<SA>`) and injects only the token; tc-logview itself does not impersonate or refresh.
8
+
- Auth precedence is now `TC_LOGVIEW_ACCESS_TOKEN` > `key_path` > ADC; the active mode is logged under `-v` as `token`, `key_file`, or `ADC`. Client-create and query errors are tagged with the active mode for diagnosability.
9
+
- Expired/invalid token errors append a one-line hint pointing at the re-mint command.
10
+
11
+
### Changed
12
+
13
+
-`config init` template's authentication comment block now documents all three modes and the priority order.
14
+
- README Setup section gains Option C describing the host-mints-token / container-consumes-token flow.
Copy file name to clipboardExpand all lines: README.md
+21-1Lines changed: 21 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -68,7 +68,7 @@ environments:
68
68
69
69
### 2. Authenticate to GCP
70
70
71
-
Choose one of the two options belowper environment. In the example config above, `fx-ci`, `community-tc`, and `staging` use service account keys (Option B); `dev` uses ADC (Option A).
71
+
Choose one of the three options below. Options A and B are configured per environment in `config.yaml`; Option C is selected at runtime via the `TC_LOGVIEW_ACCESS_TOKEN` env var and overrides whatever the config says. In the example above, `fx-ci`, `community-tc`, and `staging` use service account keys (Option B); `dev` uses ADC (Option A).
72
72
73
73
#### Option A — Application Default Credentials (recommended for local use)
74
74
@@ -86,6 +86,26 @@ Place your service account JSON key in `~/.config/tc-logview/keys/` and set `key
86
86
87
87
This mode is what you want inside an untrusted/containerized environment where you do not want to share your personal `gcloud` session.
88
88
89
+
#### Option C — Injected access token (recommended for containers / agents)
90
+
91
+
For containers running untrusted code (agents, CI jobs, ephemeral sandboxes), prefer a pre-issued short-lived bearer token over a long-lived service account key. The host impersonates a low-privilege service account once and passes only the resulting access token into the container.
92
+
93
+
```bash
94
+
# On the host (requires roles/iam.serviceAccountTokenCreator on the SA):
When `TC_LOGVIEW_ACCESS_TOKEN` is set it takes priority over `key_path` and ADC. The container never sees the host's `gcloud` session, never calls the IAM Credentials API, and cannot mint or refresh tokens. Worst-case leakage is one access token, valid only for its TTL (~1h).
106
+
107
+
Re-mint and re-inject the token before it expires for long-running containers. An expired token surfaces as a `401` from the query path with a hint pointing back at the re-mint command.
0 commit comments