Merge remote-tracking branch 'origin/develop' into chore/extract-the-personal-vcs-access-token

Both sides add to LocalVCServletService rather than change the same
code: the build agent hardening adds its four dependencies alongside
the VCS access token service, and its shortcut returns before
authenticateUser, so it never meets the AuthenticatedUser record.

The bean budget is measured, not added up: 151 edges with a longest
chain of 10, which is develop's 143 plus three account services and
five build agent beans that turn out not to overlap.

master.xml keeps the changelogs in timestamp order, and the new
build agent test gets the constructor argument this branch added.

Author: krusche

.github/workflows/ci-bean-instantiations.yml

@@ -26,12 +26,19 @@ jobs:
       MAX_STARTUP_DEPENDENCY_CHAIN_LENGTH: 10
       MAX_DEFERRED_CHAIN_LENGTH: 16
       MIN_INSTANTIATED_BEANS: 20
-      # develop's 143 plus the three account-module services that hold the columns moved out of jhi_user - the VCS access
-      # token, the recovery keys and the activity timestamps. Each is reached at startup through a consumer that is
-      # already eager (LocalVCServletService, UserCreationService, UserService), and the class-level @Lazy they carry
-      # cannot stop a consumer whose own constructor needs them. Measured with the check's own command: 146 edges,
-      # longest chain 10.
-      MAX_INSTANTIATED_BEANS: 146
+      # develop's 143 plus two independent sets of eager beans, measured together at 151 edges, longest chain 10.
+      #
+      # Three account-module services hold the columns moved out of jhi_user - the VCS access token, the recovery keys
+      # and the activity timestamps. Each is reached at startup through a consumer that is already eager
+      # (LocalVCServletService, UserCreationService, UserService), and the class-level @Lazy they carry cannot stop a
+      # consumer whose own constructor needs them.
+      #
+      # Five more come from the build agent access hardening, each pulling its own dependencies into the startup graph:
+      # BuildAgentAddressRegistryService registers cluster connection listeners and a scheduled refresh,
+      # BuildAgentNetworkPolicy parses the configured ranges and states at startup what this node enforces, and
+      # ProxyProtocolAcceptor is installed on the ssh server before it accepts a connection. A lazy registry that
+      # nothing instantiates at startup would stay empty, and no build agent could clone.
+      MAX_INSTANTIATED_BEANS: 151
       MIN_DEFERRED_CHAIN_LENGTH: 1
 
     steps:

docker/artemis/config/playwright-postgres.env

@@ -24,3 +24,9 @@ ARTEMIS_CONTINUOUSINTEGRATION_BUILDTIMEOUT="30"
 
 JENKINS_INTERNALURLS_CIURL="https://jenkins-test.artemis.in.tum.de"
 JENKINS_INTERNALURLS_VCNURL="https://artemis.in.tum.de"
+
+# Jenkins with LocalVC is the one topology that still needs the shared build-agent credential: this stack runs localvc
+# without localci, so there are no build jobs and no clone tokens, and Jenkins is not an Artemis build agent. A value
+# other than the shipped `buildjob_password`, which the prod profile rejects as a published default.
+# checkov:skip=CKV_SECRET_6: fixture credential of the local E2E stack, not a deployment secret
+ARTEMIS_VERSIONCONTROL_BUILDAGENTGITPASSWORD="local-e2e-buildagent-not-a-deployment-credential"

docker/artemis/config/playwright.env

@@ -43,11 +43,10 @@ ARTEMIS_TELEMETRY_ENABLED="false"
 # stacks run under the prod profile. Every service here reads this file, so all of them share one key.
 JHIPSTER_SECURITY_AUTHENTICATION_JWT_BASE64SECRET="${ARTEMIS_E2E_JWT_SECRET:?not set. Use one of the E2E runner scripts, or export it yourself: the output of openssl rand -base64 64, joined into a single line}"
 
-# The prod profile also rejects the `buildjob_password` shipped in application-buildagent.yml / application-localvc.yml,
-# which the LocalCI stacks would otherwise inherit. Artemis and the build agent run in the same container here, so one
-# value covers both sides.
-# checkov:skip=CKV_SECRET_6: fixture credential of the local E2E/multi-node stacks, not a deployment secret
-ARTEMIS_VERSIONCONTROL_BUILDAGENTGITPASSWORD="local-e2e-buildagent-not-a-deployment-credential"
+# No shared build-agent credential here on purpose. This file is shared by every Playwright stack, and the LocalCI ones
+# run a node that refuses to start with one configured - build agents there authenticate with the clone token of the
+# build job they are running. The Jenkins with LocalVC stack is the exception and sets it in playwright-postgres.env,
+# which only that stack uses.
 
 # Token is valid 3 days
 JHIPSTER_SECURITY_AUTHENTICATION_JWT_TOKENVALIDITYINSECONDS="259200"
@@ -68,3 +67,16 @@ MANAGEMENT_METRICS_EXPORT_PROMETHEUS_ENABLED="true"
 
 # Activate E2E seed data via Liquibase
 SPRING_LIQUIBASE_CONTEXTS="prod,e2e"
+
+# Nginx forwards the git ssh port at the TCP level and announces the real client with a PROXY protocol header
+# (proxy_protocol on, see docker/nginx/nginx.conf). Without this, the ssh server would attribute every connection to
+# nginx: git ssh rate limiting would share one bucket across all users and the access log would record the proxy.
+#
+# !!! NOT A PRODUCTION VALUE. Do not copy this line into a real deployment. !!!
+# These are the docker bridge ranges, which is where nginx sits in a compose stack. Compose assigns container addresses
+# dynamically, so there is no single address to name here. The cost is that anything able to connect from inside these
+# ranges could forge a client address and name an arbitrary ssh client; that is acceptable only because a compose test
+# stack is not a trust boundary and nothing else reaches port 7921 in it.
+# A real deployment must name its load balancer's own address, and should restrict port 7921 at the firewall so that
+# only the load balancer can reach it. See the "SSH behind a load balancer" section of the security documentation.
+ARTEMIS_VERSIONCONTROL_SSHPROXYPROTOCOL_TRUSTEDSOURCES="172.16.0.0/12,10.0.0.0/8,192.168.0.0/16"

docker/artemis/config/prod-multinode-fast.env

@@ -63,9 +63,17 @@ JHIPSTER_SECURITY_AUTHENTICATION_JWT_TOKENVALIDITYINSECONDSFORREMEMBERME="259200
 ARTEMIS_VERSIONCONTROL_URL="http://localhost:8081"
 ARTEMIS_VERSIONCONTROL_USER="artemis_admin"
 ARTEMIS_VERSIONCONTROL_PASSWORD="local-e2e-admin-not-a-deployment-credential"
-ARTEMIS_VERSIONCONTROL_BUILDAGENTGITUSERNAME="buildjob_user"
-# checkov:skip=CKV_SECRET_6: fixture credential of the local E2E/multi-node stacks, not a deployment secret
-ARTEMIS_VERSIONCONTROL_BUILDAGENTGITPASSWORD="local-e2e-buildagent-not-a-deployment-credential"
+# Deliberately empty, and this is the point of it. Build agents authenticate with the clone token of the build job they
+# are running, and BuildJobGitService silently falls back to this shared pair whenever a job carries no token. With the
+# pair configured, a completely broken token path would still let every E2E test pass through the fallback, so nothing
+# here would ever fail. Leaving it empty makes the token path load-bearing: if it breaks, these tests break.
+#
+# This stack is the right place for it because it covers both agent topologies at once - node-3 is a standalone build
+# agent (a middleware client, whose origin is observable) and node-2 is co-located with a core node (no client
+# connection, so nothing to observe). Do not restore these values to "fix" a failing build; a failure here means the
+# token path is genuinely broken.
+ARTEMIS_VERSIONCONTROL_BUILDAGENTGITUSERNAME=""
+ARTEMIS_VERSIONCONTROL_BUILDAGENTGITPASSWORD=""
 
 ARTEMIS_CONTINUOUSINTEGRATION_ARTEMISAUTHENTICATIONTOKENVALUE="demo"
 ARTEMIS_CONTINUOUSINTEGRATION_DOCKERCONNECTIONURI="unix:///var/run/docker.sock"
@@ -109,3 +117,8 @@ INFO_OPERATORNAME="TUM"
 SPRING_LIQUIBASE_CONTEXTS="prod,e2e"
 
 MANAGEMENT_METRICS_EXPORT_PROMETHEUS_ENABLED="true"
+
+# Same as the containerised multi-node setup: nginx forwards 7921 with proxy_protocol on. Here the Artemis nodes run
+# on the host, so the header arrives from the docker gateway, which is inside these ranges.
+# !!! NOT A PRODUCTION VALUE. Do not copy this line into a real deployment. !!! See prod-multinode.env for why.
+ARTEMIS_VERSIONCONTROL_SSHPROXYPROTOCOL_TRUSTEDSOURCES="172.16.0.0/12,10.0.0.0/8,192.168.0.0/16"

docker/artemis/config/prod-multinode.env

@@ -44,10 +44,24 @@ JHIPSTER_SECURITY_AUTHENTICATION_JWT_BASE64SECRET="${ARTEMIS_E2E_JWT_SECRET:?not
 ARTEMIS_VERSIONCONTROL_URL='http://artemis-app-node-2:8080'
 ARTEMIS_VERSIONCONTROL_USER='artemis_admin'
 ARTEMIS_VERSIONCONTROL_PASSWORD='local-e2e-admin-not-a-deployment-credential'
-ARTEMIS_VERSIONCONTROL_BUILDAGENTGITUSERNAME='buildjob_user'
-# checkov:skip=CKV_SECRET_6: fixture credential of the local E2E/multi-node stacks, not a deployment secret
-ARTEMIS_VERSIONCONTROL_BUILDAGENTGITPASSWORD='local-e2e-buildagent-not-a-deployment-credential'
+# Deliberately empty: these nodes run local CI, which refuses to start with a shared build-agent credential configured.
+# Build agents authenticate with the clone token of the job they are running, which is what this stack exercises.
+ARTEMIS_VERSIONCONTROL_BUILDAGENTGITUSERNAME=''
+ARTEMIS_VERSIONCONTROL_BUILDAGENTGITPASSWORD=''
 ARTEMIS_CONTINUOUSINTEGRATION_ARTEMISAUTHENTICATIONTOKENVALUE='demo'
 ARTEMIS_CONTINUOUSINTEGRATION_DOCKERCONNECTIONURI='unix:///var/run/docker.sock'
 ARTEMIS_GIT_NAME='artemis'
 ARTEMIS_GIT_EMAIL='artemis@example.com'
+
+# Nginx forwards the git ssh port at the TCP level and announces the real client with a PROXY protocol header
+# (proxy_protocol on, see docker/nginx/nginx.conf). Without this, the ssh server would attribute every connection to
+# nginx: git ssh rate limiting would share one bucket across all users and the access log would record the proxy.
+#
+# !!! NOT A PRODUCTION VALUE. Do not copy this line into a real deployment. !!!
+# These are the docker bridge ranges, which is where nginx sits in a compose stack. Compose assigns container addresses
+# dynamically, so there is no single address to name here. The cost is that anything able to connect from inside these
+# ranges could forge a client address and name an arbitrary ssh client; that is acceptable only because a compose test
+# stack is not a trust boundary and nothing else reaches port 7921 in it.
+# A real deployment must name its load balancer's own address, and should restrict port 7921 at the firewall so that
+# only the load balancer can reach it. See the "SSH behind a load balancer" section of the security documentation.
+ARTEMIS_VERSIONCONTROL_SSHPROXYPROTOCOL_TRUSTEDSOURCES="172.16.0.0/12,10.0.0.0/8,192.168.0.0/16"

docker/artemis/config/prod-singlenode.env

@@ -1,2 +1,15 @@
 EUREKA_CLIENT_REGISTERWITHEUREKA=false
 EUREKA_CLIENT_FETCHREGISTRY=false
+
+# Nginx forwards the git ssh port at the TCP level and announces the real client with a PROXY protocol header
+# (proxy_protocol on, see docker/nginx/nginx.conf). Without this, the ssh server would attribute every connection to
+# nginx: git ssh rate limiting would share one bucket across all users and the access log would record the proxy.
+#
+# !!! NOT A PRODUCTION VALUE. Do not copy this line into a real deployment. !!!
+# These are the docker bridge ranges, which is where nginx sits in a compose stack. Compose assigns container addresses
+# dynamically, so there is no single address to name here. The cost is that anything able to connect from inside these
+# ranges could forge a client address and name an arbitrary ssh client; that is acceptable only because a compose test
+# stack is not a trust boundary and nothing else reaches port 7921 in it.
+# A real deployment must name its load balancer's own address, and should restrict port 7921 at the firewall so that
+# only the load balancer can reach it. See the "SSH behind a load balancer" section of the security documentation.
+ARTEMIS_VERSIONCONTROL_SSHPROXYPROTOCOL_TRUSTEDSOURCES="172.16.0.0/12,10.0.0.0/8,192.168.0.0/16"

docker/nginx/nginx.conf

@@ -48,5 +48,12 @@ stream {
     server {
         listen 7921;
         proxy_pass artemis;
+        # specific Artemis change: announce the real client to the ssh server.
+        # A plain TCP proxy_pass hides it, so every ssh connection would look like it came from this container:
+        # git ssh rate limiting would share one bucket across all users, and the access log would record nginx.
+        # Artemis reads the header when the connection comes from an address listed in
+        # artemis.version-control.ssh-proxy-protocol.trusted-sources, which the shipped env files set to the
+        # docker bridge ranges. Removing this line requires clearing that property, or ssh connections are refused.
+        proxy_protocol on;
     }
 }

documentation/docs/admin/jenkins-localvc.mdx

@@ -64,7 +64,7 @@ artemis:
       user: root
       password: dummy # has to be set, but does not matter for LocalVC
       build-agent-git-username: jenkins
-      build-agent-git-password: artemis_admin # choose some strong password and username (gives read access to all repositories)
+      build-agent-git-password: <choose a strong password> # gives read access to all repositories, so do not reuse another credential. Values Artemis has published, artemis_admin among them, are rejected under the prod profile
   continuous-integration:
       user: artemis_admin
       password: artemis_admin
@@ -168,7 +168,7 @@ The following steps describe how to deploy a pre-configured version of the Jenki
            user: root
            password: dummy # have to be set, but does not matter for LocalVC
            build-agent-git-username: jenkins
-           build-agent-git-password: artemis_admin # choose some strong password and username (gives read access to all repositories)
+           build-agent-git-password: <choose a strong password> # gives read access to all repositories, so do not reuse another credential. Values Artemis has published, artemis_admin among them, are rejected under the prod profile
        continuous-integration:
            user: artemis_admin
            password: artemis_admin

documentation/docs/admin/production-setup/multiple-artemis-instances.mdx

@@ -589,28 +589,23 @@ You can make following adaptations to the `application-prod.yml`:
 
 3. Furthermore, you will need some configuration related to version control and continuous integration.
 
-    Build agents require access to the VC server. How they authenticate for it is selected by
-    `artemis.version-control.build-agent-use-ssh`, and the credentials below belong to only one of the two options:
-
-    - `true` (**recommended**): each agent generates an SSH key pair at startup and authenticates with it, so there is no
-      shared credential to configure and `build-agent-git-username`/`build-agent-git-password` may be omitted entirely.
-    - `false` (default, **deprecated**): the agents clone over HTTPS with the credentials below, which you must add to the
-      build agents and to the localvc nodes alike.
-
-    The HTTPS credentials are therefore required only for that second configuration; the SSH setup is described after the
-    example below.
+    Build agents need to reach the VC server to clone repositories. They authenticate themselves: over HTTPS with the clone token of the build job they are running, or with an SSH key as described after the example below. Neither needs any configuration here.
 
     ```yaml
     artemis:
         version-control:
             url: <url-to-your-vc-server>
             default-branch: main # The branch that should be used as default branch for all newly created repositories. This does NOT have to be equal to the default branch of the VCS
-            # Artemis admin credentials
-            build-agent-git-username: buildjob_user # Replace with more secure credentials for production. Required for https access to localvc, and ignored when build-agent-use-ssh is true
-            build-agent-git-password: buildjob_password # Replace with more secure credentials for production. Required for https access to localvc, and ignored when build-agent-use-ssh is true
     ```
 
-    The order matters when you switch an existing installation over. Set `artemis.version-control.build-agent-use-ssh: true` on the build agents first — localvc nodes accept a registered agent's key regardless of their own setting, so builds keep working, and you can move agents one at a time — and only afterwards on the localvc nodes, where it stops that credential pair from granting build agents read access to every repository. Doing it in the other order breaks every agent still cloning over HTTPS. See [Build Agent Authentication](/admin/production-setup/security#build-agent-authentication).
+    Build agents need no credential from you here. Choose in this order:
+
+    1. **SSH keys, recommended.** Set `artemis.version-control.build-agent-use-ssh: true` together with `ssh-template-clone-url` and `ssh-private-key-folder-path`. Every agent then generates its own key pair at startup and publishes only the public key — nothing to distribute or rotate. Roll it out on the build agents first (localvc nodes accept a registered agent's key regardless of their own setting, so builds keep working) and on the localvc nodes afterwards.
+    2. **Build job clone tokens**, used automatically over HTTPS while `build-agent-use-ssh` is `false`. This needs no configuration at all.
+
+    Do **not** set `build-agent-git-username` or `build-agent-git-password` on these nodes — a node that runs local CI **refuses to start** with either of them configured, whether or not the agents use SSH. The pair is a static secret opening every repository that nothing here needs, and it belongs only to a localvc node without local CI, which is [Jenkins with LocalVC](/admin/jenkins-localvc).
+
+    Note that a multi-node setup terminates SSH on the load balancer, which hides the real client from the SSH server. Enable PROXY protocol in the nginx `stream` block and list the balancer in `artemis.version-control.ssh-proxy-protocol.trusted-sources` on every localvc node; the Docker Compose files in this repository already do both. See [Build Agent Authentication](/admin/production-setup/security#build-agent-authentication) for this and for restricting which networks build agents may connect from.
 
 4. Configuration related to the execution of build jobs: