Support for startup settings

[diegosucaria]

Hello! thank you for writing this nice piece of code! it is awesomeee!!!

I know that perhaps it is not supported, but can you point me on what to do to start kubebox with a pod terminal opened?

I'm trying to have a url that you can open in the browser and get a terminal to a certain container without having to select/click/press anything.
If I can disable moving away from that pod, it would be great.

[astefanutti]

Thanks a lot for the kind feedback.

Your understanding is correct, it is not currently supported.

If I understand correctly, you're using the Web version. We could rely on a fragment that would identify the view to be open and its parameters.

I really like the idea. Thanks for the suggestion!

[diegosucaria]

Thanks for considering my idea!

The main goal of this is that I could give another person a shell inside a container, without giving access to the rest of the containers running on the same cluster.

I'm doing some tests myself...
Since it is the first time I read this code and I am not used to working with the elements that this project uses, I found it too difficult to do what I wanted to achieve first....

Instead, I am capping the kubebox pod listing function to the values set by these two variables:
RESTRICT_NAMESPACE="somenamespace"
RESTRICT_CONTAINER_NAME="somecontainernameregex"

That kind of works well, but now I am trying to remove the graphics and display the shell there instead.... still working on it.

Thank you again!

[astefanutti]

Ah, it seems it's more about sharing a shell into a container with someone else then.

One idea, would be to use Kubebox as a side-car of the container to share, and rely on the Kubernetes Downward API to inject the namespace and pod information as environment variables automatically: https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api. That would be a very cool way to use Kubebox!

Do not hesitate if you need any help on the code. You can even create a draft PR if you think that helps.

[diegosucaria]

Yes, that is exactly what I am trying to do...

It could be two things:
1- single shell startup (it could be sidecar or not): just open the shell in the main screen. do not allow exiting or moving away.
2- limited shell use: open kubebox, display the shell instead of graphs, and restrict pod listing to certain namespace and certain pod name or regex.

I managed to start a shell at startup, but it displays over the main screen and exiting the shell returns you to the main screen.

I'm doing some progress with 2-, but I am not being able to focus on the shell:

I can do a PR if you want but I've been working "destructively" let's say...

[astefanutti]

I need to think a bit more about it, but it seems option 2 could be achieve with Kubernetes RBAC, that is restricting the permissions granted to the service account that's used to run the Kubebox pod. Plus a navigation system, that would rely on the URL fragment for example to jump directly to a particular container shell.

Otherwise, 1 seems interesting to explore, as it could be used as an ephemeral container, that possibly could expose a Web shell, even without talking to the Master API...

[diegosucaria]

Yes, I couldn't agree more!

I'll keep working on my tests and I'll share a PR if I reach something useful :)

Thank you!