2019-06-28 - System Operations and Management SIG Agenda and Notes
Date
Attendees
- VBar
- Christopher Creswell
- Greg Delisle
- Robert Douglas
- Johannes Drexl
- Anton Emelianov (Deactivated)
- Ian Hardy
- Hkaplanian
- Philip Robinson
- jroot
- Wayne Schneider
- Catherine Smith
- Alexander Soto
- Brandon Tharp
- Ian Walls
- Todd Wallwork
- patty.wanninger
- UMass Amherst
Goals
- Okapi Security
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 5 | Welcome | Ingolf |
|
| Securing Okapi - FOLIO Security | Ingolf, Johannes Drexl | Meeting Notes: Ingolf had some questions concerning SSL secured communication to and from Okapi (Slides by Ingolf; summary of a conversation between Julian Ladisch and Ingolf). Okapi itself communicates via HTTP, but most run it behind a load balancer which provides HTTPS. Jason: At TAMU, all network communication is with load balancing. Jason has a workload for each backend module. The workload contains more than one (typically 3-4) instance of each module. They are using DNS round robbing. Everything has a route. Tunneling is used. Routing is abstracted away from the network layer. Getting there is not straight HTTP. It's encapsulated. The only ingress is to Stripes and Okapi. Harry: What if one wants to deploy e.g. a student management system - this will not be going through Stripes. Jason: Edge modules are separately put up; separately from Okapi and Stripes. Wayne: Okapi is not an HTTPS server; it could not accept HTTPS. ----- Jo explains security concerns around Okapi and FOLIO modules. You can use the postgres database only for Okapi. Once the database is breached, the whole database is for the dust bin. Without superuser rights you can't set it (Okapi) up. Wayne: mod-login, mod-permissions and mod-users require superuser privileges, Okapi itself does not. Jo shows an example of a wiki which he has set up. "mywiki" is the only database the wiki user has any rights on. There is no need for superuser privileges. It should be done (in FOLIO) in the same way. Jo: The whole background communication is unencrypted, unless you set up tunnels. The communication with the postgres server is also unencrypted. If you force SSL connection (in pg_hba.conf), postgres says "no encrypted traffic is allowed". Jason: We didn't try SSL down all the way to the postgres databases. Jo shows an internet page https://xkcd.com/2166/ which explains "the modern tech stack". Jo: You have to make sure that you are talking to a specific module and only to this module. No man-in-the-middle attacks. Anton: I agree. We have to find out how to get it fixed. SysOps need to be smarter, to create tunnels. Jo: If you can execute code within a docker container, then you can talk to Okapi. You don't bring down the container. In this way, you can hijack the system. Harry: We should log these issues into JIRA. We will have a security audit. Jo will submit a presentation to the Chaos Communication Congress, which will take place in the last week of the calendar year. The Chaos Communication Congress is the Chaos Computer Club’s (https://www.ccc.de/en/) annual symposium and hacker party. Philip: Jo, this was extremely valuable. Jo: Have to consider a black list vs. a white list approach Wayne: Okapi has its own storage which is managed by Okapi. Okapi is not responsible for module storage, each module is responsible. Jo: You have to give the Okapi user superuser privileges, otherwise this doesn't work: https://github.com/folio-org/okapi/blob/master/doc/securing.md Wayne: SysOps can ameliorate some of these concerns. | |
| Wrap-up | Ingolf | Wayne summarized the security concerns into three topics. — See the action items below. The security concerns are of high priority and will be relevant for all of the group. We will resume the discussing about security in the next group meeting. There will be a lot of coding involved to address these issues. There is "priorization of tasks" (I don't recall the exact terminology of this meeting) in three weeks from now, we should have created JIRA tickets by then (Anton). Tod: Chalmers plans to go live in August, but the next full implementers plan to go live November 2019. So we can proceed in the regular way Ingolf: We will skip next week's meeting due to the U.S. Independence Day weekend. We will meet again on July 12th and address the issues around FOLIO security. I wish you a good weekend and a happy holiday. | |
| Topics for next sessions: | |||
| Upgrading and updating | UXPROD-1815 - Getting issue details... STATUS (Jakub ?) |
. Although some plan to go live only with ERM already by the end of 2019.Action items
Intra-module communication and database communication encryption
Reliance on a single point of failure for authorization (mod-authtoken)
Superuser database access