Mailing-List: contact user-help@ignite.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@ignite.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CADRng7ZviDE6+ZJPEXi52hV+BhTc2Ly94pjWw4_OurEYNjjtwQ@mail.gmail.com>
References: 
 <CADRng7ZviDE6+ZJPEXi52hV+BhTc2Ly94pjWw4_OurEYNjjtwQ@mail.gmail.com>
From: Ognen Duzlevski <ognen.duzlevski@gmail.com>
Date: Thu, 30 Jul 2015 11:17:43 -0500
Message-ID: 
 <CAPzt5W5hnF6O5L_R3oABmPb1JwksvKjASttWWAG1m5nUxf8s3Q@mail.gmail.com>
Subject: Re: Securing Ignite
To: user@ignite.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11348f306cd9e0051c1a0d7c

--001a11348f306cd9e0051c1a0d7c
Content-Type: text/plain; charset=UTF-8

Aleksei, VPC is by default private, no? You can always have a separate
subnet within the VPC that you deploy all your on-demand Ignite nodes into,
together with your "always on" node - combined with some simple iptables
rules, this should be sufficient. You can expose the functionality of your
cluster via REST API where you can control access to the whole thing
(submitting jobs, asking for data etc.) via passwords, shared secrets,
public/private keys etc. The exposed REST point can be a separate machine
or set of machines running something like Scalatra (with/without Akka) that
is not in the same subnet but is allowed to connect to the Ignite subnet as
a client - you can make this node have a static IP (or you can have a
different subnet where this node is that is only allowed to connect to the
Ignite subnet) and only allow it to connect to your cluster...

On Thu, Jul 30, 2015 at 9:37 AM, Aleksei Valikov <aleksei.valikov@gmail.com>
wrote:

> Hi,
>
> I'm considering Apache Ignite for a distributed computing application. I
> have a question about security.
>
> We'll have a central node which will run all the time (the application
> server) and a number of nodes which will join/leave the cluster in the
> runtime (we'll use AWS to add new computing resources on demand). I guess
> we'll need to use the static IP-based discovery for this scenario.
>
> As I read the configuration right now, any server in my VPC which knows
> the IP address of the central node will be able to connect to the Ignite
> cluster and accept tasks/jobs. This feels quite insecure - basically anyone
> in VPC would be able to get the data from the tasks/jobs.
>
> How could I make it secure?
>
> I've found the following post:
>
> http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/
>
> This is a step into the right direction. However, whitelisting IPs is not
> an option in case of dynamic IP addresses (which we probably have in AWS).
>
> So I'd like to ask for advice on how to secure the Ignite cluster, for
> instance with some pre-shared secret. Is there any support for this OOTB?
>
> Many thanks and best wishes,
> Alexey
>

--001a11348f306cd9e0051c1a0d7c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Aleksei, VPC is by default private, no? You can always hav=
e a separate subnet within the VPC that you deploy all your on-demand Ignit=
e nodes into, together with your &quot;always on&quot; node - combined with=
 some simple iptables rules, this should be sufficient. You can expose the =
functionality of your cluster via REST API where you can control access to =
the whole thing (submitting jobs, asking for data etc.) via passwords, shar=
ed secrets, public/private keys etc. The exposed REST point can be a separa=
te machine or set of machines running something like Scalatra (with/without=
 Akka) that is not in the same subnet but is allowed to connect to the Igni=
te subnet as a client - you can make this node have a static IP (or you can=
 have a different subnet where this node is that is only allowed to connect=
 to the Ignite subnet) and only allow it to connect to your cluster...</div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 30, =
2015 at 9:37 AM, Aleksei Valikov <span dir=3D"ltr">&lt;<a href=3D"mailto:al=
eksei.valikov@gmail.com" target=3D"_blank">aleksei.valikov@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div>=
<br></div><div>I&#39;m considering Apache Ignite for a distributed computin=
g application. I have a question about security.</div><div><br></div><div>W=
e&#39;ll have a central node which will run all the time (the application s=
erver) and a number of nodes which will join/leave the cluster in the runti=
me (we&#39;ll use AWS to add new computing resources on demand). I guess we=
&#39;ll need to use the static IP-based discovery for this scenario.</div><=
div><br></div><div>As I read the configuration right now, any server in my =
VPC which knows the IP address of the central node will be able to connect =
to the Ignite cluster and accept tasks/jobs. This feels quite insecure - ba=
sically anyone in VPC would be able to get the data from the tasks/jobs.</d=
iv><div><br></div><div>How could I make it secure?</div><div><br></div><div=
>I&#39;ve found the following post:</div><div><br></div><div><a href=3D"htt=
p://smartkey.co.uk/development/securing-an-apache-ignite-cluster/" target=
=3D"_blank">http://smartkey.co.uk/development/securing-an-apache-ignite-clu=
ster/</a><br></div><div><br></div><div>This is a step into the right direct=
ion. However, whitelisting IPs is not an option in case of dynamic IP addre=
sses (which we probably have in AWS).</div><div><br></div><div>So I&#39;d l=
ike to ask for advice on how to secure the Ignite cluster, for instance wit=
h some pre-shared secret. Is there any support for this OOTB?</div><div><br=
></div><div>Many thanks and best wishes,</div><div>Alexey</div></div>
</blockquote></div><br></div>

--001a11348f306cd9e0051c1a0d7c--