-
Notifications
You must be signed in to change notification settings - Fork 973
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rules to the config repo #7605
Comments
cc: @tomzo FYI (for context: #3636 (comment)) |
To your questions:
|
If we go down this path, the combination |
I meant:
... should apply to agents too, right? I don't think |
@arvindsv Yes, we can only specify agents UUID. So the |
I agree on that part. The other option is allowing explicitly every resource that was created there. Which would costly to implement because it would require to parse config repos first and then migrate the xml. I not sure if the Consider what's the difference for user in these cases: case 1
With config repo: pipelines:
mypipe:
group: mygroup case 2Then what's the benefit being able to configure this?
With config repo: pipelines:
mypipe:
group: mygroup |
@tomzo Correct, the pipeline group will be created via reference only. But if the said group does not already exist in GoCD, we explicitly use to create one. Hence, the So, in the case 2 above, the The same goes for environment as well. |
Can |
I mean: Does |
If a team/project follows certain pattern that their environments/pipeline groups/pipelines must adhere to, then maybe yes, a |
What happens when there are two pipelines in the same group pg_1. What is the minimum permission required to create and then refer a pipeline-group? |
That was my point. I think, it's more intuitive for user. |
Multiple config-repos can add pipelines to the same group. So taking in the points suggested above, maybe we can remove
So, with this table in mind, the min. permission for scenario raised by @adityasood would be |
Let's consider a couple of scenarios:
This is possible using:
This isn't possible currently since the What other scenarios can we think of, that might be useful? |
What does that mean? I'm not sure I understood @adityasood's question.
Doesn't the refer provide control over the name / pattern? |
What I meant was |
What I understood was that there are two pipelines which are in same group coming from config-repos. Now these two can either come from the same config-repo or different. @adityasood Is my understanding correct? |
Ah, yes. Maybe we're missing a: |
I like to think of it as |
Agreed. |
Right. Unlike pipeline, those two can be defined in either place (config XML or config repo). And they'll be merged together. We can just say: |
@kritika-singh3 yes that is what I meant. |
I am just wondering if the rules should be defined on a config repo or on the entities the config repo refers to (environment, pipeline_group or pipeline). With granular authorization, we can have a non System Admin with permission to create a config_repo. Now, this user can create a config repo and define rules which grants access to refer to any environment or pipeline_group. Am I thinking right? |
Yes, you're thinking right (and what you say will be possible), but trying to prevent that will mean that the permissions will be much harder to understand. We might have to knowingly allow this to happen. Also, it's about referring. You cannot access (or administer) a pipeline that is already defined. However, I know that it will lead to escaping the permissions provideed to a non-system-admin. |
IMO, rules defined on the config-repos will give us a centralised control over what all can be modified by the entity in question. Adding rules on env and pipeline group, will be two separate places of edit/errors. Also, if in future we expand the scope of config-repo, we would need to add the rules on them as well. For RBAC, I was thinking of introducing a separate action, which when granted, will give permission to edit rules. But this would require that the rules declaration/modification should be via a different endpoint rather than using existing config-repo creation/modification endpoints. |
@maheshp @kritika-singh3 good points Pros and Cons of both options:
Is there an option to restrict non-system-admins from creating config repos and elastic agent profiles? Then we can go with option2 @arvindsv wdyt? |
Yes. It is restricted to system admins only. However, with recent improvements to granular auth (see "Improvements to Role Based Access Control" in https://www.gocd.org/releases/#19-12-0), it is possible to delegate access to administer config repos to non-system-admins as well. So, it is an option. My opinion is that: Since it is an option to provide access to non-system-admins, we can go with option 2 in your comment above and keep it at the config repo. |
Summarizing:
The rules defined for that config repo will govern what all entities can be added/referred to the GoCD. Proposed actions are:
Note: Example of the config: <config-repo pluginId="json.config.plugin" id="json">
<git url="/tmp/config-repo" />
<rules>
<allow action="refer" type="environment">env_*</allow>
<allow action="define" type="pipeline">teamA_*</allow>
<allow action="refer" type="pipeline">common_*</allow>
</rules>
</config-repo>
Does this need any change? |
@kritika-singh3 @arvindsv I believe we are adding a new action |
You mean It's true that it can be confusing if it's not there. But then, without it, we can't support scenario (2) (in that comment) and allow namespacing within a pipeline group. Is that ok? |
Yeah I meant I think it is ok for now to not allow namespacing within a pipeline group. Based on specific use cases we can add it later, probably that might require a config migration to support default behaviour. |
Ok, I can live with that. |
Great!!! I have updated the issue description with the conclusion. |
Closing this issue since Rajiesh has tested the PR's |
Issue Type
Summary
Epic Issue: #5175 (search for
Better authorization
), #3636Proposal: Add
Rules
to the config repo to allow/deny creation/access to environments, pipeline groups and pipelines.The rules defined for that config repo will govern what all entities can be added/referred to the GoCD. Proposed actions are:
Note:
Deny
rule will take precedence.Example of the config:
Need to decide:
deny
all? The existing GoCD installations using config-repos may break if so. (Maybe we can do a config migration to get around this?)More questions based on comments
Conclusion
Possible actions
Additional Info
deny
rule will take precedence.deny
all? The existing GoCD installations using config-repos may break if so. (Maybe we can do a config migration to get around this?): Yes, the default rule will bedeny
. Will consider a config migration to add a defaultallow
all entity.The text was updated successfully, but these errors were encountered: