Update offering notes with all three offerings

Co-authored-by: Lysanne Pinto <lpinto@gitlab.com>

This reverts commit 0d054978.

These links just changed in the Runner repo. Let's update them here
so they stay in sync.

Make clear how old these images actually are.

Co-authored-by: Amy Qualls <aqualls@gitlab.com>

This commit allows to akeyless vault integration within gitlab.
Introduced as an experiment and could be removed at any time.

Co-authored-by: Amir Maor<>

The parenthesis was in the wrong place, causing text to be dropped
and a bad link.

In GitLab 16.11
!146881
introduced the `groups_direct` fields for CI JWT tokens used in the
Vault integration. However, since JWT tokens are often sent in the
`Authorization` HTTP header, the addition of the `groups_direct` field
can cause the header to exceed the maximum allowed header size of
Web/proxy servers.

To avoid this issue, put this `groups_direct` field behind a
`ci_jwt_groups_direct` feature flag while we figure out the best way
to handle this.

Relates to #467253

Changelog: changed

GCP Secret Manager will not work with most projects used by GitLab employees due to repo path length.

Co-authored-by: Marcel Amirault <mamirault@gitlab.com>

Co-authored-by: Christina Lohr <clohr@gitlab.com>

Daphne Kua authored 8 months ago and Daphne Kua committed 8 months ago

Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: Marcel Amirault <mamirault@gitlab.com>

Fix navigation language and minor vale and formatting
tweaks.

In gitlab-runner!4718
support was added for using GCP secrets from a project other than the
one containing the WIF pool. This is done by specifying the
fully-qualified secret name.

Document the feature in the GCP secret manager documentation.

Part of gitlab-runner#37487

relates to !150362

The audience of the JWT should be explicit—matching the party it was intended to be given to / used by. 
In these examples, the token is created to attest identity to the Vault server, so the audience is the Vault server. 
Using the opposite party (gitlab instance) as the audience would prevent Vault from validating
if a provided JWT was issued for usage in Vault server or if it was issued for a different service and 
is being co-opted to authenticate with Vault. 

There's too much content about rules variations for one page,
so we need a dedicated page for these examples and details

- /doc/ci/secrets/index.md
- /doc/ci/yaml/index.md

This is needed in order to be able to filter users by group in Vault
secrets management integration.

#435848

Changelog: changed

Another batch of links, fixed.

Related to: #439130