-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Adds the design proposal for self-hosting authz webhook #1458
Conversation
/ok-to-test |
An example configuration file for authz looks like this: | ||
|
||
```yaml | ||
apiVersion: authorizationconfig.k8s.io/v1alpha1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know we've had concerns in the past about API groups with only one type. In the future, should this group hold other webhook configs? e.g. audit or authentication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you recommend to do here instead?
Not sure I can decide either way, not knowing the history of such concerns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was referencing kubernetes/kubernetes#55812 (comment)
Maybe this could be included in the existing apiserver.config.k8s.io
group?
kubernetes/kubernetes@229c430#diff-77d495a77d16f1f8c941606e2e5dee42R30
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding from previous comments is that this addition would be a kube-apiserver feature only, and as such not suitable for generic apiservers.
See for example discussion around this comment: kubernetes/kubernetes#52511 (comment)
Would your proposal not mean that we're mixing in these specific concerns into all other apiservers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't realized deads2k had already commented on this. It's fine as is then. Thanks for the feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing! It's on me as a proposer to dig up prior art.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per https://github.com/kubernetes/community/blob/master/contributors/devel/component-config-conventions.md, component config apigroups should have the prefix: .config.k8s.io
. I also don't see why this specific config format will not be useful for other webhooks (e.g. authenticator).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed the prefix to conform to that convention if it helps. I'm not generalizing since this is not the intention, and previous feedback has been that this should remain a kubeapiserver feature only.
externalAuthorizationHooks: | ||
- name: webhook-name | ||
clientConfig: | ||
serverCaFile: ... # the path to the CA file for the webhook server |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we should probably be more consistent about what we name these fields. What other config uses serverCaFile
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern here was that a field named serverCa
, or server-certificate
isn't quite clearly saying whether what follows is a file path name, or the actual quoted content of the field.
serverCaFile
is very clear about what the contents are expected to be. Is this something that's not desirable? Should the name err towards consistency regardless? Do we support/endorse the use of yaml-style inline quoting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I mean we have a history of not being constant in our naming of TLS options kubernetes/kubernetes#54665
Admission webhooks use caBundle
for example: https://kubernetes.io/docs/admin/extensible-admission-controllers/#configure-webhook-admission-controller-on-the-fly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, duly noted. Do you have a specific recommendation, just so I don't need to go invent an approach if you can already see one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Digging around the APIs there's not much precedence. I agree this is more explicit than caBundle
. Let's just leave it as is. Sorry for the noise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM. I updated the comments to be way more specific as to the meaning of the fields.
Versus: this work is out of scope. | ||
|
||
Our proposed solution makes no change to the current state of the webhook | ||
libraries. Unifying code paths for webhooks is a worthwhile goal, but out of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to be adding features to the authorization webhook, it seems odd to declare "how other webhooks will us this feature it's out of scope." I'd like to see it at least considered, even if it's not implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other webhooks won't use this feature per this proposal. The proposal (at least IMHO) doesn't prevent reuse.
I can expand a bit on that viewpoint in the text, but anything I'd say would be along the lines of "this is not a concern in the context of this proposal".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, forgot to mention: Thanks a million for jumping to review this pull request so quickly!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I seflishly would like to see this usable by the authentication webhook too. Looking at kubernetes/kubernetes#54733 it doesn't seem like that would be too difficult, the language here just worries me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please take another look. I tried to clarify.
b57bbf3
to
4695751
Compare
/assign @deads2k |
4695751
to
2b96799
Compare
A bit stale but potentially related: kubernetes/kubernetes#30395 |
`kube-apiserver` can make use of it. This approach has [garnered support][8] | ||
from the community in the earlier proposal. | ||
|
||
## Proposal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a section on security implications of running an authorizer on the cluster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a section on security.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. LGTM
// Top-level | ||
type ExternalAuthorizationHookConfiguration struct { | ||
meta.TypeMeta | ||
meta.ObjectMeta |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Config objects should not need ObjectMeta.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
def1887
to
cc4d736
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: filmil Assign the PR to them by writing The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
This proposal implements feature request: kubernetes/enhancements#516 Code review comments handled: - Fixed the resource naming. - Removed ObjectMeta from the configuration file description. - Added a Security section explaining some of the security recommendations.
cc4d736
to
56c6cbc
Compare
/assign @deads2k |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This proposal implements feature request:
kubernetes/enhancements#516
Please refer to the feature request for administrative details. Reviews appreciated.