I'm setting up a cloud service on azure and want to buffer logs in redis. However running redis as a web service on azure means my requests have to leave my virtual network, which means encryption is a must.
I've searched for hours but haven't found any clues whether logstash can read from redis via ssl. Isn't that possible at all?
Seems like redis isn't able to talk ssl and the redis web service of azure seems to come with custom ssl support, which seems to be the reason why there is no ssl support for the redis input.
However this solution (stunnel) helped me solving my problem: http://bencane.com/2014/02/18/sending-redis-traffic-through-an-ssl-tunnel-with-stunnel/
Related
Maybe this is a dumb question, but I really don't know if I have to secure applications with tokens etc. within a kubernetes cluster.
So for example I make a grpc-call from a client within the cluster to a server within the cluster.
I thought this should be secure without authenticating the client with a token or something like that, because (if I understood it right) kubernetes pods and services work within a VPN which won't be exposed as long as it's not told to.
But is this really secure, should I somehow build an authorization system within my cluster?
Also how can I use a service to load balance the grpc-calls over the server pods without exposing the server outside the cluster?
If you have a service, it already has built-in load balancer when you have more than one replica out of the box.
Also Kubernetes traffic is internal within the cluster out of the box, unless you explicitly expose traffic using LoadBalancer, Ingress or NodePort.
Does it mean traffic is safe? No.
By default, everything is allowed within Kubernetes cluster so every service can reach every service or pod in StatefulSet apps.
You can use NetworkPolicy to allow traffic from one service to another service and nothing else. That would increase security.
Does it mean traffic is safe now? It depends.
Authentication would add an additional security layer in case container is hacked. There could be more scenarios, but I can't think of for now.
So internal authentication is usually used to improve security in production systems.
I hope it answers the question.
Our web and mobile application suite is used by some government agencies requiring strong security. We're providing XMPP-based chat. We used Openfire as XMPP server, but it turned out Openfire clustering (provided by Hazelcast plugin) does not allow Openfire nodes to communicate over SSL. We're not allowed to use node-to-node communications without SSL.
So, we're currently looking at Ejabberd XMPP server as a (more scalable) alternative to Openfire. But it looks like Ejabberd cluster nodes also communicate without SSL. Is it possible to set up Ejabberd cluster with nodes using SSL to talk to each other?
There is two ways to enable clustering over TLS with ejabberd:
You can set Erlang distribution over TLS: http://erlang.org/doc/apps/ssl/ssl_distribution.html
You can use VPN to protect your cluster.
Typically, the second solution is best for performance, as you offload the SSL processing from your cluster to a lower level layer. Clustering in ejabberd is not intended to be set over the internet, as you need low latency between your node for optimal operation.
I am trying to get more documentation, understanding about security in Azure Managed Kubernetes Service (AKS).
Does Azure encrypt the containers deployed to the AKS cluster at "rest"? If so, how is data encryption achieved at rest, and in motion?
What are the ways to achieve SSL/TLS in AKS, any documentation is appreciated.
Thanks in advance
I can definitely tell you TLS termination is supported in AKS. I've been able to implement this.
HTTPS Ingress on Azure Kubernetes Service (AKS)
This documentation is slightly out of date though. You should use cert-manager instead of KUBE-LEGO.
I would welcome a more authoritative answer, but as far as I have determined managed disks are always encrypted (https://azure.microsoft.com/en-us/blog/azure-managed-disks-sse/), but the worker nodes are not encrypted by default. It would be necessary to run az vm encryption enable on every node (quite a chore if you are scaling up and down!). If you do that you should be covered, though.
As for SSL/TLS Kubernetes supports TLS for Ingress, see https://kubernetes.io/docs/concepts/services-networking/ingress, but I haven't tested it in AKS. We are using our own Nginx server as gateway and with that approach you can use any TLS tutorial out there. We feel that we have more control that way.
In a scenario where there are thousands of webservices are there reasons to use also a signed cert for each microservice or it's just going to add overhead? Services communicate via VPC sitting behind a firewall while Public endpoints are behind a nginx public facing a valid CA cert.
Services are on multiple servers on aws.
From my limited experience, I believe that it is overkill. If an attacker has access to listen in or interact with your internal network then there are most likely other issues which you should be contending with.
This article on auth0.com explains the use of SSL only on connections to the external client. I also share this view and believe implementing SSL at an individual service level would get extremely difficult unless you where running some form of proxy such as HAProxy or Nginx on each individual host which is sub-optimal, especially if you're using a form of managed cluster like Kubernetes or Docker Swarm.
My current thoughts are its fine to run SSL just for your edge services, ensure you lock down your AWS network using something like Scout2 and run unencrypted for inter-service communication on your lan.
unless all intranet in the cloud are fully VLAN-configured and isolated, is it possible for other hosts that you don't own that are on the same LAN to steal your password by running a simple tcpdump? if that's the case, we need ssl or other encryption internally on the cloud too.
A Zookeeper architecture question for you ZK Gurus:
I use zookeeper to manage messaging to a cloud of worker machines. Currently the application servers that control the messages and the workers are in the same infrastructure (network). I'm considering allowing clients to communicate with these servers outside of the network from arbitrary locations. I've read about Zookeepers ACL and Authentication Capabilities but I notice that digest sends the passwords in cleartext. I'd be concerned about securing the socket connection and protecting against outside attacks. I dont see anything online telling me that this IS/IS NOT something that can/should be done with Zookeeper.
Is this a common architecture with Zookeeper and are there any suggestions?
Am I barking up the wrong tree for this type of work?
if you do not have a secured network (VPN), this in not something you should do for exactly the reason pointed out. you can mitigate the problem quite a bit using the kerberos plug in, which will secure the authentication and authorization, but you still will not get confidentiality (encryption). what you really need is SSL. things are setup now so that SSL support could be implemented, but code still needs to be written :)