Grouper Users - Open Discussion List

[Jack Stewart <>]

John,

This really gives us a great push in the right direction!  I am looking forward to reviewing it in more detail very shortly.

Many, many thanks,

Jack

On Wed, May 9, 2018 at 11:44 PM, John Gasper <> wrote:

Hi Jack,

 

We’ve got lots of variables at play here. First, Docker Swarm (which is the TIER reference), K8, AWS ECS, etc. all work Docker Secrets and Configs differently. Second, grouper configs (and embedded secrets) are everywhere… grouper.hibernate.properties, subject.properties, sources.xml, ldap.properties, grouper-loader.properties. Ideally, we could just pass in grouper database settings and all the other info would come from the database. Done! Third, (I’ve deployed many Grouper deployments) everyone is really different. Multiple subject sources, multiple loader sources, many provisioning targets… There are a lot of combinations, and anything other than a very simple env necessarily require modifying many of the previously mentioned files. It can’t be templated very easily.

 

I’m working with a client right now who has duplicated subject, loader, and provisioning targets with differing connection strings, connection account credentials, base DNs, etc. So almost none of the config is baked into the image because everything changes between test and prod, and it is all stored in Docker Secrets and Configs. Here’s a sample of their Swarm secrets and configs:

$ docker secret ls

ID                          NAME                               DRIVER              CREATED             UPDATED

i8vczzgpxfx29i0nxmgt6tls9   grouper-loader-2.properties                            7 days ago          7 days ago

p6g3inpg9jh0zwqbvz38fzcmf   grouper-loader.properties                              13 days ago         13 days ago

vdmz5t01itc3kuk35hnchbecr   grouper.hibernate.properties                           2 weeks ago         2 weeks ago

n69ag5l04jbcz6vv6g5ut76vq   host-key.pem                                           2 weeks ago         2 weeks ago

pf1wnp97ioaiv1m9ykq0qnh7r   ldap-2.xml                                             7 days ago          7 days ago

tzzi9tbxm1voeiyjsf6pc9lcw   ldap.xml                                               12 days ago         12 days ago

jdvlchztqj270koxd1t0m8znr   sp-key.pem                                             13 days ago         13 days ago

uncnezdbqrs41fqd02dntn970   subject-2.properties                                   5 days ago          5 days ago

zvpgp9iztfcslpjxj4wgt5twy   subject-3.properties                                   5 days ago          5 days ago

2z2jrwxneq5a9epr2ikhz37el   subject.properties                                     13 days ago         13 days ago

 

$ docker config ls

ID                          NAME                CREATED             UPDATED

e81oi8bo91g2pzffai4ptqhb2   host-cert.pem       2 weeks ago         2 weeks ago

kxmw0mvrcslgr5q31h8iztea9   shibboleth2.xml     13 days ago         13 days ago

lmw7n0ya1apuau9h1hrg7rk49   sp-cert.pem         13 days ago         13 days ago

 

You’ll notice that some of the items are “versioned”. Swarm doesn’t let you update secrets themselves. You add new ones and update the service to drop the old secret and re-map the new. That may sound painful, but being able to call “docker service rollback ui” and have it revert your configs is pretty cool.

 

I’ve been building a Kubernetes deployment config. Check my next email to the list for details about that. But it’s K8’s secrets and configs is more flexible in some regards and a pain in the butt in others. It expects to set the config files of the entire directory… heaven forbid you don’t want to wipe out the other files in classes/ or conf/. You have to jump through some hurdles to replace only one file at a time… And don’t you dare try to map something into /run/secrets (where Docker Swarm does it), it freaks out. You have to map them into /var/run/secrets/ which gets linked back to /run/secrets. BTW, this all took me about 4 or 5 hours to figure out as it isn’t well documented… (Most K8 people don’t have to worries about using /run/secrets, but we are working with Swarm as the primary target and that is what it does.)

 

So I think the cleaner solution is for someone at Global Summit to buy the Grouper dev team breakfast, lunch, and dinner tomorrow and ask them to centralize the configs into the database. Yes, this has problems too, but it’s a step in the right direction.

 

John Gasper
IAM Consultant
Unicon, Inc.
PGP/GPG Key: 0xbafee3ef

 

From: <> on behalf of Jack Stewart <>
Date: Tuesday, May 8, 2018 at 1:38 PM
To: John Gasper <>
Cc: John Schrader <>, "Hyzer, Chris" <>, Christopher Hubing <>, "" <>, csp study grouper <>

Subject: Re: [grouper-users] Containerized Grouper and Secrets

 

Everyone,

 

Again, this is a great discussion!

 

I guess I've stepping around it this question, but I'll ask it directly: when will the Grouper containers be delivered by TIER in such a way that the configuration files and/or individual configuration parameters can easily be converted to secrets?

 

I've been trying to make the point that if we have to tear into every one of the Grouper configuration files and convert them over to our secrets management system, even if it's only during major upgrades, that's a lot of work.

 

I recently heard that the Grouper containers would be made to be more "Kubernetes friendly" soon.  Is this what was meant?

 

Thanks, Jack

 

 

 

On Mon, May 7, 2018 at 12:21 PM, John Gasper <> wrote:

I’m back… There’s one more option that I just learned about. It requires a more recent version of Docker Engine and be using Swarm mode, but Docker Secrets and Configs supports templating. You can basically set the file to something like this:

 

hibernate.connection.password = {{ secret “grouper_db_password” }}

 

You save the config file as a Docker config, but do it like so:

docker config create --template-driver golang grouper.hibernate.properties ./grouper.hibernate.properties

 

This tells Docker that before it publishes the config file into the running container, grouper.hibernate.properties, needs to run through the golang merge/template process.

 

Now save the password string as a Docker Secret named grouper_db_password.

 

Then when you create your service you just map your secrets like normal and the password will be provided in the config.

 

Unfortunately the functionality is so new that there isn’t a lot of documentation on it, but this blog entry does talk about it some more: https://blog.sunekeller.dk/docker-18-03-config-and-secret-templating/

John Gasper
IAM Consultant
Unicon, Inc.
PGP/GPG Key: 0xbafee3ef

From: <> on behalf of John Gasper <>
Date: Tuesday, May 1, 2018 at 3:46 PM
To: John Schrader <>, Jack Stewart <>

Cc: "Hyzer, Chris" <>, Christopher Hubing <>, "" <>, csp study grouper <>
Subject: Re: [grouper-users] Containerized Grouper and Secrets

 

Hey all,

 

Sorry, I’m late to this party. I’ve got a few tidbits to share that might be beneficial to you or others in the future. (And John that’s great info about the AWS SecretsManager)

 

One of the TIER requirements was to be able to read in password from an env parameter or from a file specified by env parameter. This doesn’t necessarily make sense for Grouper since we have to customize the property files anyways, but I’ve got some examples in the image source’s test directory:

Two examples of the EL code:

https://github.internet2.edu/docker/grouper/blob/master/test-compose/configs-and-secrets/grouper/grouper.hibernate.properties#L29

https://github.internet2.edu/docker/grouper/blob/master/test-compose/configs-and-secrets/grouper/subject.properties

And applying it using both methods: https://github.internet2.edu/docker/grouper/blob/master/test-compose/docker-compose.yml#L46-L47

 

If you were going with this method, I’d pick the one that is appropriate and just use that chunk, but it’s your env do as you want. 😊

 

Also, I’m working on some videos showing how to use the TIER Grouper image in Docker Swarm. I’m waiting for approval of the videos and then I’ll post about them on the list, but all of the step-by-step source material is here and shows how to use Docker Secrets: https://github.com/Unicon/tier-grouper-deployment. Using this method, the sensitive files and env specific config files are managed by Swarm. This has the upside of being able to run “docker service rollback XXX” and it switches configs/secrets to the previous config. (It’s actually pretty cool to call rollback several times and watch it switch your service back to the image/config several versions ago.)

 

Of course you can always use morphStrings to store your passwords, and mount them however you want to, and reference those locations in the properties file. I’d probably still manage the files with “docker config” since you’ll likely use databases and data sources that are different between test and prod. If the files are the same, then I’d just manage them as project source that gets backed into the image.

 

OK, my two cents.

 

John Gasper
IAM Consultant
Unicon, Inc.
PGP/GPG Key: 0xbafee3ef

From: <> on behalf of John Schrader <>
Date: Sunday, April 29, 2018 at 9:10 AM
To: Jack Stewart <>
Cc: "Hyzer, Chris" <>, Christopher Hubing <>, "" <>, csp study grouper <>
Subject: Re: [grouper-users] Containerized Grouper and Secrets

 

This is a great conversation..

 

For those of us running in AWS cloud, AWS has released "SecretsManager" [1]

 

SecretsManager opens up some interesting possibilities for both EC2 instances and containers(tasks) running in ECS.

 

As a POC, I've created an elConfig class (thanks to Chris for the capability) that retrieves values for hibernate properties:

hibernate.connection.url.sm.elConfig            = ${edu.internet2.middleware.grouperClient.config.SecretsManagerElClass.getSecret('/grouper/dev','url')}

hibernate.connection.url                        = $$hibernate.connection.url.sm$$

hibernate.connection.username.sm.elConfig       = ${edu.internet2.middleware.grouperClient.config.SecretsManagerElClass.getSecret('/grouper/dev','username')}

hibernate.connection.username                   = $$hibernate.connection.username.sm$$

hibernate.connection.password.sm.elConfig       = ${edu.internet2.middleware.grouperClient.config.SecretsManagerElClass.getSecret('/grouper/dev','password')}

hibernate.connection.password                   = $$hibernate.connection.password.sm$$

from SecretsManager.

 

Read/Decrypt access to the `/grouper/dev` secret is controlled by the role associated with an EC2 instance or ECS task.

Using a role helps with the initial credential bootstrapping and allows for immutability.

 

-John

 

[1] https://aws.amazon.com/secrets-manager/

 

 

 

 

 

 

 

 

On Thu, Apr 26, 2018 at 1:27 PM, Jack Stewart <> wrote:

Everyone,

Thank you all for your wonderful feedback!  I hope the discussion continues.

A few thoughts:

- Although Grouper can run with environment variables, it would take a lot of time to convert, and each major upgrade could possibly be made tricky as a result.  Or am I being too paranoid?

- I don’t quite see consensus on a clear way forward.  All the information presented here has been helpful, though.  I will check what others are doing locally.

Jack

 

-- 

Jack Stewart

Solutions Architect, Identity and Access Management

University of Michigan

4251 Plymouth Road

Ann Arbor, Michigan 48105-3640

(734) 764-0853

On Apr 26, 2018, at 12:39 PM, Hyzer, Chris <> wrote:

Fyi grouper config can happen in env vars, also the sources.xml can be migrated to subject.properties

https://spaces.internet2.edu/display/Grouper/Grouper+configuration+overlay#Grouperconfigurationoverlay-Environmentvariables

https://spaces.internet2.edu/display/Grouper/Grouper+sources.xml+conversion+to+subject.properties

Thanks
Chris

-----Original Message-----
From: [] On Behalf Of Christopher Hubing
Sent: Wednesday, April 25, 2018 1:00 PM
To: Jack Stewart <>
Cc: ; csp study grouper <>
Subject: Re: [grouper-users] Containerized Grouper and Secrets


For I2, we are storing secret things in an encrypted S3 bucket. The build
host has access to read from it, and then pushes the images to a private
Elastic Container Repo. The containers run in ECS.

Here's an example of our Dockerfile for the UI:
https://github.internet2.edu/gist/chubing/c4e663ab5a39fb73dccdcd748a92c5fe

Since the new Grouper container is pushed to Dockerhub (and have tags for
patches), it should make it pretty easy to manange (hopefully).

-c

On Wed, 25 Apr 2018, Jack Stewart wrote:

Everyone,

I would like to start out by saying that the new role-based Grouper containers are great!  It was very easy to build the images.

 

Now my question is, what are other schools doing with regard to their Grouper configurations?  Are you "burning them into" storing them in the containers themselves, or are you using

secrets?

 

Converting an application like Grouper to use secrets would be a LOT of work.  Effectively, you would need to convert all of the settings to environment variables.  How would you deal with

the sources.xml files which, by design, need to be customized?

 

Many thanks,

Jack

 

 

--

Jack Stewart

Solutions Architect, Identity and Access Management

University of Michigan

4251 Plymouth Road

Ann Arbor, Michigan 48105-3640

(734) 764-0853

 

 

 

--

John Schrader

Identity and Access Management

Office of Information Technologies

University of Notre Dame

 

EVERYTHING SHOULD BE MADE AS SIMPLE AS POSSIBLE, BUT NOT ANY SIMPLER

—ALBERT EINSTEIN

 

--

Jack Stewart

Solutions Architect, Identity and Access Management

University of Michigan

4251 Plymouth Road

Ann Arbor, Michigan 48105-3640

(734) 764-0853

--

Jack Stewart

Solutions Architect, Identity and Access Management

University of Michigan

4251 Plymouth Road

Ann Arbor, Michigan 48105-3640

(734) 764-0853