-
Notifications
You must be signed in to change notification settings - Fork 14.6k
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
Document proxy flows #12305
Document proxy flows #12305
Conversation
|
||
Note that it is the responsibility of the extension server implementation to provide the above. Many do it by default, leveraging the `k8s.io/apiserver/` package. Others may provide options to override it using command-line options. | ||
|
||
### Extension Server Authorize the Request |
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.
@liggitt - this is the part I don't get. Didn't it already authorize the request at the first step?
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.
from the extension API server's perspective, all that has been proven is the identity of the incoming request (authentication, not authorization). The auth proxy might be the aggregator which already ran an authorization check, but it could just as easily be a generic authenticating proxy that only checked identity and added user info into headers.
Deploy preview for kubernetes-io-master-staging ready! Built with commit 9cc9b4c https://deploy-preview-12305--kubernetes-io-master-staging.netlify.com |
hi @liggitt would you be willing to serve as the technical reviewer of this content? Simply add a /lgtm when you are satisfied with its technical accuracy. Thanks!!! |
c092266
to
90f79a0
Compare
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
|
||
## Authentication Flow | ||
|
||
Unlike Custom Resource Definitions (CRDs), the Aggregation API involves another server - your Extension API Server - in addition to the standard Kubernetes apiserver. The Kubernetes apiserver will need to communicate with your extension server, and your extension server will need to communicate with the Kubernetes apiserver. In order for this communication to be secured, the apiserver uses x509 certificates to authenticate itself to the extension 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: suggest API server
over API Server
and apiserver
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 suggest explicitly saying "Kubernetes API server" and "Extension API server" everywhere instead of "apiserver" for clarity
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.
Yeah, that makes sense. Elsewhere in the docs I have seen "apiserver" so stuck with it. I don't care much one way or the other though, so will follow your suggestion.
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.
Actually, the original document uses "apiserver" everywhere (7 times). You sure you want me to change all of those as well?
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.
But adding explicit "Kubernetes apiserver" vs "extension apiserver" (or "API server") is a definite.
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.
Updated to use "Kubernetes apiserver" and "extension apiserver" everywhere. If you feel we should change all cases of "apiserver" to "API server" (including the pre-existing ones), no problem, quick search-and-replace.
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
|
||
Note that it is the responsibility of the extension server implementation to provide the above. Many do it by default, leveraging the `k8s.io/apiserver/` package. Others may provide options to override it using command-line options. | ||
|
||
### Extension Server Authorize the Request |
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.
from the extension API server's perspective, all that has been proven is the identity of the incoming request (authentication, not authorization). The auth proxy might be the aggregator which already ran an authorization check, but it could just as easily be a generic authenticating proxy that only checked identity and added user info into headers.
90f79a0
to
16dfc9b
Compare
c5fd8d2
to
14fd384
Compare
@liggitt I addressed everything in your comments. Just need a decision on "Kubernetes apiserver" and "extension apiserver" vs "Kubernetes API server" and "extension API server". I think I like "apiserver" just because it is consistent with what was there before, but your call. |
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
Outdated
Show resolved
Hide resolved
one note about the role that allows submitting subjectaccessreviews, technical content lgtm otherwise, thanks! |
14fd384
to
9cc9b4c
Compare
Done! |
/lgtm |
@bradtopol could you please take a look at this PR and state your suggestions/approval. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: zparnold The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@@ -22,13 +22,173 @@ Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extensi | |||
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. | |||
{{< /note >}} | |||
|
|||
{{% /capture %}} | |||
|
|||
{{% capture authflow %}} |
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 tag isn't recognized by Hugo, the static site generator we use to build the docs. So the build ignores everything inside this capture tag. (Note that the change to the heading below does show up on the live site.) The tags are part of the template for the different topic types that we require; they can't be used with arbitrary strings to designate a section type.
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.
one comment @Bradamant3 is that i run a quick test on my local dev env and i can confirm that by removing {{% capture authflow %}}
and {{% /capture %}}
does solve it however the text does show after the Enable Kubernetes Apiserver flags
although in the file the new text added by @deitch is before
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.
Good catch, @DanyC97, and thanks very much for testing -- my suggestion to remove the offending capture tags was incomplete. The added content needs to be placed inside the steps
capture tag. See https://kubernetes.io/docs/contribute/style/page-templates/#task-template.
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.
@deitch should you not have time/ spare cycle to fix this one, let me know and i'll take over
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 @DanyC97 . I must have copied it over from somewhere when doing the previous PR and it lingered. I will clean it up and update.
should you not have time/ spare cycle to fix this one, let me know and i'll take over
Never have, but I will do it anyways. :-)
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 fixed the tags on the open PR that I have at #12890 since it was open anyways. Take a look there?
@deitch not sure how you'd like to proceed with this one -- I can revert the merge, but if you've deleted your local branch, you can submit a new PR instead. I suggest just removing the problem capture tags for the new content you've written. |
Document flows of proxy requests for aggregated API.
As discussed with @liggitt .