TLDR Question;

Is it possible to setup a CICD pipeline so that it executes with the permissions of the user who triggered the build? If so which tools support this?

Full Question;

Apologies if this is a naive question as I am new to CICD. We are trying to setup a CICD pipeline for our project which requires access to a restricted database. The issue we are facing is that each user on the project has different levels of access (which I believe is managed via LDAP) within the database (for example user A can access datasets X, Y & Z whilst user B can only access Z & W).

Due to the nature of our work, code is typically executed interactively (something we are trying to move away from) and such to execute any api that access the database users need to enter their username and password i.e.

get_data(dataset = A, username = $USER, password=$PASSWORD)

Our challenge is thus how to enable the CICD pipeline to access these data-assets without accidentally enabling people to access data that they shouldn't have access to.

I think the most obvious solution is to create a user account for the CICD tool itself, only giving it access to the datasets it needs and then embedding the username and password as secrets within the CICD tool. Our fear with this is that it then means that the project owner becomes responsible for ensuring that everyone with write access to the project has access to the data-assets that the project uses. Given user permissions change fairly frequently (as does project ownership) this doesn't seem like the safest or most sustainable way of solving the problem.

Ideally we are looking for a solution where the CICD tool executes with the same permissions as the user who triggered the build. Are there any tools that support this ? Or alternatively are there any different solutions that could solve our use-case?

Any help/guidance/pointers would be greatly appreciated !

2 Answers 2


My general experience is that CI/CD tools don't support impersonation or claims based authentication well or at-all. In addition you probably want the CI/CD tool to have more access than your users, because you want them to only use the CI/CD tool to change things.

The way I have handled this in the past, however, was as follows:

  1. Have the pipeline call the API of the CI/CD to find out who ran the pipeline
  2. Use this pipeline to look up the group's that the user is a member of this (i.e. in LDAP)
  3. If the member is of the appropriate group, continue. If not abort the build.

It's quite important to abort rather than fail the build because then it differentiates between an invalid user running the build, and a valid using running a build which then fails.

Another approach would be to sync LDAP groups with your CI/CD platform, and set permissions that way, although that may not give you the granularity you want.


Most CI/CD tooling will support permissions of some sort. For example:

  • All of AWS CI/CD tooling supports limiting permissions via IAM. IAM also ties into AD which would give you that SSO (single sign on) feel. Virtually every major cloud provider will have equivalent permission based functionality (e.g. Azure, Google Cloud).
  • Bamboo supports limiting who can edit, view, and run builds and deployments. It also supports defining global or plan variables and limiting who has access to viewing those variables. I'm sure similar functionality exists in Jenkins.
  • Most CI/CD tools can be setup to trigger based on Pull Requests. This allows only admins access to the build details while the developers can trigger builds automatically.

Since you are specifically looking for a strategy where the person who triggers the build has specific permissions, a Pull Request workflow combined with permissions roles be what you are looking for.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.