Web Terminal #182
Web Terminal #182
Conversation
Signed-off-by: Mario Loriedo <[email protected]>
openshift-ci-robot
added
the
size/L
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: l0rd The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/assign @shawn-hurley |
|
cc @spadgett |
|
/assign @spadgett @benjaminapetersen |
Co-Authored-By: Sergii Leshchenko <[email protected]>
Co-Authored-By: Sergii Leshchenko <[email protected]>
|
|
||
|  | ||
|
|
||
| The endpoint is secured through an [OpenShift OAuth Proxy](https://github.com/openshift/oauth-proxy) sidecar. The client includes the user OpenShift token in its requests HTTP header. Only authenticated OpenShift users that satisfy the RBAC policy requirements are able to send requests to the Terminal server. |
There was a problem hiding this comment.
if you have the ability to indicate that only userX can exec or attach into PodA, why do you need to separately authenticate them. Can't you just use a normal exec call?
There was a problem hiding this comment.
Currently, the web terminal we use has two API methods:
- connect - initialize exec to k8s API
- attach - connect to initialized exec.
This design was made from the beginning on Che and it allows (but not sure if it's implemented, maybe for Theia) to restore the terminal state after user refreshes a page.
But as an alternative - we could leave the only one method which would do both operations, it would allow avoiding the need to protect our endpoints with authentication.
But then the client should be somehow able to get k8s client.
In case, of OpenShift OAuth Proxy - it does it for CloudShell: use OpenShiftOAuth to get scoped token, store it in the cookies, and it let CloudShell client just send a request and authorization header will be provided by browser.
So, I hope it makes the current implementation a bit cleaner but we're able to discuss and find other possible implementations.
|
|
||
| #### Users Token Injection in Tooling Containers | ||
|
|
||
| That's something that we still need to figure out (see "Open Questions" section) but the injection of the user token cannot be achieved through a secret because cluster editors would be able to access it. Options are 1) xtermjs that automatically execute a command at startup 2) the `DevWorkspaces` controller that copies the token in the tooling container after it has been started. |
There was a problem hiding this comment.
if you control the image at the other end, when you exec in, the first thing you could do is copy the user token into the pod and create a kubeconfig file and KUBECONFIG env var
There was a problem hiding this comment.
the first thing you could do is copy the user token into the pod and create a kubeconfig file and KUBECONFIG env var
Yeah, we should be able to implement something like that.
The question is not addressed yet - where to get user's personal token.
Currently, OpenShift OAuth proxy uses SA and is not able to request user's personal token, but only some of the existing roles
https://docs.openshift.com/container-platform/3.5/architecture/additional_concepts/authentication.html#service-accounts-as-oauth-clients
So, we need to take a look if we are able to register a dedicated OAuth client for CloudShell, OpenShift OAuth proxy could use it - our server side is able to get user's personal token and initialize kubeconfig. Will play with it shortly.
There was a problem hiding this comment.
Well, there seem to be an issue with OAuth Client for CloudShell, I've described it here eclipse-che/che#16515
@deads2k Maybe you have a recommendation on how we could get user's personal token in a safe manner?
During the call, @davidfestal shared that he wondered if it's possible to have some proxy on OpenShift Console side and the URL is available for WorkspaceController...
Then CloudShell would be requested from OpenShift Console domain and we'd be able to reuse the same token OpenShift Console does.
|
|
||
| #### Cloud Shell Pod Exec Denial Policy | ||
|
|
||
| Users tokens are injected in the Tooling container. That's required for `oc` or `odo` to work properly. As a consequence access to the Tooling container should be allowed **only to the user of the Cloud Shell instace**. That's something that the authorization mechanism based on RBAC seen above is not able to garantee: users with editor privileges at cluster scope will be able to exec into the Pod. |
There was a problem hiding this comment.
line breaks every 120 char or every sentence to make comments eeasier
|
|
||
| #### Cloud Shell Pod Exec Denial Policy | ||
|
|
||
| Users tokens are injected in the Tooling container. That's required for `oc` or `odo` to work properly. As a consequence access to the Tooling container should be allowed **only to the user of the Cloud Shell instace**. That's something that the authorization mechanism based on RBAC seen above is not able to garantee: users with editor privileges at cluster scope will be able to exec into the Pod. |
There was a problem hiding this comment.
Can you describe the API interaction you will use to guarantee this? Will it take advantage of certain aspects of pod immutability? It cannot be an annotation.
There was a problem hiding this comment.
There is
- A Mutating Admission Webhook that adds an annotation with the creator UID to the DevWorkspace CR at creation time;
Then WorkspaceController creates Deployment with that creator annotation in metadata.annotations + spec.template.metadata.annotations. As a result, deployment creates pods with creator annotation propagated.
-
A Mutating Admission Webhook that validates that the creator annotation is not modified in workspace-related deployments and pods. If the value is omit - it's restored from the previous object state, if it's modified - error is thrown.
-
A Validating Admission Webhook that validates exec to make sure that the user who request connect to the workspace-related pod is the same as pod creator annotation.
Hope it answers: Can you describe the API interaction you will use to guarantee this?
If not - let me know.
Will it take advantage of certain aspects of pod immutability?
Do you mean that it would be better to propagate creator info like through Env vars, or command/args, or other fields which is immutable?
We haven't thought about it before. Will take into account.
|
|
||
| - A Mutating Admission Webhook that adds a user attribute to the DevWorkspace CR at creation time | ||
| - A Validating Admission Webhook that block changes to the user attribute of a DevWorkspace CR | ||
| - A Validating Admission Webhook that block changes to the Cloud Shell Pod annotation that stores the reference to the DevWorkspace CR. |
There was a problem hiding this comment.
Could we simplify down to a least common denominator of a user reference? A webhook on pods could actually protect an annotation (making it set-once) indicating user and then prevent other execs. It wouldn't preclude you embedding it in another resource type, but it makes your footprint on kube smaller.
There was a problem hiding this comment.
Do you mean something like:
- the only Workspace CR has creator annotation;
- deny modifing OwnerReference for deployment and pods;
- no need to validate deployment or pods with webhooks;
- ValidatingWebhook which check if it's try to connect to a workspace-related pod, if yes - finds to which workspace CR instance this pod belongs to, use creator from there.
If yes - we considered this option but it would make validating webhook check slower, and since we're not able to filter CreateExecOptions with object/label selectors - it would mean that every exec would be slower.
Please elaborate more if you meant something else.
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
It has been implemented as web-terminal operator. A blog post has been published on the OpenShift blog. Closing this PR. |
8 participants
This is a first draft of the Cloud Shell proposal. cc @deads2k @davidfestal