docs: add blog post about permissions on pac#713
Conversation
tekton-robot
added
the
size/L
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
the
approved
Added a new blog post explaining the authorization model, covering default checks, the `/ok-to-test` mechanism, and policy-based access control to help users secure their pipeline execution. Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
chmouel
force-pushed
the
pac-permissions-and-policy-blog-post
branch
from
c035dd2 to
f633cd1
Compare
| `/ok-to-test` on a pull request to approve it for CI. Once approved, PAC | ||
| triggers the pipeline for that PR. | ||
|
|
||
| Related commands: |
There was a problem hiding this comment.
These can only be commented by the people who are allowed by the above rules as well?
| > turn hostile after gaining initial trust, or combine it with | ||
| > `require-ok-to-test-sha` to at least pin approvals to specific commits. |
There was a problem hiding this comment.
If you have remember-ok-to-test enabled, will it trigger (i.e. auto-approve in the future) if you only approve a specific commit to run?
| > automatically -- without further review. A contributor whose initial commits | ||
| > looked harmless could later push malicious code that executes in your CI | ||
| > environment without anyone explicitly approving it. Keep this setting |
There was a problem hiding this comment.
Do we have any further information about what this might be that we can refer to? For example running arbitrary workloads on the infra environment where Tekton is running including exfiltrating any available secrets?
| > turn hostile after gaining initial trust, or combine it with | ||
| > `require-ok-to-test-sha` to at least pin approvals to specific commits. | ||
|
|
||
| ### Preventing Race Conditions with SHA Verification |
There was a problem hiding this comment.
I would move this higher up above the remember ok-to-test.
| There is a subtle attack vector: a malicious contributor could push a bad | ||
| commit right after an `/ok-to-test` comment is posted but before the CI picks |
There was a problem hiding this comment.
Do you want to say that the comments are not tied to commits in the webhook events (resulting in PAC needing to find the HEAD commit) that are sent or is that too much detail?
| `/ok-to-test` comment to include the specific commit SHA being approved: | ||
|
|
||
| ``` | ||
| /ok-to-test abc123def |
There was a problem hiding this comment.
This allows a short sha or a long sha? If so, should we highlight that a long sha is a stronger protection or that is well known?
If using a short SHA, it would be easier to prepare a malicious commit (with an appropriate sha collision), force-pushing it to trigger the same timing attack. I don't know how likely this would be to target though.
|
|
||
| ## The OWNERS File | ||
|
|
||
| PAC supports a Prow-compatible `OWNERS` file as a fallback authorization |
There was a problem hiding this comment.
Do you have a link to this if people are not familiar?
4 participants
Added a new blog post explaining the authorization model, covering default checks, the
/ok-to-testmechanism, and policy-based access control to help users secure their pipeline execution.Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide
for more details.