Remote terminal to IRIS container

Question

Question

Brendan Oakley · Oct 3, 2019

#Containerization #Docker #Security #Terminal #Access control #InterSystems IRIS

When deploying IRIS in a container, what are recommendations for permitting users terminal access? There is docker exec -it, but that does not work from a user's workstation where - in the old deployment model - they would connect to the server over ssh using Putty and open a terminal session from there.

Discussion (9)2

Log in or sign up to continue

Conor Walsh · Oct 4, 2019

Hi Brendan,

For write-style operations, my recommendation is: Do not allow this in production. Part of the gain from containerization is that you make production as automation-friendly as possible, and that it's manipulated by humans in potentially-unpredictable ways as rarely as possible.

For read-style operations - i.e., logging in and running "do ^GetReports" - I don't expect this to be a common use case. Containers usually operate on service models that involve a minimum of command-line interactivity, and as few ways as possible to access the application running inside. Most of those methods are usually network-based rather than terminal-based. You're absolutely correct that giving folks membership in the "docker" group on a host is equivalent to giving them host-root, which means it may be unsuitable for your use case here.

Installing sshd inside the image is an option, but will come with some complexity. You'll need to start sshd in your iris-main --before, and preferably also stop it gracefully on the other side. You'll also have to clear the hurdle where the /etc/passwd and /etc/group entries inside the container are relatively unrelated to the entries outside of it, though if you have the container connect to the same NIS server as the host does, that problem should become fairly moot.

Side note on users/groups in the container vs. on host: Integer UIDs and GIDs are the same, which can be important when writing files to your Durable %SYS area or other host bind mounts, but the number->name mappings are totally independent; they're essentially two different interpretations of the same "primary key". This can be a plus, and can allow you to have a custom approach to users/groups inside a container; when combined with named Docker volumes (instead of bind mounts), you can create a whole distinct user/group ecosystem, if you like.

I don't have a lot of experience with Web Terminal, but it would be my go-to option for letting users log in remotely via their IRIS credentials while bypassing the need for any management of Linux credentials inside the container.

If I'm wrong and this turns out to be a commonly-desired use case, we can look into other solutions or new features here.

Cheers,
Conor

1 0

score 0 · Answer 1 · 2019-10-03T15:04:18-04:00

Eduard Lebedyuk · Oct 3, 2019

but that does not work

why?

docker exec -it <container name> iris session iris

should do the trick.

0 0

score 0 · Answer 2 · 2019-10-03T16:34:32-04:00

Are you suggesting end users ssh into the docker host and have access to run docker commands? That would presumably grant them administrative access to do anything to or in any container as any user.

I am specifically asking about unprivileged end user terminal access to the terminal session as their own user id.

score 0 · Answer 3 · 2019-10-03T17:00:27-04:00

Your old setup was users sshing into the system, no?

You can try force command a script which execs into a container and exists after that.

Or you can install sshd in your container and allow users to connect to it.

score 0 · Answer 4 · 2019-10-03T17:20:46-04:00

Sounds like installing sshd in the container is the way to go.

I gather this is a relatively uncommon use case.

Thanks for your time.

score 0 · Answer 5 · 2019-10-03T17:23:53-04:00

Eduard Lebedyuk · Oct 3, 2019

You can also try Web Terminal.

0 0

score 2 · Answer 6 · 2019-10-07T15:18:15-04:00

Hi Brendan,

So you must have a CHUI based app or part of it, still on chui/ssh. On one hand I'd like to suggest it's time to move on to something more modern as containers are in general seen as backend services (UDP, TCP, http, etc.) on the other I do understand that it's difficult to evolve quickly.

A few years ago I used to use Tutum containers based on Ubuntu and CentOS that had sshd in it. Docker bought them and their containers disappeared. You can probably still find them in the Docker Hub but they'd be old and stagnating.

Since then you've probably seen this link on the Docker doc. One issue is about users's mapping though, as mentioned. The WebTerminal or managing your sshd are the two most realistic options right now.

Apparently InterSystems is working on something that maybe useful to you but their lips are tight :)

score 0 · Answer 7 · 2019-10-22T08:13:39-04:00

Hi Brendan!

What exactly you are looking for to have in IRIS terminal functionality?

Perhaps web-terminal functionality will be enough for you?

If so, here is the dockerfile which builds IRIS container with web-terminal inside - it installs package manager client (ZPM) and installs web-terminal on top.

HTH

score 0 · Answer 8 · 2019-10-29T11:37:57-04:00

Hi Evgeny,

We need to allow users to log in using their UNIX credentials (via LDAP) and run terminal sessions as their OS user. Because web-terminal works over the SuperServer port, even if we used LDAP auth at that level, their processes would run as the user associated with the SuperServer service, so it does not fit our security model. We will look at it, because it may have some limited usefulness in some contexts, but probably not in production.

Thanks for sharing the dockerfile.