4 ms·

I'm struggling to understand why this is useful. How is this useful from doing a docker exec, or kubectl exec?

by lapser 4y ago

janosdebugs 4y ago
It was born from a need in the webhosting sector. I wanted to give users shell access so they can do things like git pull directly to their website. Without containers it's difficult to constrain a user. The first SSH server I build along these lines involved the components what make containers today: chroots, cgroups, etc. (That was more than 10 years ago.) Over time, more use cases have developed, most of them around the need for jump host or lab access. There has also been some research done into SSH attack patterns using this as a honeypot, which will hopefully be published soon. See: https://containerssh.io/usecases/lab/ https://containerssh.io/usecases/lab/
- alerighi 4y ago
  It is difficult? It is something most web hosting did way before container existed. You just create the user on the system (well, probably have the user in LDAP) and give the user the permission to access only its files and possibly execute only a number of trusted programs (or not execute programs at all, and dive only SFTP/SCP/git access and not a shell). Containers may give some false sense of security tough, a lot of people doesn't understand really that escaping a container is not such a difficult thing, since it pretty new stuff and bugs are being discovered, also the container may be configured badly, while the UNIX permission mechanism is around since forever and it's pretty solid (not that in the past there weren't bug that bypassed it, but the same bugs may as well be used in a container anyway).
  - janosdebugs 4y ago
    Most webhosting services barely managed to offer encrypted FTP/SFTP before containers existed, most went with plain text FTP. When I worked in the sector back 2011 we had a customer with a hacked/stolen FTP password every other week. As far as features are concerned, yes, you can make a git server you can push to, but allowing users to get a full shell and pull from their git server is a whole other comfort level. More modern alternatives would include on-server development with VS Code, which we aim to support in the next version with port forwarding supported. As far as container security is concerned, if properly configured, these are still a sight more secure than trying to give users shell access without them. The UNIX permission mechanism is woefully inadequate for keeping users from messing with each other's stuff. This is obviously not a problem if you don't want to provide a shell service to users, but some services, like the LX Plus service at CERN mentioned in the other thread [1] is specifically that: a shell service for users to access. One of the problems containers (or more accurately, network namespaces) solve are the language or development servers users may start for their development needs. These often don't contain any extra security beyond binding to 127.0.0.1. However, on a shared server this is obviously not enough. The other problem with using purely UNIX permissions to isolate users in the webhosting sector is users messing up their permissions. Back in the day this was also a constant problem, so nowadays all webhosters run the webserver / PHP-FPM instance with the same user ID as the user uses to upload their code, often having multiple websites for the same user using the same user ID. This lends itself to cross-contamination between sites if one is breached. If the sites run on a different user ID, however, it becomes more difficult for a user to move data between them. [1] https://news.ycombinator.com/item?id=32790856 https://news.ycombinator.com/item?id=32790856
  - rkeene2 4y ago
    Indeed, I let anonymous people run arbitrary code on my system... though I haven't bothered to make it available over SSH. https://rkeene.dev/js-repl/?arg=bash https://rkeene.dev/js-repl/?arg=bash It creates a secure environment on every connection, though it doesn't use cgroups, just chroot, resource limits, and other boundary protection mechanisms, etc.
Too 4y ago
In one sentence: Everybody already knows how to use SSH, only the infra department knows how to use kubectl. Don’t underestimate how much pushback and struggle even such a small tool addition can add to developers with already too many other things on their mind. This enables the whole dev org to use ephemeral workflow from k8s, without having to understanding k8s. SSH also comes with a lot of tooling integration that is not as readily available as for k8s. Tunneling through anything, IDE integration or sshfs to name a few. Granularly locking down a k8s cluster can also be a challenge. It’s easier to just block your k8s api server from anyone who is not admin. Otherwise in principle you are right, kubectl should on paper be equally or even more capable.

I'm struggling to understand why this is useful. How is this useful from doing a docker exec, or kubectl exec?

by lapser 4y ago

I'm struggling to understand why this is useful. How is this useful from doing a docker exec, or kubectl exec?

It was born from a need in the webhosting sector. I wanted to give users shell access so they can do things like git pull directly to their website. Without containers it's difficult to constrain a user. The first SSH server I build along these lines involved the components what make containers today: chroots, cgroups, etc. (That was more than 10 years ago.) Over time, more use cases have developed, most of them around the need for jump host or lab access. There has also been some research done into SSH attack patterns using this as a honeypot, which will hopefully be published soon. See: https://containerssh.io/usecases/lab/ https://containerssh.io/usecases/lab/

alerighi 4y ago
It is difficult? It is something most web hosting did way before container existed. You just create the user on the system (well, probably have the user in LDAP) and give the user the permission to access only its files and possibly execute only a number of trusted programs (or not execute programs at all, and dive only SFTP/SCP/git access and not a shell). Containers may give some false sense of security tough, a lot of people doesn't understand really that escaping a container is not such a difficult thing, since it pretty new stuff and bugs are being discovered, also the container may be configured badly, while the UNIX permission mechanism is around since forever and it's pretty solid (not that in the past there weren't bug that bypassed it, but the same bugs may as well be used in a container anyway).
- janosdebugs 4y ago
  Most webhosting services barely managed to offer encrypted FTP/SFTP before containers existed, most went with plain text FTP. When I worked in the sector back 2011 we had a customer with a hacked/stolen FTP password every other week. As far as features are concerned, yes, you can make a git server you can push to, but allowing users to get a full shell and pull from their git server is a whole other comfort level. More modern alternatives would include on-server development with VS Code, which we aim to support in the next version with port forwarding supported. As far as container security is concerned, if properly configured, these are still a sight more secure than trying to give users shell access without them. The UNIX permission mechanism is woefully inadequate for keeping users from messing with each other's stuff. This is obviously not a problem if you don't want to provide a shell service to users, but some services, like the LX Plus service at CERN mentioned in the other thread [1] is specifically that: a shell service for users to access. One of the problems containers (or more accurately, network namespaces) solve are the language or development servers users may start for their development needs. These often don't contain any extra security beyond binding to 127.0.0.1. However, on a shared server this is obviously not enough. The other problem with using purely UNIX permissions to isolate users in the webhosting sector is users messing up their permissions. Back in the day this was also a constant problem, so nowadays all webhosters run the webserver / PHP-FPM instance with the same user ID as the user uses to upload their code, often having multiple websites for the same user using the same user ID. This lends itself to cross-contamination between sites if one is breached. If the sites run on a different user ID, however, it becomes more difficult for a user to move data between them. [1] https://news.ycombinator.com/item?id=32790856 https://news.ycombinator.com/item?id=32790856
- rkeene2 4y ago
  Indeed, I let anonymous people run arbitrary code on my system... though I haven't bothered to make it available over SSH. https://rkeene.dev/js-repl/?arg=bash https://rkeene.dev/js-repl/?arg=bash It creates a secure environment on every connection, though it doesn't use cgroups, just chroot, resource limits, and other boundary protection mechanisms, etc.

Too 4y ago

In one sentence: Everybody already knows how to use SSH, only the infra department knows how to use kubectl. Don’t underestimate how much pushback and struggle even such a small tool addition can add to developers with already too many other things on their mind. This enables the whole dev org to use ephemeral workflow from k8s, without having to understanding k8s. SSH also comes with a lot of tooling integration that is not as readily available as for k8s. Tunneling through anything, IDE integration or sshfs to name a few. Granularly locking down a k8s cluster can also be a challenge. It’s easier to just block your k8s api server from anyone who is not admin. Otherwise in principle you are right, kubectl should on paper be equally or even more capable.