TAI/TA-Deployment-Broker
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update gui

Browse Source
This commit is contained in:
David Schroeder
2026-07-28 21:11:54 -05:00
parent 6c4ce8f6df
commit 555aae0ab2
12 changed files with 71 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/client-api.md
+1 -1
View File
@@ -1,6 +1,6 @@
# Proxmox client API
The ProxMenu client uses two HTTPS requests. It never receives Gitea
The ProxMenu client uses two HTTPS requests. It never receives Git
credentials.
## Exchange a deployment code
docs/deployment.md
+26 -26
View File
@@ -7,8 +7,8 @@ VM. `/opt/idssys/TA-Deployment-Access` is only one possible example.
One Compose project manages:
- TAPM broker, with an embedded SQLite database
- Gitea, with its own embedded SQLite database and repository storage
- Nginx, terminating TLS for the broker and Gitea
- Git, with its own embedded SQLite database and repository storage
- Nginx, terminating TLS for the broker and Git
- Certbot, as an on-demand utility for certificate issuance and renewal
The same deployment supports an explicitly insecure HTTP testing phase before
@@ -18,9 +18,9 @@ runtime data.
In production, only the configured Nginx HTTP and HTTPS ports are published.
They default to 8680 and 8643. Inside Docker, Nginx listens on ports 80 and 443,
the broker on 8080, and Gitea is explicitly pinned to `0.0.0.0:3000`. Gitea
the broker on 8080, and Git is explicitly pinned to `0.0.0.0:3000`. Git
SSH is disabled. Deployment-level variables such as `HTTP_PORT` are not passed
into the Gitea container, preventing them from overriding its internal listener.
into the Git container, preventing them from overriding its internal listener.
## 1. VM and network
@@ -38,7 +38,7 @@ the required forwarded ports. Nginx supplies the application-edge controls:
unknown HTTP hostnames are dropped, unknown TLS SNI names are rejected,
TLS is restricted to 1.2/1.3, session tickets and version disclosure are
disabled, broker requests and per-address connections are limited, slow-client
timeouts are bounded, Gitea login bursts are throttled, and HSTS plus browser
timeouts are bounded, Git login bursts are throttled, and HSTS plus browser
security headers are returned. Container PID ceilings and Docker log rotation
reduce the impact of local resource exhaustion.
Nginx also runs with a read-only container filesystem and narrowly scoped
@@ -50,7 +50,7 @@ forwarding headers.
```sh
sudo mkdir -p /YOUR/INSTALL/PARENT
sudo git clone GITEA-REPOSITORY-URL /YOUR/INSTALL/PARENT/TA-Deployment-Access
sudo git clone GIT-REPOSITORY-URL /YOUR/INSTALL/PARENT/TA-Deployment-Access
sudo chown -R 1000:1000 /YOUR/INSTALL/PARENT/TA-Deployment-Access
cd /YOUR/INSTALL/PARENT/TA-Deployment-Access
./install.sh
@@ -58,7 +58,7 @@ cd /YOUR/INSTALL/PARENT/TA-Deployment-Access
The guided installer validates both hostnames and Docker ports, generates the
broker cookie secret, writes `.env` with mode `0600`, prepares persistent
storage, and starts only Gitea and Nginx. It defaults to `SSL_MODE=none`, so no
storage, and starts only Git and Nginx. It defaults to `SSL_MODE=none`, so no
certificate or public port forwarding is required.
With the default `HTTP_PORT=8680`, test URLs include that port:
@@ -82,7 +82,7 @@ Runtime state is deliberately visible below the checkout:
config/
├── broker/ # tapm.db and SQLite WAL files
├── gitea/
│ ├── config/ # app.ini and Gitea configuration
│ ├── config/ # app.ini and Git configuration
│ └── data/ # repositories, packages, and gitea.db
├── letsencrypt/ # account data, certificate, and private key
├── ssl/ # optional administrator-provided certificate
@@ -92,15 +92,15 @@ config/
The contents are ignored by Git. They must never be committed.
## 3. Configure Gitea and the broker
## 3. Configure Git and the broker
The installer has already bootstrapped Gitea. Create the initial administrator:
The installer has already bootstrapped Git. Create the initial administrator:
```sh
./manage.sh create-admin
```
Sign in at the Gitea URL printed by the command and change the temporary
Sign in at the Git URL printed by the command and change the temporary
password. Create the `TAI` organization, then create:
1. `tapm-packages`, with a read-only package token.
@@ -116,13 +116,13 @@ Save the resulting values without echoing secrets to the terminal:
```
The broker is deliberately not started during the first bootstrap. Blank
OAuth/package values are valid for Gitea-only setup, while `start` refuses to
OAuth/package values are valid for Git-only setup, while `start` refuses to
launch the broker until all required credentials are present.
`TAPM_GITEA_URL` is the public browser-facing Gitea URL.
`TAPM_GITEA_URL` is the public browser-facing Git URL.
`TAPM_GITEA_INTERNAL_URL` defaults to `http://gitea:3000` in installations so
OAuth token exchange and package traffic stay on the private Compose network.
Do not publish Gitea's internal port to make broker authentication work.
Do not publish Git's internal port to make broker authentication work.
Deployment codes default to seven days:
@@ -141,7 +141,7 @@ For troubleshooting, use `./manage.sh diagnostics`. Do not share unredacted
`docker compose config` output: Compose resolves the broker's `.env` file and
can print cookie, OAuth, and package secrets. If configuration output is
accidentally disclosed, rotate the cookie secret with
`./manage.sh rotate-cookie-secret` and replace any configured Gitea tokens or
`./manage.sh rotate-cookie-secret` and replace any configured Git tokens or
OAuth secret that appeared.
## 4. Enable TLS when forwarding is ready
@@ -157,7 +157,7 @@ After public DNS resolves and the datacenter edge forwards public TCP 80 and
`set-ssl` changes all public URLs to HTTPS and removes the temporary `:8680`
test port. `bootstrap` obtains the certificate and switches Nginx to TLS.
`start` recreates Gitea and the broker with secure cookies. Existing SQLite
`start` recreates Git and the broker with secure cookies. Existing SQLite
databases, repositories, packages, installation identities, and secrets remain
in place.
@@ -188,7 +188,7 @@ curl --fail "http://GITEA_DOMAIN:HTTP_PORT/api/healthz" # SSL_MODE=none
```
The broker automatically applies SQLite schema migrations before starting.
Gitea uses its own SQLite database at
Git uses its own SQLite database at
`config/gitea/data/data/gitea.db`.
After TLS is enabled, use the equivalent `https://` URLs without the temporary
HTTP test port.
@@ -196,7 +196,7 @@ HTTP test port.
### Final identity hardening
After public DNS, WAN TCP 80/443 forwarding, and the Let's Encrypt certificate
are working, configure Microsoft Entra ID as Gitea's OpenID Connect
are working, configure Microsoft Entra ID as Git's OpenID Connect
authentication source. Register the final callback URL:
```text
@@ -204,9 +204,9 @@ https://GITEA_DOMAIN/user/oauth2/entra/callback
```
Require assignment to the Entra enterprise application, apply the company's
Duo-backed Conditional Access policy, and map the Entra `Gitea.User` and
`Gitea.Admin` application roles into Gitea. Verify an Entra administrator can
sign in and reach the broker before disabling Gitea's local password sign-in
Duo-backed Conditional Access policy, and map the Entra `Git.User` and
`Git.Admin` application roles into Git. Verify an Entra administrator can
sign in and reach the broker before disabling Git's local password sign-in
form. Keep a documented VM-console recovery procedure and retain the package
reader and publisher as non-admin service accounts with narrowly scoped
tokens.
@@ -227,8 +227,8 @@ Then run:
./manage.sh start-direct
```
This adds host mappings to the broker's port 8080 and Gitea's port 3000. It
also changes Gitea's root URL and session cookie policy to permit HTTP login.
This adds host mappings to the broker's port 8080 and Git's port 3000. It
also changes Git's root URL and session cookie policy to permit HTTP login.
The direct broker port is suitable for health and API testing; technician
OAuth login remains designed for the HTTPS public URL. Do not use the
direct-port override on an Internet-facing production VM. Return to the
@@ -241,7 +241,7 @@ production URL and secure-cookie policy with:
## 6. Move repositories
For each existing repository, create an empty matching repository in the new
Gitea and mirror all refs:
Git and mirror all refs:
```sh
git clone --mirror OLD-REPOSITORY-URL
@@ -280,10 +280,10 @@ cd /YOUR/INSTALL/PARENT/TA-Deployment-Access
```
The updater operates only on the current VM. It fast-forwards the checked-out
branch, pulls the pinned Gitea and Nginx images, rebuilds and restarts the local
branch, pulls the pinned Git and Nginx images, rebuilds and restarts the local
stack, and waits for the local broker to become healthy. Certbot is not pulled
or run during a routine update; it is used only by `bootstrap` and `renew`. The
updater has no peer discovery, SSH, or multi-node update behavior.
Pin image versions as supplied and review release notes before changing them.
Never change Gitea between rootless and rootful image families in place.
Never change Git between rootless and rootful image families in place.