Set SSL_CERT_FILE and nest mTLS keys in AI Gateway docs

Hamza Hassanainrequested to merge
gitlab-community/gitlab-org/gitlab:docs-aigw-ca-followup-ssl-cert-file into master

What does this MR do?

This is a follow-up to !261303 (merged). @nateweinshenker suggested both points in his review, and agreed to a follow-up MR.

I fixed two things on the AI Gateway install page:

  • "Pass the root CA certificate to the AI Gateway" set only REQUESTS_CA_BUNDLE. That is enough for token validation. Calls to a self-signed model endpoint go through LiteLLM and httpx, and the Duo Workflow Service calls GitLab with aiohttp. Those clients read SSL_CERT_FILE, not REQUESTS_CA_BUNDLE. The steps now also set SSL_CERT_FILE to the same cacert.pem file, like the container CA bundle steps already do.
  • The mTLS example for a GitLab Helm chart deployment had volumes, volumeMounts and extraEnvironmentVariables at the top level of values.yaml. Under the GitLab chart, these settings belong to the AI Gateway subchart, so I moved them under ai-gateway:, the same way as the custom CA step.

No headings changed, so existing links still work.

I checked the changed lines and parsed the new mTLS example:

$ git diff --check upstream/master...HEAD
$ python3 -c 'import yaml,sys,json; print(json.dumps(yaml.safe_load(sys.stdin)))' < mtls.yaml
{"ai-gateway": {"volumes": [{"name": "mtls-client-cert", "secret": {"secretName": "aigw-mtls-client-cert", "optional": false}}], "volumeMounts": [{"name": "mtls-client-cert", "mountPath": "/certs", "readOnly": true}], "extraEnvironmentVariables": [{"name": "AIGW_MTLS__ENABLED", "value": "true"}, {"name": "AIGW_MTLS__CERT_FILE", "value": "/certs/client.pem"}]}}

The rest runs in the pipeline.

Implemented with AI assistance; I reviewed and tested the changes.

Related issues

No issue. Related to !261303 (merged).

Author's checklist

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

  • ~"frontend"
  • ~"backend"
  • ~"type::bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • Ensure a release milestone is set.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

Merge request reports