rbac for trigger?
long-term
T
Tawny Aardvark
as we're getting rbac for inputset, can we also get rbac for trigger?
we're thinking of using inputset to specify environment & infrastructure for a service for pipeline deployment with imageTag/ReleaseVersion of artifact coming from trigger payload input.
this mean we would've a single inputset per service & a trigger per inputset, so we need developer to be able to manage inputset as well as trigger.
Log In
Rohan Gupta
Merged in a post:
RBAC Support for Triggers in Harness
J
Jambalaya Angelfish
Description:
Currently, in Harness, it is not possible to configure permissions for triggers using RBAC. Only pipeline editors have the ability to modify triggers, which limits flexibility in managing access control.
Request:
We would like to request the ability to define RBAC permissions specifically for triggers. This would allow organizations to grant or restrict access to trigger configurations independently from pipeline editing permissions.
Use Case:
In many teams, different roles manage pipelines and triggers. For example, an operations team may need to create and manage triggers without having full pipeline editing access. Introducing RBAC for triggers would enhance security and delegation capabilities.
Expected Outcome:
The ability to define roles and permissions for creating, modifying, and deleting triggers.
Separation of trigger management permissions from general pipeline editing rights.
Rohan Gupta
Merged in a post:
Ability to execute a trigger with custom and more granular privileges
B
Buff Owl
Triggers are always a part of pipeline. When a trigger is executed it first gets activated, validates the trigger conditions and if all pass then it executes the pipeline.
The trigger module today uses service principle to trigger/execute the pipeline. These are much higher/elevated privileges which trigger is using.
Instead of service principal, we should use either a service account or a user’s created token for triggering this execution.
Why do this?
Because of elevated privileges entities like secrets or expression resolutions are not adhering to RBAC during pipeline execution.
We want a feature where we can validate the payload before passing it to pipeline.
E
Ecru Hare
Is there a status on this? What is the latest?
Rohan Gupta
marked this post as
long-term
Rohan Gupta
Merged in a post:
Isolated Triggers permission from pipelines
C
Compact Bovid
We want to be able to give our developers permission to create triggers but also restrict developers from creating pipelines . Right now the permission on Resource Group only has option for pipeline which is all or nothing kind of setup . We want to separate that where the pipeline creation is denied and triggers creation are enabled
Rohan Gupta
Merging this all under one, Granular RBAC for CD.
So far we have
Service (config, artifacts, overrides)
Pipeline (Triggers, Input Sets)
Pipeline (Create only, Edit Only)
R
Representative Llama
Rohan Gupta: The List seems fine + Deny in the resource scope so it can be configured for all these entities when needed.
Not sure but this may probably fall under but not sure as this is execution time access - https://ideas.harness.io/continuous-delivery/p/rbac-for-abort-button-or-disable-it-at-org-level-for-all-user-except-acc-admin
T
Thoughtful Locust
Rohan Gupta: This seems to match with our requirements. In brief Engineers executing pipelines need to be able edit/maintain the input conditions (triggers, input sets, service overrides on an environment etc) WITHOUT being able to change the fundamental service or pipeline definition. (Segregation of duty)
Rohan Gupta
Merged in a post:
More Granular RBAC Required
H
Historic Mole
I looking more granular level access control. I already stated some of my examples in the request already.
I wanted to grant access to a developer for updating the Config Files section in services section but don’t want to grant access to edit/update Artifacts section.
Rohan Gupta
Merged in a post:
Increase granularity of RBAC controls on Pipelines
T
Thoughtful Locust
Currently the RBAC (Access Control Roles) offered on a Pipeline are limited to the "Pipeline Level".
This means that a changing Pipeline Input Sets and Triggers requires Pipeline Edit permissions.
This is inconsistent because a Pipeline can be executed WITHOUT needing Pipeline Edit.
There are probably other items on a pipeline which can be made granular as well.
Rohan Gupta
marked this post as
pending feedback
Rohan Gupta
Hi Tawny Aardvark can you elaborate why you need RBAC on triggers? If you can create or edit a pipeline you can create a trigger. What specifically are you trying to restrict? Is it more inputset related?
T
Tawny Aardvark
Rohan Gupta: kinda in the same thought process as inputset, where user dont have access to edit pipeline and we want to grant them access to edit inputset & trigger.
essentially, we're thinking of tying trigger payload to inputset, so we need to enable use to manage trigger as now trigger is dependent on inputset.
Load More
→