<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=619690) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=619690) </details> <!--IssueSummary end--> ## Summary GitLab selects the transport for its IAM gRPC clients from `Rails.env`. The transport is not a configuration item. This issue makes the transport explicit. Two methods add a `tls://` prefix when `Rails.env` is not `development`: - `lib/authn/iam_data_access_service.rb:20` - `lib/authn/iam_auth_service.rb:19` and `:35` One guard then refuses a plain-text channel outside development and test: - `lib/authn/iam_service/base_client.rb:49` The configuration holds `secret_file`, `grpc.host`, and `grpc.port` only (`config/initializers/1_settings.rb:661-665`, `config/gitlab.yml.example:931-940`). No value of `grpc.host` reaches a plain-text channel, because the guard stops each attempt. **This work is not specific to `gitlab-org/gitlab`.** The attached plan covers each problem that the investigation found. The plan spans Rails, the GitLab chart, LabKit, Fairway, Artifact Registry, iam-data-access, and the Caproni development rig. The three problems in the plan are TLS on each hop inside a cluster, transport by configuration, and configurable ports. The change in this repository is one part of that plan, and other parts do not wait for it. ### Proposed change in this repository 1. Accept a scheme in the configured host. Permit `grpc://` and `tls://`. 2. Pass the scheme through `grpc_address` in both services. 3. Add `grpc://` to `strip_scheme` in `base_client.rb`. 4. Change the trigger of the guard. Permit plain text only when the operator asks for it. Do not remove the guard. 5. Write a log message that gives the endpoint when the client uses plain text. `Gitlab::Spamcheck::Client` is the model (`lib/gitlab/spamcheck/client.rb:113-119`). That client has the same logic for the channel credentials. It takes the scheme from the operator, and it has no guard for the environment. The GitLab chart needs no change for this item. The chart renders `grpc.host` as a free string, and validates the presence of the value only. ### Acceptance criteria - An address of `grpc://host:port` gives a plain-text channel in production. - An address of `host:port` continues to fail in production. - An address of `tls://host:port` keeps the current behaviour. - The application writes one log message for a plain-text endpoint. ## Improvements - An operator controls the transport. The environment does not control it. - An operator can connect to a peer that serves plain text inside a trusted network boundary. The operator must ask for that transport. - The change removes the need for `RAILS_ENV=development`. The Cloud Native GitLab images exclude the `development` gem group. Those images cannot start in that mode, so the current workaround is not available to them. - The change removes the need for a proxy that serves TLS and plain text together. That proxy was the alternative design for a cluster where the peer service cannot serve TLS. - A reader of the configuration sees the transport. The transport is no longer an assumption in the code. ## Risks - **An operator could select plain text by mistake.** The default stays TLS. A bare `host:port` address continues to fail outside development and test. The guard remains, and only an explicit scheme changes the result. The application logs the plain-text endpoint. - **Two services change together.** `Authn::IamAuthService` has the same defect, and this issue changes both. A deployment that terminates TLS at a platform edge keeps `tls://`, and the behaviour of that deployment does not change. - **`strip_scheme` is easy to miss.** Without step 3, the stub receives `grpc://host:port` and the connection fails. A test must cover this case. ## Involved components In this repository: - `lib/authn/iam_data_access_service.rb` - `lib/authn/iam_auth_service.rb` - `lib/authn/iam_service/base_client.rb` In other projects, from the attached plan. These need no change here: - `gitlab-org/charts/gitlab` — a key for `artifact_registry.api_url`. - LabKit — TLS fields in the configuration of the HTTP server. - Fairway — a configurable service port, a configurable probe port, mounts for init containers, and the host in the ingress rule. - `gitlab-org/auth/iam` — native TLS for the gRPC server. - `gitlab-org/ops/artifact-registry` — TLS for the HTTP server. - `gitlab-org/gitlab-caproni` — certificates from cert-manager, and trust for the certificate authority. ## Optional: Intended side effects - The Caproni development rig operates without GitLab edit mode after this change. The rig documents edit mode as obligatory today. - Follow-up work, in separate issues: a client key pair in `base_client.rb` for mutual TLS, and the chart key for `artifact_registry.api_url`. ## Optional: Missing test coverage - Specs that assert the current address for each of the two services. - New cases for `grpc://`, for `tls://`, and for a bare address. - A case that confirms `strip_scheme` removes `grpc://`.