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
defaultAllowPrivilegeEscalation Support #55
Comments
Mutating webhooks are likely a ways away as the ability to write them in Rego is harder than initially thought due to the need for recursion (allowing infinite recursion would make Rego turing complete). In the short term, it is possible to create a validation webhook that rejects the resource if it is missing the required field. This is not as convenient for users in the short term, but does have the advantage that their configuration files more closely match the actual internal state of the system. |
For fun, I wrote a minimal mutating webhook for this use case. The webhook closely mimics the functionality found in the PSP admissions controller. This solution isn't perfect for a number of reasons, but it has been helpful. |
Nice! One coder quality-of-life thing I'm noticing is that I think the admission framework will calculate the mutation patches for you if you return a modified object, though I may be misremembering. Which is better might be a matter of taste, but personally I like the idea of not having to worry about accidentally coding incompatible JSON patches and just modifying the inbound object directly. It's good for us to keep an eye on what people may want to use mutation for, as that will definitely impact its design. |
A framework as in a golang library? |
Yep, the controller-runtime library: |
Thanks! One last question for you since the Any advice for writing a golang k8s webhooks that support both |
To be honest, I'm not sure off the top of my head. My understanding is that you can specify which version of the review object you want via the The version of the review object is embedded in the object itself, so you could inspect the request and deserialize to the appropriate object, but I haven't dug into the differences between the two resources to see if there are any fields that need to be handled differently depending on version. |
It looks like library/experimental/mutation/pod-security-policy/allow-privilege-escalation implements this. However, mutations are still experimental and this mutation is too. |
…agent#55) Signed-off-by: Paul Bouwer <paul.bouwer@gmail.com>
This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
Describe the solution you'd like
I believe this would require a mutating webhook, but I'd like to be able to toggle a flag (on a Constraint?) similar to the
defaultAllowPrivilegeEscalation
field in thePodSecurityPolicy
resource.After reading the No New Privileges Design Doc I think I'm beginning to understand why the existing Gatekeeper PSP library policy
allow-privilege-escalation
needs to check every initContainer and container. By default, ifallowPrivilegeEscalation
isn't explicitly set tofalse
, then the nonroot containers can escalate.The text was updated successfully, but these errors were encountered: