Client->Foreman communication should be moved to Proxy

Hi,

When provisioning a machine, the client needs to access foreman unattended
urls, such as: http://foreman/unattended/kickstart
and
http://foreman/unattended/built

That means firewall open to foreman (and the API).
I think the architecture and security would improve if Foreman could be as
isolated as possible, not depending on being open to the machines it
manages… Those tasks should be left to the proxy.

The suggested solution:
Client communications directed to Foreman should me moved to proxy (in this
case, the one running on the master) so you only need port 8140
(puppetmaster) + 8443 (foreman-proxy) open.

Any thoughts on this ?

Cheers,
Marcello

I still believe the client should not talk to Foreman directly and would
like to open a feature request to make the proxy take care of the
"unattended".

Anyone comments ?

··· --- Marcello

-----Original Message-----
From: foreman-users@googlegroups.com [mailto:foreman-users@googlegroups.com]
On Behalf Of Marcello de Sousa
Sent: dinsdag 24 mei 2011 22:08
To: foreman-users@googlegroups.com
Subject: [foreman-users] Client->Foreman communication should be moved to
Proxy

Hi,

When provisioning a machine, the client needs to access foreman unattended
urls, such as: http://foreman/unattended/kickstart
and
http://foreman/unattended/built

That means firewall open to foreman (and the API).
I think the architecture and security would improve if Foreman could be as
isolated as possible, not depending on being open to the machines it
manages… Those tasks should be left to the proxy.

The suggested solution:
Client communications directed to Foreman should me moved to proxy (in this
case, the one running on the master) so you only need port 8140
(puppetmaster) + 8443 (foreman-proxy) open.

Any thoughts on this ?

Cheers,
Marcello


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

> I still believe the client should not talk to Foreman directly and would
> like to open a feature request to make the proxy take care of the
> "unattended".
>
> Anyone comments ?
>

Since you need to trust something, does it really matter if your proxy
trusts its client of if its foreman?

I realize there is a bit of confusion around foreman proxy concept, in our
case, a proxy is an extension of foreman, in order to perform tasks on
remote machines (such as your puppet server).

maybe I'm missing the point, but in this case, the proxy will accept
connections from any ip, and simply forward the request as is to foreman…
if thats correct, whats the security benefit?

additionally, if the proxy handle unattended, does it mean you create the
host via the proxy too?
Ohad

··· On Thu, Jun 9, 2011 at 10:52 AM, Marcello de Sousa wrote:

Marcello

-----Original Message-----
From: foreman-users@googlegroups.com [mailto:
foreman-users@googlegroups.com]
On Behalf Of Marcello de Sousa
Sent: dinsdag 24 mei 2011 22:08
To: foreman-users@googlegroups.com
Subject: [foreman-users] Client->Foreman communication should be moved to
Proxy

Hi,

When provisioning a machine, the client needs to access foreman unattended
urls, such as: http://foreman/unattended/kickstart
and
http://foreman/unattended/built

That means firewall open to foreman (and the API).
I think the architecture and security would improve if Foreman could be as
isolated as possible, not depending on being open to the machines it
manages… Those tasks should be left to the proxy.

The suggested solution:
Client communications directed to Foreman should me moved to proxy (in this
case, the one running on the master) so you only need port 8140
(puppetmaster) + 8443 (foreman-proxy) open.

Any thoughts on this ?

Cheers,
Marcello


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

On Behalf Of Ohad Levy

··· From: foreman-users@googlegroups.com [mailto:foreman-users@googlegroups.com] Sent: donderdag 9 juni 2011 9:55 To: foreman-users@googlegroups.com Subject: Re: [foreman-users] Client->Foreman communication should be moved to Proxy


I’ve tried to draw what I’m trying to achieve.

At first you have to open your firewall to foreman exposing its api to all
client machines. I don’t really believe this is necessary.

On the second drawing I have standard fw configuration on both datacenters
and no communication needs to be initiated from all remote clients to a
local foreman. Only the Proxy API is exposed. This feels much more clean,
secure and scalable.

The proxy doesn’t really need to simply forward the request. It could have
some intelligence to validate them or serve the unattended itself (by
storing the template information locally).

Cheers,

Marcello

On Thu, Jun 9, 2011 at 10:52 AM, Marcello de Sousa < mailto:lists@area151.com lists@area151.com> wrote:

I still believe the client should not talk to Foreman directly and would
like to open a feature request to make the proxy take care of the
“unattended”.

Anyone comments ?

Since you need to trust something, does it really matter if your proxy
trusts its client of if its foreman?

I realize there is a bit of confusion around foreman proxy concept, in our
case, a proxy is an extension of foreman, in order to perform tasks on
remote machines (such as your puppet server).

maybe I’m missing the point, but in this case, the proxy will accept
connections from any ip, and simply forward the request as is to foreman…
if thats correct, whats the security benefit?

additionally, if the proxy handle unattended, does it mean you create the
host via the proxy too?

Ohad


Marcello

-----Original Message-----
From: foreman-users@googlegroups.com [mailto:foreman-users@googlegroups.com]
On Behalf Of Marcello de Sousa
Sent: dinsdag 24 mei 2011 22:08
To: foreman-users@googlegroups.com
Subject: [foreman-users] Client->Foreman communication should be moved to
Proxy

Hi,

When provisioning a machine, the client needs to access foreman unattended
urls, such as: http://foreman/unattended/kickstart
and
http://foreman/unattended/built

That means firewall open to foreman (and the API).
I think the architecture and security would improve if Foreman could be as
isolated as possible, not depending on being open to the machines it
manages… Those tasks should be left to the proxy.

The suggested solution:
Client communications directed to Foreman should me moved to proxy (in this
case, the one running on the master) so you only need port 8140
(puppetmaster) + 8443 (foreman-proxy) open.

Any thoughts on this ?

Cheers,
Marcello


You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com
mailto:foreman-users%2Bunsubscribe@googlegroups.com .
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.


You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com
mailto:foreman-users%2Bunsubscribe@googlegroups.com .
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.


You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

>
>
>
>
> From: foreman-users@googlegroups.com [mailto:
> foreman-users@googlegroups.com] *On Behalf Of *Ohad Levy
> Sent: donderdag 9 juni 2011 9:55
>
> To: foreman-users@googlegroups.com
> Subject: Re: [foreman-users] Client->Foreman communication should be
> moved to Proxy
>
>
>
> http://i.imgur.com/aJlN5.png
>
> I’ve tried to draw what I’m trying to achieve.
>
> At first you have to open your firewall to foreman exposing its api to all
> client machines. I don’t really believe this is necessary.
>
but if you enable authentication, then it would be rejected without a valid
user/password.
at the moment, there is a very small set of operations that do not require
authentication (such as requesting a kickstart - which goes though another
set of validiting the requesting ip address vs build state etc).

On the second drawing I have standard fw configuration on both datacenters
> and no communication needs to be initiated from all remote clients to a
> local foreman. Only the Proxy API is exposed. This feels much more clean,
> secure and scalable.
>
So what you want to do is simply block all client traffic communication to
foreman…
what if you are using foreman and puppet without a master? the clients still
need to communicate with foreman…

> The proxy doesn’t really need to simply forward the request. It could have
> some intelligence to validate them or serve the unattended itself (by
> storing the template information locally)…
>
Providing the templates complicates the proxy alot, how would you validate
the requests on the proxy?

Ohad

··· On Thu, Jun 9, 2011 at 11:44 AM, Marcello de Sousa wrote:

Cheers,

Marcello

On Thu, Jun 9, 2011 at 10:52 AM, Marcello de Sousa lists@area151.com > wrote:

I still believe the client should not talk to Foreman directly and would
like to open a feature request to make the proxy take care of the
"unattended".

Anyone comments ?

Since you need to trust something, does it really matter if your proxy
trusts its client of if its foreman?

I realize there is a bit of confusion around foreman proxy concept, in our
case, a proxy is an extension of foreman, in order to perform tasks on
remote machines (such as your puppet server).

maybe I’m missing the point, but in this case, the proxy will accept
connections from any ip, and simply forward the request as is to foreman…
if thats correct, whats the security benefit?

additionally, if the proxy handle unattended, does it mean you create the
host via the proxy too?

Ohad


Marcello

-----Original Message-----
From: foreman-users@googlegroups.com [mailto:
foreman-users@googlegroups.com]
On Behalf Of Marcello de Sousa
Sent: dinsdag 24 mei 2011 22:08
To: foreman-users@googlegroups.com
Subject: [foreman-users] Client->Foreman communication should be moved to
Proxy

Hi,

When provisioning a machine, the client needs to access foreman unattended
urls, such as: http://foreman/unattended/kickstart
and
http://foreman/unattended/built

That means firewall open to foreman (and the API).
I think the architecture and security would improve if Foreman could be as
isolated as possible, not depending on being open to the machines it
manages… Those tasks should be left to the proxy.

The suggested solution:
Client communications directed to Foreman should me moved to proxy (in this
case, the one running on the master) so you only need port 8140
(puppetmaster) + 8443 (foreman-proxy) open.

Any thoughts on this ?

Cheers,
Marcello


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.