Allow user to specify verificationToken value at destination creation via API

Release notes

Problem to solve

Users today use the verificationToken value in our API to confirm that the audit events being sent from GitLab are valid and not from an alternate source impersonating GitLab.

Many users organizations block traffic that is not on an allowlist. To get streaming audit event traffic on such allow lists, it must be set up, the verificationToken recorded, and then that token added to the allow list. This is a time-consuming process and it also means events will be lost between the time of setting up streaming and getting the token on the allow list. Instead, users would prefer a way to decide on a value and update both systems at once, rather than needing to do a multi-step process.

Proposal

When the a streaming audit event destination is created, allow the user to optionally pass in their own value for verificationToken to be used. If the user provides the parameter in the API call, use that value instead of generating one.

Note: Ensure the value is strong enough not to be guess (e.g. dog is bad, require a longer hexadecimal string perhaps.) Struck this because we don't have a way to specify a policy, our policy might conflict with user choice, and if user is opting-in to set their own token, they presumably know what they are doing and can pick a secure token value.

Implementation Proposal

• Alter the externalAuditEventDestinationCreate mutation to take an optional verificationToken value.
• Ensure that this value is validated against a minimum length requirement.
• Update documentation with new functionality.

Tiering

GitLab Ultimate

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.