I'd like to limit the way Redis is used for the applications that access it, as well as for users so that not every application/user has access to all data.
Is there a way of doing access control on Redis so that applications are only allowed to access certain keys and not others?
Not at the moment. Currently Redis provides a single authorization password per Redis server, which grants full admin and data access to all (shared/numbered) databases in it.
Simple answer is No, This should be handled in the application end.
While Redis does not try to implement Access Control, it provides a tiny layer of authentication that is optionally turned on editing the redis.conf file.
-redis.io
As mentioned above redis provide only a tiny layer of authentication, everything else should be handled by the application.
Related
I have a question about giving access to k8s cluster. For example, new member joined our team. He created certificatesigningrequest and I approved it. Then created kubeconfig and give it to him to access our cluster. One day if he leave our team how can remove his access? I want he can not access to our cluster with this kubeconfig.
Imho you should use an external authentication provider. You can take a look at https://dexidp.io/docs/kubernetes/ which is an abstraction layer to other IDaaS-Providers like Azure, Google, Github and many more. For example, if your company uses Active Directory, you can control the access to the cluster using group memberships, where withdrawing access is then part of the company-wide leaver process.
We care currently running LDAP as a Master-Master configuration with one primary. We are supplying the Spring LdapContextSource with two LDAP nodes to use as primary/failover.
We went to this configuration because previously our LDAP had been behind an f5 load balancer, but we would run into replication issues when a user was created on Node A, but the f5 sent the updates to Node B before the two could sync.
However, now we are running into a situation where we are over-utilizing one node. And ignoring the second node.
What I would like to be able to do is configure the f5 such that all Create, Update, Delete operations went to a primary node, but reads were distributed between the two LDAP Nodes.
Any thoughts on how to configure the f5 to achieve this?
For reference we are using a 389-ds implementation of LDAP.
Recommendation: Split the work into two separate VIPs if possible. At least that's what we've done with mysql here — a write VIP and a read-only VIP. I know this question is for LDAP, but LDAP is a type of database, and your needs are very similar to mysql read/write dilemmas.
Write VIP: Set up your F5 pool with Priority Group Activation set to "Less than 1" on the Members tab. This is a failover configuration and does not split load since the LDAP sync isn't fast enough to support it. The higher priority number takes the traffic first. If it goes down, traffic flows to the lower priority. You assign priority as you are adding each node.
Read VIP: Load-balance traffic with a typical configuration as you had it before.
In both VIPs, of course you need a valid LDAP query in your health monitor that proves the service is working correctly. If allowed by your directory, you don't even have to login. You can just read the directory, searching for a particular base and filter defining an object within that base. This makes the health monitor faster and less troublesome while remaining effective. LDAP login in F5 monitors can be a major pain, so it's nice to skip it when feasible.
In my project, I am planning to use multiple backend to store different data in my spring cloud conifg server setup: use git backend to store un-sensitive data, and use vault to store sensitive data like password/token. This is simiar to what https://content.pivotal.io/blog/spring-cloud-services-supports-vault-multiple-backends-use-the-right-config-repo-for-the-job suggests.
My question is since the returned decrypted value from vault is passed back to "client application" through config server, will config server cache/store/log the response from vault in any way. If this is true, config server will be a big target for hacker and we may have to protect the config server with extra configuration.
I suppose the true answer to your concern would be to secure each and every layer of your stack to prevent intrusion at any single point.
The Spring documentation makes no explicit reference to caching data - so you should be safe in that regard. It would also not make a lot of sense for Config Server to cache the configuration from external data stores as it is not the source-of-truth for that data. We want it to always fetch the data from source to ensure we get the latest version of the data. I'm supposing that there might be a case of caching if Config Server stored the configuration locally and was able to watch the files for changes and refresh its cache accordingly. But having said that, I'm still not sold on the benefit of caching at this layer.
From personal use of Spring Cloud Config Server I've yet to see it logging out the entire configuration; in-fact it logs very little to start off with. I'm sure you can suppress logging even further by setting the appropriate levels.
What you should also look at doing is securing the connections between Vault & Config Server and Config Server and each application using SSL. That will prevent you from transmitting data in clear text and will provide you with an additional layer of security.
I have a web farm in amazon and one of my sites need some caching.
I am considering the use of Elasticache redis.
Can anyone shed some ligth on how I would connect and interact with this cache?
I have read about several client sdks like stackexchange redis, service stack etc.
.NET is my preferred platform.
Can these client sdks be used to interact with redis on elasticache?
Anyone know about some documentation and/or code examples using elasticache redis (with the stackexchange redis sdk)?
Im guessing I will have to authenticate using a key / secret pair, is this supported in any of these client sdks?
thanks in advance!
Lars
Elasticache is connected to the same way you connect to any other Redis instance. Once you create a new Elasticache instance, you'll be given the hostname to connect to. No need for secret/key pair. All access to the Redis instance there is configured through security groups just like with other AWS instances in EC2, RDS, etc...
With that said, there are two important caveats:
You will only be able to connect to elasticache from within the region and/or VPC in which it's launched, even if you open up the security group to outside IPs (for me, this is one of the biggest reasons not to use Elasticache).
You cannot set a password on your Redis instance. Anyone on a box that is given access to the instance in security groups (keeping in mind the limitations from caveat 1) will be able to get access to your Redis instance with full rights to add/delete/modify whatever keys they like. This is the other big reason not to use Elasticache, though it certainly still has use-cases where these drawbacks are less important.
I am developing a MVC4 application . We have hosted our application on Windows Azure IAAS Model . Right now we have configured 2 virtual machines and everything is working good. But we have an issue with maintaining User Loging .
If i login in virtual machine 1 , its not getting carried over ,when the next request is coming from Virtual machine 2 . We have mapped two virtual machines over load balance .
Should i look into Cache solutions . Any input will be greatly helpful ...
Thanks,
Jaswanth
You're hitting two completely separate VMs (yes load balanced, but separate). This mandates the need for storing any type of session data external to the VMs (or you need to sync the session content and have it identical in both VMs).
Azure doesn't do anything to sync session data for you. That's on you, to build it into your app's architecture. You mentioned caching, which is certainly a viable solution (which you pick, though, is up to you). There are other solutions too such as database-based session storage. Again, that's up to you.
But bottom line: If you're going to scale an app beyond a single server (VM in this case), in a load-balanced way, you cannot store session data in a specific vm.
Use a durable session state store (like Redis or SQL Server, etc) or put your state in a cookie and read/write it on each request. If cookie includes sensitive content, encrypt it.