Grouper Users - Open Discussion List

[Darren Boss <>]

I didn't start the thread but for me, definitely using shib SSO so apache, shib and tomee.

Not running SSL inside the container. We've almost switched everything public over to using Let's Encrypt and for Kubernetes there is the excellent cert-manager which you can deploy into the cluster and have request/renew all the TLS certs for everything. The norm is to terminate TLS at the ingress which is what I've been doing with all our deployments so far.

As with Oliver, if I would have been tempted to take Apache/Shib into a separate container but that being said, I've so far had no issues when running the Grouper or COmanage TAP images under K8s so far.

The other thing I would really like is a health status url in both Grouper and COmanage that I can hook up to the liveness and readiness probes. I think there is a feature story in COmanage for this, possibly it's even available now in the new release which I haven't looked at yet. I have this for the Shibboleth IdP at /idp/status.

It looks like the /grouper/status?diagnosticType=trivial url could be used for this if it was exempted from shibboleth authentication but locked down to the ip range for the internal nodes where the heath checks are done.

On Fri, May 1, 2020 at 3:42 AM Hyzer, Chris <> wrote:

Ive got something working here and I can picture moving some options into the container.  Are you planning on running apache, shib, and tomee?  Will you have SSL in the container or outside?  Are you ok that the user running the processes in the container can read private keys (e.g. the tomee user could read shib and apache keys)?

 

https://spaces.at.internet2.edu/display/Grouper/Grouper+Container+v2.5+POC+running+as+non-root

 

Seems like we should pass in some ARGS to the container: uid/user/gid/group to run as, and if those are set, the grouper container would chown and allow apache to listen on 443.  Would that cover it?

 

Thanks

Chris

 

 

 

 

 

From: On Behalf Of Darren Boss
Sent: Monday, April 27, 2020 7:52 AM
To: Oliver Trieu <>
Cc: Scott Koranda <>;
Subject: Re: [grouper-users] Openshift Deployment

 

Well, the Grouper image isn't one process per container. If you do shib then you have Tomee, Shibd and Apache all running together and configured to run under different user processes. I'll do a ps from the running container later today. I had some other issues with the UI under which I think I've finally been able to solve that stems from the way the http connection get proxied to the container in my setup (Nginx L4 LB -> Nginx Ingress -> NodePort Service -> Pod) which took a couple days of poking at to get working. I believe it's related to the CRSF proectections and some other mangling of http headers.

 

On Mon, Apr 27, 2020, 6:10 AM Oliver Trieu <> wrote:

Dear Darren,

 

could you elaborate on what kind or problems you expect with runAsUser in a Pod?

I am currently running our test instance of grouper 2.4 on Openshift and so far i did not encounter issue.

Is there an easy way to specifically test for this?

 

Kind Regards

 

Oliver

On 22.04.20 16:31, Darren Boss wrote:

That may not be good enough for the Openshift case but since I haven't used Openshift I can't say for sure.

 

I'm not sure about dropping privileges. It seems like a step in the right direction but I'm not sure what happens when combined with specifying security contexts in the pod (runAsUser). I'd be willing to do a bit of digging or run some tests on a test cluster if that was of interest.

 

I'm still ramping up my knowledge on the security side of running services under Kubernetes.

 

On Wed, Apr 22, 2020 at 9:50 AM Scott Koranda <> wrote:

Hi,

Just a clarifying question...

Would you find it acceptable for the container to start running as root
and then drop privileges later to a non-privileged user, or is your
requirement that the container never need any root privileges at all?

Asking for a friend...

Thanks,

Scott K

> Even if not running under Openshift and just upstream Kubernetes, please
> retool the Docker images to not run as root (this applies to the other TAP
> images as well).
>
> Containers are not vms and unless you are running with uid
> translation/mapping in place, the grouper process would be running at root
> on the system as well. From what I've read, running within a user namespace
> and remapping uids can impart a performance penalty.
>
> On Wed, Apr 22, 2020 at 3:22 AM Oliver Trieu <>
> wrote:
>
> > Dear Grouper Team,
> >
> >
> > I think its great that Grouper is now running on containers.
> >
> > This is definitely a step in the right direction.
> >
> > I was wondering if you could prepare your Container Image to run on the
> > Openshift Platform.
> >
> > The issue here is that the current Image wants to run as the root user.
> >
> > It would be great if you could run it as an unpriviledged user.
> >
> >
> > Is it possible to obtaiin the Dockerfiles you used to create the images?
> >
> >
> > Kind Regards
> >
> >
> > Oliver
> >
> >
> >
> >
> >
>
> --
> Darren Boss
> Senior Programmer/Analyst
> Programmeur-analyste principal
>

--

Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal

--

Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal