Proposal - encrypted cache
by Sebastian Laskawiec
Hey!
A while ago I stumbled upon [1]. The article talks about encrypting data
before they reach the server, so that the server doesn't know how to
decrypt it. This makes the data more secure.
The idea is definitely not new and I have been asked about something
similar several times during local JUGs meetups (in my area there are lots
of payments organizations who might be interested in this).
Of course, this can be easily done inside an app, so that it encrypts the
data and passes a byte array to the Hot Rod Client. I'm just thinking about
making it a bit easier and adding a default encryption/decryption mechanism
to the Hot Rod client.
What do you think? Does it make sense?
Thanks
Sebastian
[1] https://eprint.iacr.org/2016/920.pdf
6 years, 6 months
Hot Rod secured by default
by Tristan Tarrant
Dear all,
after a mini chat on IRC, I wanted to bring this to everybody's attention.
We should make the Hot Rod endpoint require authentication in the
out-of-the-box configuration.
The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
mechanism against the ApplicationRealm and require users to run the
add-user script.
This would achieve two goals:
- secure out-of-the-box configuration, which is always a good idea
- access to the "protected" schema and script caches which is prevented
when not on loopback on non-authenticated endpoints.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
6 years, 10 months
HotRod client TCK
by Martin Gencur
Hello all,
we have been working on https://issues.jboss.org/browse/ISPN-7120.
Anna has finished the first step from the JIRA - collecting information
about tests in the Java HotRod client test suite (including server
integration tests) and it is now prepared for wider review.
She created a spreadsheet [1]. The spread sheet includes for each Java
test its name, the suggested target package in the TCK, whether to
include it in the TCK or not, and some other notes. The suggested
package also poses grouping for the tests (e.g. tck.query, tck.near,
tck.xsite, ...)
Let me add that right now the goal is not to create a true TCK [2]. The
goal is to make sure that all implementations of the HotRod protocol
have sufficient test coverage and possibly the same server side of the
client-server test (including the server version and configuration).
What are the next step?
* Please review the list (at least a quick look) and see if some of the
tests which are NOT suggested for the TCK should be added or vice versa.
* I suppose the next step would then be to check other implementations
(C#, C++, NodeJS, ..) and identify tests which are missing there (there
will surely be some).
* Gradually implement the missing tests in the other implementations
Note: Here we should ensure that the server is configured in the same
way for all implementations. One way to achieve this (thanks Anna for
suggestion!) is to have a shell/batch scripts for CLI which would be
executed before the tests. This can probably be done for all impls. and
both UNIX/WINDOWS. I also realize that my PR for ISPN [3] becomes
useless because it uses Creaper (Java) and we need a language-neutral
solution for configuring the server.
Some other notes:
* there are some duplicated tests in hotrod-client and server
integration test suites, in this case it probably makes sense to only
include in the TCK the server integration test
* tests from the hotrod-client module which are supposed to be part of
the TCK should be copied to the server integration test suite one day
(possibly later)
Please let us know what you think.
Thanks,
Martin
[1]
https://docs.google.com/spreadsheets/d/1bZBBi5m4oLL4lBTZhdRbIC_EA0giQNDZW...
[2] https://en.wikipedia.org/wiki/Technology_Compatibility_Kit
[3] https://github.com/infinispan/infinispan/pull/5012
7 years, 7 months
to be a command, or not to be a command, that is the question
by Katia Aresti
Hi all,
As you might know I'm working since my arrival, among other things, on
ISPN-5728 Jira [1], where the idea is to override the default ConcurrentMap
methods that are missing in CacheImpl (merge, replaceAll, compute ... )
I've created a pull-request [2] for compute, computeIfAbsent and
computeIfPresent methods, creating two new commands. By the way, I did the
same thing for the merge method in a branch that I haven't pull requested
yet.
There is an opposite view between Radim and Will concerning the
implementation of these methods. To make it short :
In one side Will considers compute/merge best implementation should be as a
new Command (so what is already done)
In the other side, Radim considers adding another command is not necessary
as we could simple implement these methods using ReadWriteKeyCommand
The detailed discussion and arguments of both sides is on GitHub [2]
Before moving forward and making any choice by myself, I would like to hear
your opinions. For the record, it doesn't bother me redoing everything if
most people think like Radim because working on commands has helped me to
learn and understand more about infinispan internals, so this hasn't been a
waste of time for me.
Katia
[1] https://issues.jboss.org/browse/ISPN-5728
[2] https://github.com/infinispan/infinispan/pull/5046
7 years, 7 months
Unwrapping exceptions
by Katia Aresti
Hi all !
Radim pointed me to this thread discussing the exceptions launched by the
lambda executed by the user.
So, I've came accros this problem right now with the compute method.
ComputeIfAbsent is used by the QueryCache [1]
This method is now a Command, so when the wrapped lambda throws an
exception, [2], the expected exception is the one raised by the lambda. But
with my modifications, this exception is wrapped in a CacheException.
I discussed with Adrien yesterday, and IMHO and his, a CacheException is
not the same thing as the exception raised inside the lambda. Moreover, in
this particular case, I don't know if users some code could be broken if we
make the user get a CacheException that wrappes the ParseException instead
of the ParseException itself.
How can I fix the problem ?
Should we correct the tests and say that, from now on, CacheException will
be raised ?
Should we handle this CacheException in the QueryCache class when
computeIfAbsent is called ?
Should we propagate the lambda's exception as it is ?
Katia
[1]
https://github.com/infinispan/infinispan/blob/master/query/src/main/java/...
[2]
https://github.com/infinispan/infinispan/blob/master/query/src/test/java/...
7 years, 8 months
Simplest way to check the validity of connection to Remote Cache
by Ramesh Reddy
Hi,
Is there call I can make on the cache API like ping to check the validity of the remote connection? In OpenShift JDV is having issues with keeping the connections fresh to JDG when node count goes to zero and comes back up.
Thank you.
Ramesh..
7 years, 8 months
TLS/SNI support for Relay protocol
by Sebastian Laskawiec
Hey Bela!
I've been thinking about Cross Site Replication using Relay protocol on
Kubernetes/OpenShift. Most of the installations should use Federation [1]
but I can also imagine a custom installation with two sites (let's call
them X and Y) and totally separate networks. In that case, the flow through
Kubernetes/OpenShift might look like the following:
Site X, Pod 1 (sending relay message) ---> sending packets ---> the
Internet ---> Site Y, Ingress/Route ---> Service ---> Site Y, Pod 1
Ingress/Routes and Services are Kubernetes/OpenShift "things". The former
acts as a reverse proxy and the latter as a load balancer.
Unfortunately Ingress/Routes don't have good support for custom protocols
using TCP (they were designed with HTTP in mind). The only way to make it
work is to use TLS with SNI [2][3]. So we would need to encrypt all traffic
with TLS and use Application FQDN (a fully qualified application name, so
something like this: infinispan-app-2-myproject.*site-x*.com) as SNI
Hostname. Note that FQDN for both sites might be slightly different -
Infinispan on site X might want to use FQDN containing site Y in its name
and vice versa.
I was wondering if it is possible to configure JGroups this way. If not,
are there any plans to do so?
Thanks,
Sebastian
[1] https://kubernetes.io/docs/concepts/cluster-administration/federation/
[2] https://www.ietf.org/rfc/rfc3546.txt
[3] Look for "Passthrough Termination"
https://docs.openshift.com/enterprise/3.2/architecture/core_concepts/rout...
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
7 years, 8 months
