Allow pam to contact external motley cue endpoint

[samuelbernardolip]

Currently, to use ssh-oidc connection flow, is required to install server side the pam module and the service motley cue. The current flow require the client to contact the server in two open ports, one for ssh another for motley clue token endpoint and also to retrieve the user claims and translate them to posix user attributes.

This kind of setup brings more surface attack on server side, since we have 2 ports open and more software to keep on each node. I suggest for future work to improve pam module configuration, so both attributes and token could be retrieved from an external endpoint, like when using an LDAP endpoint.
A central endpoint for motley cue will also turn easier the management of multiple nodes, since, in that case, would only be required to install the pam module.

[dianagudu]

This is possible, in principle. You can run motley-cue on another machine and update the configurations to use this motley cue endpoint:

• server side: for the PAM module, configure the verify_endpoint in /etc/pam.d/pam-ssh-oidc-config.ini
• client side: use mccli with --mc-endpoint URL

What is left is to configure how the local accounts are being managed, since motley-cue creates local accounts that need to be available on the host running the ssh server.

• with the LDAP backend (configured in feudal_adapter.conf of motley-cue), motley-cue can create accounts in an LDAP server (or you can pre-create them in another way beforehand), so what is left is to configure the server to also use this LDAP in /etc/nsswitch.conf (+ nslcd installed)
• with the local_unix backend it's tricky, since motley_cue simply runs useradd and other linux utilities, so you'll need a way for the NSS on the server to read from the files on the motley-cue instance (/etc/passwd, /etc/group, /etc/shadow), maybe by mounting them in each VM (I did have some issues with this idea of mounting them when I tried this with docker, so it needs more tinkering).

It definitely needs to be streamlined and tested.

[samuelbernardolip]

Hi @dianagudu
Very good news since there is already the support in mccli and motley-cue to run using a central endpoint.
About the account management, I think would be possible to have a LDAP server in same machine as motley-cue, and then configure nsswitch to get the accounts from that ldap endpoint. So, thinking in containers this would be translated to two containers, one for motley-cue and another for openldap for example.
The use case I'm interested to apply this is different from the VMs context. I would like to use it to provide ssh access to a deployed testbed in CI/CD pipelines. This would be using any kind of virtualization, but I'm thinking here on containers, since it is the most popular approach for almost all applications and services nowadays.
So describing the scenario with K8s, we add the containers for motley-cue and openldap (maybe on same pod), where configurations will be loaded during container init (I think this will need some work here), so all others could be accessible using the tool mccli from the pipeline. Then the kubectl containers to run the commands to interact with kubernetes cluster using ssh-oidc (using ssh as a way to access the K8s API avoiding to open security breaches even in testing phase). For the client, here in LIP, we have already created a docker image for that.

So let see how I can fit this on my agenda to test ssh-oidc in CI/CD.