Date

24-Feb-2021

Attendees

Discussion items

Time	Item	Who	Notes
	Kafka Security	VBar and Vasily Gancharov	One of the changes that are being made as part of Iris is to drop PubSub (which uses Kafka and enforces FOLIO security via Okapi and FOLIO standard authentication methods) for Data Import and instead mode to direct Kafka Access. This raises security implications that didn't exist before. Vasily Gancharov has created a design for securing this design - Temporary Kafka security solution. Note that the Elastic Search work is also using this direct Kafka access. Vasily and Vince will present and answer questions. Notes: Proposed approach to Multi-tenancy for Kafka are very analogous to how the project uses PostgreSQL and its used of separate schemas per tenant. However there are differences because how the system is deployed will impact the degree of tenant separation. This document describes the model, not necessarily the implementation. This is a "temporary" solution - because a more formal permanent solution couldn't be achieved in the timeframe. Recommendation is to have a separate Kafka user per module per tenant to have ultimate "least privileged" access, but a user per tenant is also supported by this model (or even a mix). How will administrators setting up the system know how many users and what the ACLs need to be? Note that the methods for how exactly this can be managed/achieved hasn't been documented yet. Note that a script could also be created to provision the users and setup their permissions. This document will be how implementation should be done /wiki/spaces/~Vasily/pages/3571890 The permanent solution would be to have a single security solution in FOLIO that addresses the needs of Kafka - so that it's not managed separately. We are not clear whether the modules (Data Import and Elastic Search) have adopted this model or not. We need to identify what they've done wrt configuration, use and authentication of Kafka. Vasily Gancharovwill investigate and report back to the Tech Council Our conclusion is that in general this design is acceptable. There are open questions as to whether this can be implemented for R1 and what the ramifications are for Data Import and Elastic Search for R1.

Time

Item

Who

Notes

Kafka Security

VBar and Vasily Gancharov

One of the changes that are being made as part of Iris is to drop PubSub (which uses Kafka and enforces FOLIO security via Okapi and FOLIO standard authentication methods) for Data Import and instead mode to direct Kafka Access. This raises security implications that didn't exist before. Vasily Gancharov has created a design for securing this design - Temporary Kafka security solution. Note that the Elastic Search work is also using this direct Kafka access.

Vasily and Vince will present and answer questions.

Notes:

Proposed approach to Multi-tenancy for Kafka are very analogous to how the project uses PostgreSQL and its used of separate schemas per tenant. However there are differences because how the system is deployed will impact the degree of tenant separation.
This document describes the model, not necessarily the implementation.
This is a "temporary" solution - because a more formal permanent solution couldn't be achieved in the timeframe.
Recommendation is to have a separate Kafka user per module per tenant to have ultimate "least privileged" access, but a user per tenant is also supported by this model (or even a mix). How will administrators setting up the system know how many users and what the ACLs need to be? Note that the methods for how exactly this can be managed/achieved hasn't been documented yet. Note that a script could also be created to provision the users and setup their permissions.
This document will be how implementation should be done /wiki/spaces/~Vasily/pages/3571890
The permanent solution would be to have a single security solution in FOLIO that addresses the needs of Kafka - so that it's not managed separately.
We are not clear whether the modules (Data Import and Elastic Search) have adopted this model or not. We need to identify what they've done wrt configuration, use and authentication of Kafka. Vasily Gancharovwill investigate and report back to the Tech Council

Our conclusion is that in general this design is acceptable. There are open questions as to whether this can be implemented for R1 and what the ramifications are for Data Import and Elastic Search for R1.

Browser not supported