Block SSH from a Docker container

I’d like to offer the ability for end-users to turn off the remote shell feature of BalenaCloud. For example, by default, the remote shell feature would be off. If a user has trouble with their device, they could open a settings pane and enable a “remote support” feature which would then open the remote shell.

I looked through the Balena-supervisor API, and this looks like a great place to implement it, but it didn’t seem like I could do this through the API.

Any suggestions on how I might accomplish this?

Additional details:

  • I’m running an Electron GUI app in a docker container, so the API-based solution is preferable as it’s pretty easy to make API calls in a web app.

Thanks for any help you can offer!

Hi there,

Can you describe a bit more about the use case of what you are trying to build? If you are running a custom application that your users interact with, can’t you just hide/not show the terminal and then display it when they toggle the setting?

Please let us know what you’re aiming for so we can help guide you!

Hey! Thanks for the reply!

So I’m running a GUI application in a docker container on Balena; this shows up on a display on my device and provides a UI to the user.

It’s my understanding that with BalenaCloud, I can open up a Shell into any device and any container/service running on a device.

Some of my clients have security concerns with this, so what I would like is to be able to turn on/off this BalenaCloud Shell feature for a particular device via an option in the container that’s running my UI.

So for example, my UI would have some sort of toggle switch in it; when a user toggles it off, the UI could send some sort of API call to the Host OS to disable the remote shell feature. When the user toggles the switch on, it would re-enable this feature.

Is that clear/is there anything I can do to be more descriptive? I appreciate your time and help!

Hello,

at the moment we don’t support disabling SSH access to the device or to application containers. This has implications for features like HUP and device diagnostics. The container shell would be a separate consideration as this is really just a docker exec.
Maybe we can help with solving the issue at the core of this? What specifically is the concern about terminal access? Is it sensitive data or proprietary code?