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).
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | aaron | T88445 MediaWiki active/active datacenter investigation and work (tracking) | |||
| Resolved | Eevans | T206016 Create a service for session storage | |||
| Resolved | Eevans | T209109 Security model for session storage service |
Event Timeline
Comment Actions
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.
Comment Actions
@Eevans, @Clarakosi - just booked a quick hangout with the Security-Team for this Friday (2/15) to discuss potential security concerns for this service.
Comment Actions
Change 490106 had a related patch set uploaded (by Eevans; owner: Eevans):
[mediawiki/services/kask@master] Cassandra client encryption
Comment Actions
Change 490106 merged by Clarakosi:
[mediawiki/services/kask@master] Cassandra client encryption
Comment Actions
Change 490332 had a related patch set uploaded (by Eevans; owner: Eevans):
[mediawiki/services/kask@master] Cassandra client authentication
Comment Actions
Change 490332 merged by Clarakosi:
[mediawiki/services/kask@master] Cassandra client authentication
Comment Actions
Change 491862 had a related patch set uploaded (by Clarakosi; owner: Clarakosi):
[mediawiki/services/kask@master] Kask TLS configuration
Comment Actions
Change 491862 merged by Eevans:
[mediawiki/services/kask@master] Kask TLS configuration
Comment Actions
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?
Comment Actions
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.