Skip to content
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

Ability to modify default trust settings for org? #4875

Open
igniscyan opened this issue Feb 21, 2025 · 11 comments
Open

Ability to modify default trust settings for org? #4875

igniscyan opened this issue Feb 21, 2025 · 11 comments
Labels
enhancement improve existing features

Comments

@igniscyan
Copy link

For private intranet instances, is it possible to make it so repos have default trust settings for VOLUMES and NETWORK to true?

@qwerty287 qwerty287 added the enhancement improve existing features label Feb 22, 2025
@xoxys
Copy link
Member

xoxys commented Feb 24, 2025

As discussed in matrix, this is not possible right now. However, would be a nice enhancement.

Also from the chat:

We had the idea of adding a config file configuring repo options, that could be placed next to the workflow configs some time ago which might solve your request

Security settings should not be read from a file in the git repo. This is IMO very dangerous in case someone gets write access to a repo.

I would be fine if this gets implemented as org/user setting that can be configured via UI/API/CLI.

@igniscyan
Copy link
Author

igniscyan commented Feb 24, 2025

As discussed in matrix, this is not possible right now. However, would be a nice enhancement.

Also from the chat:

We had the idea of adding a config file configuring repo options, that could be placed next to the workflow configs some time ago which might solve your request

Security settings should not be read from a file in the git repo. This is IMO very dangerous in case someone gets write access to a repo.

I would be fine if this gets implemented as org/user setting that can be configured via UI/API/CLI.

Thanks for the response here - and apologies if it looks like I re-asked. I posted here first and got a reply in matrix shortly after.

I'd love to look into getting involved and seeing if I can make this change!

How do we expect this to look? Should it be a repositories tab within an org/repo? It needs to be explicit that it's an org wide config

Edit: just want to also bring up a quick back and forth I had in #4025 where it was shared that these would eventually become agent settings? Is that the current plan for the trusted settings?

@qwerty287
Copy link
Contributor

This should be added as an agent option after #4675 was merged. So I think this PR should get done first and then we can extend the feature

@xoxys
Copy link
Member

xoxys commented Feb 24, 2025

Sorry I don't have much context, but why do we want to migrate these settings to agent settings? And I can then not control it per repo anymore? An agent would have e.g. Security permissions regardless of the repo?

@igniscyan
Copy link
Author

Sorry I don't have much context, but why do we want to migrate these settings to agent settings? And I can then not control it per repo anymore? An agent would have e.g. Security permissions regardless of the repo?

I'm not sure - I asked the question in the separate thread trying to get some elaboration myself.

I think either paradigm can work - the settings can be applied to an agent and orgs can take a default agent, or orgs can set default repo configs. I'd like some clarity myself before I work one way or the other.

@qwerty287
Copy link
Contributor

qwerty287 commented Feb 24, 2025

Sorry I don't have much context, but why do we want to migrate these settings to agent settings?

For the discussion, see #3758

This came up when we introduced user-registered agents. Then you might have a user agent and would like to give your (trusted) repo additional privileges, but you cannot long as you are not the server admin.
The point is that this is kind of a "responsibility" difference between server and agent, because the agent executes the pipelines, but with a trusted configuration which is managed by the server. The agent host is the one that could be taken over by a malicious repo, not the server.

And I can then not control it per repo anymore? An agent would have e.g. Security permissions regardless of the repo?

No, in your agent configuration you define which repos have trusted access. The pipelines from this repo executed by the agent then get privileged access, but the other ones don't.

I'd like some clarity myself before I work one way or the other.

Before you start, please wait for the linked PR.

@xoxys
Copy link
Member

xoxys commented Feb 24, 2025

I see, thanks.

No, in your agent configuration you define which repos have trusted access.

What about companies where the IT team hosts a shared setup? Repo owners won't have access to the agent config and letting the IT team add every repo to agents config might not scale. I understand the general idea, but this could lead to other issues IMO.

@qwerty287
Copy link
Contributor

In this scenario, would you give server admin access to any repo owner that needs trusted access? Otherwise they would not be able to enable trusted access for a specific repo.

@xoxys
Copy link
Member

xoxys commented Feb 24, 2025

Thats exactly my point. Repo owner can enabled it in the UI on their own while they cant anymore on the agents.

@qwerty287
Copy link
Contributor

Yes, but repo owners can only do so if they have server admin rights (not repo admin rights, but admin for the full wp server). If I have a separate IT team I wouldn't give server admin access to all of the repo owners.

@xoxys
Copy link
Member

xoxys commented Feb 25, 2025

Oh ok in that case it doesnt matter where this configuration is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement improve existing features
Projects
None yet
Development

No branches or pull requests

3 participants