@fcatteau any update here?

@jtouchstone1 Any other questions teams are asking in their reports?

@fcatteau I think its worth calling out the extra controls that play a part in limiting when secrets can actually be exposed

• Branches and Protected branches -> Secrets are limited to specific branches.
• Environments and Protected environments - Secrets are limited to specific environments.
• Merge requests and approvals -> Catch any secrets being printed before merging

While at the surface, it may seem concerning that a secret can be exposed so easily. But in reality - there are several gating mechanisms to minimize the possibility of this happening.

@fcatteau This should be a GA item. I'll leave it to you to schedule and organize.

Actual response from customer

url and internal_url must be specified in openbao config ◦ When configuring the openbao component, url and internal_url must be specified in values.yaml in the openbao section with the internal service name, local to Kubernetes. ◦ Without these config values, the GitLab webservice pod will attempt to use the DNS name to contact openbao, which will fail (in our case anyway). ◦ This would be good to be called out in the installation documentation.

@dbiryukov @fcatteau These can be post-ga. Will evaluate FE items on a continuous basis.

For group/project limits - we may bump this to a much higher value where configuring this might not be warranted. We will continue this discussion on fulfillment issue.

@fcatteau See responses below

Application limit for number of policies in groups and projects: gitlab#589588

What do we define as policy here?

Admin settings page for secrets manager limits: gitlab#588131

This should be post-ga

Inform user that they have hit Secrets Manager data limit: gitlab#588130 – right now we do have an error message but UX isn't great

What error is displayed at the moment?

Application limit for maximum secret size:

I believe this is implemented. Can you confirm?