Config choices for tier/shibbidp_configbuilder_container

[Paul Caskey]

Hi Darren-

I’ll take a look at the ConfigBuilder this week.  I need to modify it to use the InCommon MDQ service rather than the aggregate and will take a look at the FERPA consent thing as well.  FWIW, it pulls the config from this repo/branch: https://github.internet2.edu/docker/shib-idp-conftree/tree/3.4release

Running as root in containers was a conscious decision from the packaging working group.  We can re-visit this on the community calls (now called the Software Integration calls) on Wednesdays and Fridays.  Let me know if you’re interested in joining us for those.

In the future, for container-specific issues, you can post in our incommon-shib slack channel or send email to help at incommon.org<mailto:help at incommon.org>

Thanks for the feedback!



From: users <users-bounces at shibboleth.net> on behalf of Darren Boss <darren.boss at computecanada.ca>
Reply-To: Shib Users <users at shibboleth.net>
Date: Wednesday, October 2, 2019 at 7:45 AM
To: Shib Users <users at shibboleth.net>
Subject: Config choices for tier/shibbidp_configbuilder_container

This might not be the right forum for discussing the configuration choices in the tier/shibbidp_configbuilder_container image but they caused me some frustration and I'm curious to know if this was a purposeful decision or possibly some of this configuration was accidentally left in.

In the profile-intercept.xml file the intercept/attribute-release has an activation condition related to a FERPA attribute which only enables the attribute release consent flow if it finds this attribute to be true/yes. I had done some modifications in the intercept configuration so when I was trying to get my configuration working with the tier/shib-idp image, I was assuming that it was something in my own configuration that I had messed up or not merged into the configuration generated by the config builder. Seems like an odd decision to only trigger attribute release consent only when a FERPA attribute is present for a user.

That being said, I'm very pleased to see the docker images for many of these projects being built via CI and available to the community. One thing I'd like to see is the images run the services under a non-root account. You wouldn't run the tomcat or jetty server as root on a virtual machine so why run as root in the containerized deployment.

I haven't done an empirical test yet but it does seem like the tier/tap image is loading a lot faster than what I was experiencing with the Unicon shib image I was basing my deployment on previously. That is likely due to the change in the JVM used (Azul vs. Corretto). I've been able to drop my initial delays for the Kubernetes health probes way back from what I was previously using even with Jetty java.security.egd tweaks in place.
--
Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal
darren.boss at computecanada.ca<mailto:darren.boss at computecanada.ca>
(o) 416.228.1234 x 230
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20191002/da1808a0/attachment.html>