Concourse
Move away from generic API catch-all policy checks to specific actions #6013
andy-paine
started this conversation in
Ideas
Replies: 1 comment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The policy checking (OPA) integration currently can generically send all API calls to the ATC to the policy checker (controlled by env vars/flags when starting web) and where the API request body is JSON or YAML, include it in the request. This means that Concourse does not need to know about all the possible permutations of controls operators may want to apply as it "dumbly" passes down any info it knows about the request but this also means that the policy checking system is now tightly coupled to the API of the ATC. In addition, some endpoints use
application/x-www-url-form-encodedcontent types so these request bodies are not serialised and sent to the policy checker.Relevant conversations:
Comment discussing issue arising from
SaveConfigaction being caused by system rather than just API - Enforce SetPipeline policy check inset_pipelinestep #5932 (comment)Issue with form data not being passed down/not coherent API for policy checks - https://github.com/concourse/rfcs/discussions/71
Discussion from Discord
vito
since we're talking about OPA, i could use a bit more input on this question: Enforce SetPipeline policy check in
set_pipelinestep #5932 (comment) tl;dr i'm thinking we should remove these catch-all API policy checks and add them for specific actions insteadandy.paine
Having them as catch-all means that the whole policy checking system has a much lower overhead for the Concourse maintainers I think but has issues with now API changes which would normally only have been breaking to web & fly (being the major 2 clients of the API) are now going to passed down to the policy checker. Overhead for the maintainers may not be a concern if policy checking becomes a core part of Concourse's offering as a system in which case tighter management of what is checked and the format of those checks may well be preferable.
It would probably require maintenance of a document like this that obeyed similar API semantic versioning for breaking changes etc. https://github.com/open-policy-agent/opa-envoy-plugin#example-policy
The benefit of having a catch-all is that Concourse doesn't need to know about every possible use case - I could do something really weird like "Bob is only allowed to view pipelines with 4 or more jobs if one of them is called unit-tests" without Concourse ever having to think about the horrors that have lead to that rule being needed
I'm half tempted to have a go at implementing the entire Concourse RBAC system using Rego and OPA as a library which would show us what information Concourse checks and maybe shed some light as to where there are missing bits
It's possible that some of the fine-grained controls that someone might want to apply may actually be better served by projects going forward
I guess one of the major questions is: have people ever expressed an issue with the current API endpoint access system or are the things people want to control with OPA just Concourse "actions" like "setting a pipeline" - I would suggest the latter is more likely true so we really just need to capture what actions should be in scope
It would be useful to know what actions people are interested in controlling with a policy checker
Available actions
All actions (I think)
My suggestions for relevant actions
cc: @vito @evanchaoli @sshuvaev
Beta Was this translation helpful? Give feedback.
All reactions