Grouper Users - Open Discussion List

["Black, Carey M." <>]

@ Baron Fujimoto

                Yes.

                Back in the day “SSL processing” was a real CPU/resource drain and offloading that at the LB had a cost savings. But I don’t think that is as true today. ( And the security concerns are generally higher now too. )

 

                The point of using SSL is to “guard the wire”.

                So if the LB holds the “user facing cert” and then re-encrypts the traffic to the back end Webserver(s) then the LB becomes a possible “injection/attack” point. (IMHO: proxy  = injection/attack point )

                My point is that if you need to protect the wire between the LB and the backend webserver(s) then you can still use “certs”. And most LB’s are able to “trust self signed certs”. Yes, to avoid the renewal/cert management issues on the “internal network legs”.  ( Well, frankly the backend can change self signed certs every time they reboot/”spin up the container” if you want to. )

                Obviously not as “strong” as terminating TLS at the application, but much better ( IMHO ) than not using SSL on the second network leg too.

 

                And as Greg points out… you can do your own CA too. ( With all the “normal work” that a CA brings with it. )

                FWIW: I think there is some value there, if you scale far enough to make the CA work “worth it”.

 

 

@ Greg Haverkamp

                Not everyone has such nice tools. (AKA: HashiCorp Vault )

                Kicks some dirt and wanders off muttering:  “Wish I had such nice things.”

 

                😊

--

Carey Matthew

 

From: <> On Behalf Of Greg Haverkamp
Sent: Tuesday, July 21, 2020 7:15 PM
To: Baron Fujimoto <>; Grouper Users <>
Subject: Re: [grouper-users] containerized grouper noob questions

 

You can do that, or you can generate a new cert at container instantiation/run, which is what we do.  We pull a new certificate from our secrets manager (HashiCorp Vault) at container run, and the LB trusts Vault’s CA.

 

I don’t know that that’s necessary for Grouper, but it’s the general model I’d like all of our services to get to.

 

Greg

 

On Tue, Jul 21, 2020 at 4:07 PM Baron Fujimoto <> wrote:

Interesting. Again, to make sure I understand this scenario, you describe having the LB terminate the TLS using a standard CA issued certificate. From there, you forward the traffic – also via TLS to the back end containerized service which is using its own, potentially long-lived (say, to alleviate renewal and cert management issues?), self-signed cert? I suppose this would depend on the capabilities of the LB as well to support this.

I concur it would be preferable to encrypt all the network channels where feasible.

On Thu, Jul 16, 2020 at 12:10:55PM +0000, Black, Carey M. wrote:
>I think it is also reasonable to point out:
>
>Even if you terminate TLS at a Load balancer, you can still use SSL past that point too.
>       Yes, any break in the TLS is a "point of concern". However, IMHO, anywhere you are using http is also an "area of concern" too.
>       AKA: If you are accepting of the "network risk" and use http, then that is a choice. But there are other choices too. 😊
>       A lot of load balancer's are very accepting of self signed certs on the back end web servers. And that at least reduces the "network snooping" risks.
>
>And really, if your Load balancer is compromised then what is really "safe" at that point? ( So don't let that happen. 😊 )
>
>--
>Carey Matthew
>
>-----Original Message-----
>From: <> On Behalf Of Coleman, Erik C
>Sent: Thursday, July 16, 2020 12:32 AM
>To: Baron Fujimoto <>; Grouper Users <>
>Subject: RE: [grouper-users] containerized grouper noob questions
>
>Baron,
>
>We do exactly the last part-- our TLS is terminated at the AWS App Load Balancer, and then everything is proxied non-SSL behind the ALB to the containers, with separate UI and ws container.  We're still on 2.4.0 so Apache is in the middle of that using AJP to Tomcat.  So ours looks something like:
>
>RP: <https://urldefense.com/v3/__https://grouperapp.someschool.edu/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxGql1Rtw$ > (port 443 on ALB) --> UI: https://urldefense.com/v3/__http://ui-container-host:80__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxF_MP6Eg$  (Apache) -> https://urldefense.com/v3/__http://localhost:8009__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9Nx7MwdG-0$  (AJP)
>
>I think this is simplified in 2.5.x.
>
>-Erik Coleman
>
>
>-----Original Message-----
>From: <> On Behalf Of Baron Fujimoto
>Sent: Tuesday, July 14, 2020 4:25 PM
>To: Grouper Users <>
>Subject: Re: [grouper-users] containerized grouper noob questions
>
>Ahh, ok. To make sure I understand, the reverse proxy listens on the standard port 443, and depending on the URI path routes the traffic to the appropriate UI or WS docker container:
>
>RP: <https://urldefense.com/v3/__https://grouper.example.edu/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9Nxz2MxruA$ >    (port 443) -> UI: http(s?)://grouper.example.edu:8080/grouper>
>RP: <https://urldefense.com/v3/__https://grouper.example.edu/grouper-ws__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxYt8uxJo$ > (port 443) -> WS: http(s?)://grouper.example.edu:8888/grouper-ws>
>
>Currently, we terminate our TLS in the shared Tomcat servlet container. How do you handle this when using the reverse proxy? Do you move the TLS termination up to the RP and connect via http to the proxied docker containers?
>
>On Mon, Jul 13, 2020 at 10:51:48PM -0400, Darren Boss wrote:
>>One option would be to set up a reverse proxy in front of the
>>containers that directs traffic to the correct container based on the
>>url pattern. That reverse proxy is grouper.example.edu and it has rules
>>so traffic to /grouper goes to the ui container while /grouper-ws goes
>>to the web services container. In Kubernetes, this is a core part of
>>the platform and called the ingress controller which is typically done
>>via Nginx.
>>
>>On Mon, Jul 13, 2020 at 8:15 PM Baron Fujimoto <> wrote:
>>>
>>> On Thu, Jul 02, 2020 at 05:15:31PM -1000, Baron Fujimoto wrote:
>>> >We're dipping our toes in the water of containerized Grouper, generally upgrading from 2.2 to 2.5. Upgrade issues aside, I have some basic questions about containerized Grouper that I hope aren't too stupid. I poked around the Grouper doucmentation I could find but didn't find what I was looking for – I'm happy to RTFM if someone will point me to TFM.
>>> >
>>>
>>> Different question:
>>>
>>> Our current grouper UI and WS deployments share a common hostname and port (443).  E.g.:
>>>
>>> UI: <https://urldefense.com/v3/__https://grouper.example.edu.grouper/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxbmCVFhw$ >
>>> WS: <https://urldefense.com/v3/__https://grouper.example.edu.grouper/grouper-ws__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxC30Ad0M$ >
>>>
>>> We achieve this by running both services out of a shared Tomcat servlet container. With dockerized Grouper the the best practice seems to be to run each service in its own docker container (each with its own Tomcat servlet container)?  Since each service can't listen to the same port (right?), what is the recommended way of handling this? Just having, say, the WS, listen to a different port? (Assuming we want to retain the same hostname.) E.g.:
>>>
>>> UI: <https://urldefense.com/v3/__https://grouper.example.edu.grouper/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxbmCVFhw$ >
>>> WS: <https://urldefense.com/v3/__https://grouper.example.edu.grouper:9443/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxuvRjJAU$ >
>>>
>>--
>>Darren Boss
>>Senior Programmer/Analyst
>>Programmeur-analyste principal
>>

--
UH Information Technology Services : Identity & Access Mgmt, Middleware
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum