splunk / vault-plugin-secrets-gitlab

Vault Plugin for Gitlab Project Access Token

Splunk OCSF Extension

The Splunk schema extension repository

vault-plugin-secrets-gitlab's Issues

support for group level access token

14.7 added support for group level access token https://about.gitlab.com/releases/2022/01/22/gitlab-14-7-released/#group-access-tokens

we want to support this in this plugin.

depending on xanzy/go-gitlab#1347

run acceptance test in CI

it currently only runs unit test. we need to run acceptance test in CI

self-hosted gitlab and isolated vault instance in docker

CLI to work with CI_JOB_JWT

continuing from #16, instead of scripts, create CLIs to facilitate

1. vault resource creation - roles and policies
2. script in a job that authenticate with vault with CI_JOB_JWT then hit token endpoint to get credentials

documentation for group/project level secret mount installment

I've tested at instance level where an admin token is used. This allows to create project access token for any projects.

For SaaS or limited use, this secret mount should work for

• group maintainer or higher access token for projects under a group
• project maintainer or higher access token for a project

We'll need to test and document that situation where group maintainer token is used. it should be able to create project access token for projects under the group. it shouldn't be able to create project access token for a project outside of the group where the token configured in plugin doesn't have access to.

expires_at is required by gitlab ~16.3

Hi, I'm testing this plugin which would be very useful for an instance-scoped external CI pipeline. But when I tried the examples in the README this error appears:

vault write gitlab/token id=1 name=ci-token scopes=api,write_repository
Error writing data to gitlab/token: Error making API request.

URL: PUT https://<vault host>/v1/gitlab/token
Code: 400. Errors:

* Failed to create a token - POST https://<gitlab host>/api/v4/projects/1/access_tokens: 400 {error: expires_at is missing}

Apparently Gitlab is changing the policy wrt expires_at, and now it's being required.

https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/issues/4133

Could you please include this in the requests?

Instruction with GitLab CI_JOB_JWT

creating instruction how to setup project with CI_JOB_JWT with secure manner

1. setting up vault instance with gitlab
2. vault resource and policy that only configured project can hit specific vault path. e.g. gitlab/roles/my-project-1-role and gitlab/token/my-project-1-role
3. hit token endpoint from job script

revoke token

Implement revoke token functionality. Currently, generated tokens are either expired or manually revoked. No-longer-needed token should also be revoked programmatically.

AC:

generic path revoke which accepts below to revoke
{
"id": ,
"token_id": ,
}

we'll want a control that a only generated token can be revoked by the requested entity. plane /revoke endpoint may not be sufficient for it.

Lift API rate limit for SaaS Gitlab

For self-hosted GitLab, admin can lift API rate limit per origin of user.
For SaaS GitLab, there's a limit documented here. it's 2000 rpm for authenticated access. This shouldn't be a problem for even large usages. But in case this plugin user surpasses the rate limit, premium/ultimate customers should be able to request for the lift.

We need to document it

token TTL

token TTL implementation is not great. this is because GitLab doesn't implement custom token expiry in minutes/hours. token always expire at midnight UTC.

https://gitlab.com/gitlab-org/gitlab/-/issues/335535

Add security scanning tool like OSS and SAST

dependabot takes care of updating dependencies.

We should have a security scanning integrated in CI

• OSS(once a week on main)
• SAST(every push, and once a week on main)

SPIKE: feasibility with native gitlab vault support

gitlab natively supports vault in ci yaml.
https://docs.gitlab.com/ee/ci/yaml/#secretsvault
https://docs.gitlab.com/ee/ci/secrets/

check detailed implementation of it and feasibility of using this secrets backend instead of kv

document if it's possible or not

Add access level support

https://docs.gitlab.com/ee/api/resource_access_tokens.html#create-a-project-access-token

when you create a project access token, it now supports setting access level

• default 40 (Maintainer)
  A valid access level. Default value is 40 (Maintainer). Other allowed values are 10 (Guest), 20 (Reporter), and 30 (Developer).