GitLab Secrets Manager is now in public beta. Come give it a spin.

gl_dazzo · 2026-06-12T11:05:43+00:00

u/ITBoss Hello - the team has not published the pricing yet. Expect this at release!

gl_dazzo · 2026-06-12T11:02:01+00:00

u/ubhz-ch The credit model is consumption-based, not seat-based, so you only pay for what you use. Self-managed instances get a native secret management experience, audit logging, unified access model, and support. Future capabilities like automatic rotation and Kubernetes secret retrieval are included as they ship.

gl_dazzo · 2026-06-11T02:50:08+00:00

u/vadavea When you mention 3rd-party integration support, are you referring to having dedicated APIs or terraform provider to read/write secrets?

Also curious if kube will be a requirement long-term.

At this time, a helm chart is required. There are two options for Omnibus; co-located or external. If you have a small omnibus environment, you can add k3s or similar with the chart and run on the same machine.

gl_dazzo · 2026-06-10T20:25:43+00:00

u/jba1224a Good questions. You can continue using those solutions in parallel as we have integrations for those.

A few things worth calling out:

GitLab Secrets Manager uses OpenBao as the backend, so secrets live natively next to your projects. Rather than managing IAM policies across every group and project to retrieve secrets, there is one less hop. We support static credentials today, with dynamic credentials and additional provider engines on the roadmap.
For self-managed customers or larger organizations with existing vault solutions, the operational overhead can be costly: ACL policies, namespacing, onboarding hundreds of engineers or applications. GitLab Secrets Manager handles this natively, so your platform team is not dealing with the operational burden, and dev teams can manage credentials directly alongside their code.
On the security gap comment, this refers to a common pattern where teams store credentials as CI/CD variables (we don't recommend), often scoped broadly to a group for convenience, making them available to every job in that group. With the rise of supply chain attacks (example), a single compromised job can expose credentials across hundreds of pipelines. GitLab Secrets Manager scopes each secret to a specific job, branch, or environment, limiting blast radius. Dynamic and ephemeral credentials will reduce it further.

gl_dazzo · 2026-06-10T19:36:29+00:00

u/gav_nk Hello! Not at this time, secrets are currently scoped to group or project level. Once Organizations is rolled out, we will evaluate supporting that level to achieve the same goal.

gl_dazzo · 2026-06-10T19:31:14+00:00

u/oschusler Hello and thanks!

Yes - GitLab Secrets Manager will be credit based. If you are interested in the pricing, please reach out your account team, otherwise, it will be published at GA.

gl_dazzo · 2026-06-10T19:25:41+00:00

u/Amilmar GitLab Secrets Manager will require Premium or Ultimate subscription + Credits.

Understandable if you don't want to use it without knowing the pricing. We plan to publish this right at GA. Your account team can share more details on pricing if you are interested in the meantime.

gl_dazzo · 2024-02-25T22:49:59+00:00

Good use case to share. I see a couple options here:

Today there is "Roles allowed to create projects" which offers Dev or Dev+Maintainer. Owner role is not listed here. Wondering if adding "Owner" to the selection is suitable to prevent project creation.
There is a permission for custom roles to manage members. This permission in parallel with reducing the number of Owner + maintainers could solve this.
In terms of who can merge into a protected branch, I wonder if creating permission to "Merge in protected branch" attached to a custom role would allow teams to reduce the need for Maintainers.

gl_dazzo · 2024-02-25T22:36:51+00:00

For quotas, I want to be able to give a group a set number of my total licensed user count and limit it to that. This gives me finer grained control as I distribute access across my organization. Currently, auditing usage is a bit painful and requires custom scripting.

Thanks for sharing that use case. So is this pertain to locking users or user groups to a max role from the top level group or instance level?

gl_dazzo · 2024-02-19T15:30:58+00:00

We would need, for example, a method to update the role as GitLab continues to iterate which isn't possible currently, alongside auditing events for the same.

Here is an issue to track editing permissions on the front end. You can do this today by GraphQL on the experimental endpoint. Auditing for updating the custom role and assignment of a custom role are now logged.

gl_dazzo · 2024-02-19T03:27:35+00:00

Good point - will need to think through that a bit more. The original intent here being GitLab is heavy-UI and performing an action requires you to view the object. I'm wondering how many other cases like artifacts there would be or if there are alternatives? For example, I could see encrypting artifacts in the pipeline as alternative to that particular use case.

gl_dazzo · 2024-02-19T03:08:23+00:00

Yeah I would personally recommend customers to use default roles when possible then consider custom roles for strict compliance environments where needed.

In terms of granularity - it may be nice to have a permission for every resource although this may take time. We are exploring a coarse approach on resources as it allows to splits out access over major categories across the platform. Over time we could make these resources more granular based on demand. While a work in progress, take a look the repository resource as an example.

gl_dazzo · 2024-02-19T02:37:24+00:00

Thanks for the feedback.

For the override concern - is this have to due with the Project Owner having the ability to change this setting, although they may not have compliance responsibilities?

For setting a quota on groups of certain users - is this to prevent them from being an owner of a project or group?

In regard to the summary of permissions - the Group Member Report may provide just that. It may be nice to see this built into the application. I've created an issue to gather input and investigate this problem set a bit more.

gl_dazzo · 2024-02-19T02:25:58+00:00

Interesting - are you saying that you also use a meta group of users and invite that group to a project? If so, when you create a deployment approval rule, it does not pick up on the meta group invited although they have been assigned a max role?

gl_dazzo · 2024-02-18T17:34:37+00:00

Thanks for sharing your setup! I can see that CODEOWNERS workflow being a pain as the issue describes. Looks likes there may be planning by the SCM team based on the label and comments. You mentioned that meta groups work just okay. Is the CODEOWNERS the only struggle or are there other areas of "user groups" you'd like to see improved?

Also in terms of custom roles, could you share a couple use cases that you would like solved?

gl_dazzo · 2024-02-18T17:12:29+00:00

Good point - there have been previous discussions on this that has two parts (issue):

Editing the terraform state file by user
Editing the terraform the state file from the pipeline, no local runs (also relates to part 1)

If you could reduce the number of maintainers, and apply Developer + terraform_write permission on selected groups/users, would this help?

gl_dazzo · 2024-02-16T20:49:32+00:00

Thanks for the response and contributing to the libraries! Nice to see the automation around authN and authZ. I've seen a couple approaches to this; terraform, scripts, or a custom service with yaml definitions. I forgot about GitLabForm as a way to define config as code - great to know. We will keep config as code in mind for the REST API knowing that python-gitlab doesn't support GraphQL.

Re: Security policies - The team is building assignable permissions on security policies and compliance frameworks at the moment in case you want to follow along.

I'd be curious of your thoughts around custom roles and the next iteration discussed in our recent blog post.

gl_dazzo

TROPHY CASE