We need to establish the security features that make sense for a session storage service, and implement them accordingly (i.e. encryption, access lists, client/server certification verification).
|Open||None||T88445 MediaWiki active/active datacenter investigation and work (tracking)|
|Stalled||Eevans||T206016 Create a service for session storage|
|Resolved||Eevans||T209109 Security model for session storage service|
- Mentioned In
- T215533: Enable use of session storage service in MediaWiki
T206015: Plan/design a session storage service
rMSKS34db308be8fc: Kask TLS configuration
rMSKS61197b442a84: Kask TLS configuration
rMSKS5a95f18dcfd7: Kask TLS configuration
rMSKS689367a764b4: Kask TLS configuration
rMSKSf183b1a8f33b: Kask TLS configuration
rMSKS5689e47f47da: Kask TLS configuration
rMSKS38feecfb7d38: Cassandra client authentication
rMSKS4af5ac8dd299: Cassandra client authentication
rMSKS9f7557fe6459: Cassandra client authentication
rMSKS43f383dd7e71: Cassandra client encryption
To summarize a (IRC) discussion w/ @Joe today:
- We most definitely need to TLS encrypt HTTP connections
- With TLS encryption in place, a certificate trust chain would likely suffice for authentication
- The use of HTTP basic auth could also work, so long as the Authorization header is encrypted over the wire (see above)
- A certificate trust chain would technically be more secure, but imposes a significant maintenance burden (maintaining a CA, and (re)issuing signed certs)
Any input from the Security-Team here would be appreciated.
I believe the current status here to be:
- Connectivity to session storage will be IP-restricited
- We will TLS encrypt the connection between MediaWiki and session storage
- We will (eventually) use CA-signed certificates, and validate them
- We may move to production (with 1 & 2), and followup with 3 later after sorting out CA particulars
@Joe, @akosiaris does this reflect your opinion as well? I think this issue has remained open to this point in case we needed to implement HTTP basic auth in Kask. If that is not the case, then perhaps we can close this issue?
Hi, sorry for the late answer, offsites...
#1 is a bit unclear to me. Yes, the cassandra nodes are IP restricted indeed and only accept connections from the kubernetes pod range. The kubernetes pods range is also IP restricted and only the sessionstore pods can connect to cassandra.
However, anything can currently connect to the sessionstore. IP limiting this is technically possible, however it is going to be a gigantic mess to implement as the mediawiki hosts are NOT some separate network, but rather intermingled with all other hosts. Thus it will require maintaining a list of all mediawiki hosts IP addresses which is very very error prone and tedious (we don't do it for any other service mediawiki connects to either right now).
#2 wise, fully agreed.
#3 wise, we already use CA-signed certificates for the service itself, trusted across our infrastructure. mediawiki hosts already trust it and indeed do verification of certs issued by it (unless I am horribly mistaken, the PHP libraries anyway already do, curl/libcurl definitely do).
So, regarding #4, numbers 2 and 3 are already working anyway, I am not sure if there was an assumption about #1 meaning only mediawiki would be able to connect network wise to the sessionstore.