docs: fix sso-and-identity.md drift (proxy provider count, git pull credential)
Proxy provider count is 94 live, not 96. Bigger fix: the doc claimed the 5 pull-only docker hosts each have a separate read-only Gitea Deploy Key - live investigation found no Deploy Key object exists anywhere in Gitea at all. The real mechanism (docker_git_setup role, iac repo) copies the same write-capable automation-bot account key identically to every host at first provisioning. Corrected the claim and swapped the now-inaccurate screenshot for the real provisioning task as evidence. Same fix applied to the source KB note (Gitea Access Model).
This commit is contained in:
2 files changed
+18
-5
No files matched your search
Binary file not shown.
|
Before Width: | Height: | Size: 80 KiB |
@@ -1,6 +1,7 @@
|
|||||||
<!-- verified: 2026-09-06
|
<!-- verified: 2026-09-18
|
||||||
rocky-docker-lxc@4f43dcc : caddy/Caddyfile
|
rocky-docker-lxc@7dd5025 : caddy/Caddyfile
|
||||||
caddy-vm@9369f8b : caddy/Caddyfile
|
caddy-vm@9369f8b : caddy/Caddyfile
|
||||||
|
iac@f770e1c : ansible/roles/bootstrap_roles/docker_git_setup
|
||||||
trilium : baWhWTUejvY6, hWiIGZIlvQiN, nAPJq9A1iuX8
|
trilium : baWhWTUejvY6, hWiIGZIlvQiN, nAPJq9A1iuX8
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@@ -60,7 +61,7 @@ This is the actual live query against Authentik's API, not a paraphrase of what'
|
|||||||
```
|
```
|
||||||
$ curl -s -H "Authorization: Bearer [REDACTED]" \
|
$ curl -s -H "Authorization: Bearer [REDACTED]" \
|
||||||
"https://authentik.[service-to-service zone]/api/v3/providers/proxy/?page_size=1" | jq '.pagination.count'
|
"https://authentik.[service-to-service zone]/api/v3/providers/proxy/?page_size=1" | jq '.pagination.count'
|
||||||
96
|
94
|
||||||
$ curl -s -H "Authorization: Bearer [REDACTED]" \
|
$ curl -s -H "Authorization: Bearer [REDACTED]" \
|
||||||
"https://authentik.[service-to-service zone]/api/v3/providers/proxy/?page_size=200" | jq -r '.results[].name' | grep -E '^proxmox'
|
"https://authentik.[service-to-service zone]/api/v3/providers/proxy/?page_size=200" | jq -r '.results[].name' | grep -E '^proxmox'
|
||||||
[no output — Proxmox has no Proxy Provider at all]
|
[no output — Proxmox has no Proxy Provider at all]
|
||||||
@@ -91,11 +92,23 @@ So an app's OIDC discovery/authority setting always points at the service-to-ser
|
|||||||
|
|
||||||
## Git Access: least privilege, not the admin account
|
## Git Access: least privilege, not the admin account
|
||||||
|
|
||||||
Automation should never run with more privilege than it needs. CI and orchestration pushes (the flows described in [`docs/orchestration.md`](orchestration.md)) run through a dedicated, non-admin bot account with scoped write access — never through an administrator identity. This wasn't the original setup: automated pushes used to run through the personal admin account used for interactive access, the same one with full admin rights over the Git server. That got fixed by standing up a separate account with its own SSH keypair and adding it as a write collaborator on every repo it touches — routine automated commits no longer run under an admin credential at all. Hosts that only need to *read* get separate read-only deploy keys instead of any shared credential. The practical payoff: if an automation credential ever leaks, the blast radius is "can push to specific repos," not "has full admin control of the Git server."
|
Automation should never run with more privilege than it needs. CI and orchestration pushes (the flows described in [`docs/orchestration.md`](orchestration.md)) run through a dedicated, non-admin bot account with scoped write access — never through an administrator identity. This wasn't the original setup: automated pushes used to run through the personal admin account used for interactive access, the same one with full admin rights over the Git server. That got fixed by standing up a separate account with its own SSH keypair and adding it as a write collaborator on every repo it touches — routine automated commits no longer run under an admin credential at all. The 5 docker hosts that only ever pull (never push) use that same bot account's key too — copied identically to each host at first provisioning, not a separate credential per host. The practical payoff: if an automation credential ever leaks, the blast radius is "can push to the repos this bot account touches," not "has full admin control of the Git server."
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||

|
This is the real provisioning task, not a description of it — the automation-bot key gets copied to every docker host identically:
|
||||||
|
|
||||||
|
```
|
||||||
|
# The automation-bot private key - authenticates the push to Gitea AND signs
|
||||||
|
# commits (ssh_key_path == ssh_signing_key_path). Copied from the control node.
|
||||||
|
- name: Install the automation-bot git key
|
||||||
|
copy:
|
||||||
|
src: "{{ ssh_key_path }}"
|
||||||
|
dest: "{{ ssh_key_path }}"
|
||||||
|
owner: "{{ git_repo_owner }}"
|
||||||
|
group: "{{ git_repo_group }}"
|
||||||
|
mode: "0600"
|
||||||
|
```
|
||||||
|
|
||||||
---
|
---
|
||||||
Related: [`docs/dns-naming.md`](dns-naming.md), [`docs/orchestration.md`](orchestration.md), [`docs/secrets-and-pki.md`](secrets-and-pki.md) · Stacks: [`stacks/identity-and-security/authentik/`](../stacks/identity-and-security/authentik/), [`stacks/platform/gitea/`](../stacks/platform/gitea/)
|
Related: [`docs/dns-naming.md`](dns-naming.md), [`docs/orchestration.md`](orchestration.md), [`docs/secrets-and-pki.md`](secrets-and-pki.md) · Stacks: [`stacks/identity-and-security/authentik/`](../stacks/identity-and-security/authentik/), [`stacks/platform/gitea/`](../stacks/platform/gitea/)
|
||||||
Reference in new issue
Block a user