Add support for Redis SSL connections to Elasticache

[NevilleS]

Is your feature request related to a specific problem?

In many production deployments, it's useful to enable Redis SSL (also referred to as Redis TLS, see a long Internet history of using SSL/TLS interchangeably 😄). I suspect the most common use case for this will be using AWS Elasticache, which is AWS' hosted version of Redis (they call it Elasticache to distance from Redis the company). Elasticache supports the ability to enable TLS encryption by default, docs for that are here: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/in-transit-encryption.html

Anyways, Redis SSL can be a bit complicated because there are many ways to do the certificate exchange, including:

1. Use root CA-signed (Lets Encrypt, ACM, etc) certificates: this is the simplest way, because most Redis clients should be able to verify and connect natively without having to provide any kind of certificate files to the client
2. Use self-signed certificates: this avoids paying for root CA-signed certificates, but requires passing extra params to the client like a ssl_ca_certs path to a certificate chain, etc.
3. Use self-signed certificates with client-side certificate authentication: this complicates it even further by requiring the client to also have it's own certificate that the server can validate

Because there are a lot of options here, you'll find a lot of confusing documentation online. However, all I really think we need to support now is option 1, because that's what Elasticache uses.

You can see some basic documentation for enabling SSL connections in redis-py here: https://github.com/redis/redis-py#ssl-connections.

Describe the solution you'd like

I think we should essentially just expose the various connection options to redis-py as documented above. In particular, I think we should at least include the ssl and ssl_cert_reqs options used in the third example (disabling hostname verification), because often in an Elasticache deployment there may be a known mismatch between the hostname and the certificate domain because the implementer may setup a friendly CNAME (e.g. fidesops.redis.mycompany.com) to redirect to the FQDN of the Elasticache instance (e.g. master.**********.cache.amazonaws.com). This is a security vulnerability so we shouldn't disable hostname verification by default of course, but I suspect we'll have several users who know the risk and still want to do that for good reasons. See https://github.com/redis/redis-py/issues/1080 for several examples of why users might need that option!

In other words, I think if we had some config vars like REDIS_SSL and REDIS_SSL_CERT_REQS that were passed along to the redis-py library, we'd be pretty future proof for most Redis SSL connections.

Describe alternatives you've considered, if any

n/a

[seanpreston]

Re: testing, there's a plan to fully host Fidesops and required infra on AWS (with Elasticache). We could functionally test this there.