Bug 1749910

Let's punt this to 4.3

I know Jakub Hrozek has been looking at this. Looping him in.

(In reply to Ben Breard from comment #2)
> I know Jakub Hrozek has been looking at this. 

More or less, I was also looking at using OCP's users (through the tokenReview API) to log into the worker nodes. More details are at https://docs.google.com/document/d/1qh-Xub-dkkGPvL-wr3APd5fOS8QkVBQiAnYFeGOClqw/edit?ts=5d5bf934#heading=h.9khfep37qdjo

(In reply to Alex Crawford from comment #0)
> I went through the exercise of trying to use SSS so that I could use my
> Kerberos credentials to SSH to RHCOS, but I ran into a few snags. Here were
> the steps that I had to follow:
>  # Add an SSS config

Right, I was using an MC in an OCP cluster to just drop a file. Whatever gets you to that config.

>  # Enable sssd.service

I was using an MC like this in OCP env for enabling the service:
spec:
  config:
    ignition:
      version: 2.2.0
    systemd:
      units:
      - name: sssd.service
        enabled: true

The interesting thing is that with recent versions of SSSD, if there is no configuration at all, then SSSD just serves users from /etc/passwd and groups from /etc/group via its interface, so you can as well just enable the service even w/o a config file. RHEL does that.

>  # Modify the PAM configuration to use pam_sss.so

So I'm still not so well-versed with COS, but as Alex said, I would also suggest to just enable pam_sss.so in the PAM config always because:
 - reconfiguring the host is harder than RHEL
 - RHEL also has been configuring pam_sss.so by default for ages (since RHEL-6..)
 - there is very little downside to having the extra module. The module just checks if SSSD is running and if not, then returns an error code
 - perhaps then both RHEL and COS could ship the same tested PAM config?

> There's no getting around the first step, but the second and third could be
> made easier. At the very least, I think we should reconfigure PAM to consult
> SSSD. 

+1

> It's probably okay to leave sssd.service disabled by default.

Hmm, maybe. But I'm biased :-)

> The interesting thing is that with recent versions of SSSD, if there is no configuration at all, then SSSD just serves users from /etc/passwd and groups from /etc/group via its interface, so you can as well just enable the service even w/o a config file. RHEL does that.

Sweet. Let's do that as well. That reduces this exercise to a single step, which will make everyone happy.

Linked MR does the bare minimum and enables `sssd` by default.  Please let me know if additional changes are requested.

Follow on for testing https://github.com/coreos/mantle/pull/1117

Follow on merged.

MR has been merged and changes are in the ART builds.

I verified that the sssd.service is enabled by default now.  This is the bare minimum as Micah stated above.  There is no sssd config and no PAM configuration to use pam_sss.so.  Is that sufficient Alex?  If so this BZ can be closed as verified.

4.3.0-0.nightly-2019-11-18-175710

$ oc debug node/ip-10-0-143-180.ec2.internal
Starting pod/ip-10-0-143-180ec2internal-debug ...
To use host binaries, run `chroot /host`
If you don't see a command prompt, try pressing enter.
sh-4.2# chroot /host
sh-4.4# ls
bin   dev  home  lib64	mnt  ostree  root  sbin  sys	  tmp  var
boot  etc  lib	 media	opt  proc    run   srv	 sysroot  usr
sh-4.4# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-11-18 22:56:47 UTC; 15h ago
 Main PID: 1801 (sssd)
    Tasks: 3 (limit: 26213)
   Memory: 35.7M
      CPU: 981ms
   CGroup: /system.slice/sssd.service
           ├─1801 /usr/sbin/sssd -i --logger=files
           ├─1827 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
           └─1828 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files

Nov 18 22:56:47 localhost systemd[1]: Starting System Security Services Daemon...
Nov 18 22:56:47 localhost sssd[1801]: Starting up
Nov 18 22:56:47 localhost sssd[be[implicit_files]][1827]: Starting up
Nov 18 22:56:47 localhost sssd[nss][1828]: Starting up
Nov 18 22:56:47 localhost systemd[1]: Started System Security Services Daemon.

I think we still need to update the PAM configuration since that is the most difficult thing to get right. This is definitely not needed for 4.3 though, so we can change the target version. The existing change is okay to go in as is so we don't need to roll anything back before we release.

Filed BZ#1774154 to track the remaining work.

Moving to VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0062