Add openbao-internal, gitlab-secrets-manager-container to GitLab projects list

Problem to solve

GitLab Secrets Manager rely on two projects that are not referenced as GitLab engineering projects, and that don't currently follow the guidelines for engineering projects.

• https://gitlab.com/gitlab-org/govern/secrets-management/openbao-internal (public)
• https://gitlab.com/gitlab-org/govern/secrets-management/gitlab-secrets-manager-container (private)

Note: This has been surfaced in gitlab-com/gl-infra/delivery#21586 (comment 2802002210).

Further details

openbao-internal builds the bao binary, and releases it using its package registry. This is a public project but the community would normally contribute to the upstream openbao project.

gitlab-secrets-manager-container builds container images, and releases them using its container registry. It's used to deploy OpenBao on staging and production using Runway.

openbao-internal is referenced in multiple projects:

• GDK
• gitlab-secrets-manager-container
• OpenBao Chart (not implemented)
• mirror project

The following projects are not in scope:

• openbao-mirror is a pull mirror of the upstream project. It's not possible to contribute to that project.
• charts/openbao is maintained by groupoperate, not by grouppipeline security.

Proposal

• Add OpenBao projects to GitLab engineer projects list.
• Align projects with checklist for GitLab repositories.
• Rename the openbao-internal project if necessary.

Projects:

• https://gitlab.com/gitlab-org/govern/secrets-management/openbao-internal (public)
• https://gitlab.com/gitlab-org/govern/secrets-management/gitlab-secrets-manager-container (private)

Implementation details

See gitlab-com/gl-infra/delivery#21586 (comment 2802037821) and https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#creating-a-new-project.

1. Read and familiarize yourself with our stance on Dogfooding. [..]
2. Ensure the project is under a subgroup of:
   • gitlab-org for anything related to the application.
   • gitlab-com for anything strictly company related.
3. Configure the project repository to use main as the name of the default branch.
4. Add the project to the list of GitLab projects in projects.yml.
5. Add a license to the repository. Contact #legal as to which license to add. A sample license is here: gitlab-org/gitlab MIT License, but contact legal before using it.
6. Add a section titled "Developer Certificate of Origin and License" to CONTRIBUTING.md in the repository. It is easiest to simply copy-paste the gitlab-org/gitaly DCO + License section verbatim.
7. Add any further relevant details to the Contribution Guide. See Contribution Example.
8. Add a link to CONTRIBUTING.md from the project's README.md.
9. Add a CODEOWNERS file, to make it easy for contributors to figure out which teams are best suited to review their changes. [..]
10. When possible, projects should have the following Merge request settings enabled [..]
11. When possible, projects should have the following Pipeline settings enabled [..]
12. Projects should have the minimum Baseline Configurations setup for MR Approval Rules and Protected Branch Settings
13. Projects should have Users can request access setting disabled to discourage granting accidental external access.
14. If needed, make sure to set up a default CI/CD configuration.
15. If the project is part of work that is shipped to customers, add it to projects_part_of_product.csv by opening an MR to that file or following the process outlined by Engineering Productivity.
16. Help AppSec categorize your new project.
17. Enable the appropriate security scanners.
18. Onboard the project to Renovate, and set up a process to regularly triage findings and update dependencies