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

<ul>
<li>All of AWS CI/CD tooling supports limiting permissions via <a href="https://aws.amazon.com/iam/" rel="nofollow noreferrer">IAM</a>.  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).</li>
<li><a href="https://www.atlassian.com/software/bamboo" rel="nofollow noreferrer">Bamboo</a> 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 <a href="https://wiki.jenkins.io/display/JENKINS/Matrix-based+security" rel="nofollow noreferrer">Jenkins</a>.</li>
<li>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.</li>
</ul>

<p>Since you are specifically looking for a strategy where the person who triggers the build has specific permissions, a <a href="https://www.atlassian.com/git/tutorials/making-a-pull-request" rel="nofollow noreferrer">Pull Request</a> workflow combined with permissions roles be what you are looking for.</p>

CC BY-SA 4.0
2019-10-15T02:11:07.963Z
2019-10-15T02:11:07.963Z
Wesley Rolnick
<p>My general experience is that CI/CD tools don't support <a href="https://www.3pillarglobal.com/insights/controlling-access-by-using-impersonation" rel="nofollow noreferrer">impersonation</a> or claims based authentication well or at-all. In addition you probably want the CI/CD tool to have <strong>more</strong> access than your users, because you want them to <strong>only use the CI/CD tool</strong> to change things.  </p>

<p>The way I have handled this in the past, however, was as follows:</p>

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

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

<p>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.</p>

CC BY-SA 4.0
2019-10-14T11:54:27.387Z
2019-10-14T11:54:27.387Z
Richard Slater
<p>TLDR Question;</p>

<p>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?</p>

<p>Full Question;</p>

<p>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 &amp; Z  whilst user B can only access Z &amp; W). </p>

<p>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. </p>

<pre><code>get_data(dataset = A, username = $USER, password=$PASSWORD)
</code></pre>

<p>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. </p>

<p>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.</p>

<p>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? </p>

<p>Any help/guidance/pointers would be greatly appreciated !</p>

<continuous-integration><cicd><role-based-access-control>
How to mange data access in a CICD pipeline for multiple users with different permissions
gowerc
# How to mange data access in a CICD pipeline for multiple users with different permissions

(Asked by: username_0 on 2019-10-14)

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 !

**Tags:** continuous-integration, cicd, role-based-access-control


---

## 2 answers

### Answer by username_1 on 2019-10-15. Score: 2

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

* All of AWS CI/CD tooling supports limiting permissions via [IAM](https://aws.amazon.com/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](https://www.atlassian.com/software/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](https://wiki.jenkins.io/display/JENKINS/Matrix-based+security).
* 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](https://www.atlassian.com/git/tutorials/making-a-pull-request) workflow combined with permissions roles be what you are looking for.


---

### Answer by username_2 on 2019-10-14. Score: 2

My general experience is that CI/CD tools don't support [impersonation](https://www.3pillarglobal.com/insights/controlling-access-by-using-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.


---

