[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] How can I prevent condor_status to provide info onthe pool PCs?
- Date: Sat, 21 Feb 2009 13:17:35 +0530
- From: Sateesh Potturu <sateeshpnv@xxxxxxxxx>
- Subject: Re: [Condor-users] How can I prevent condor_status to provide info onthe pool PCs?
Host-based (HOSTALLOW_*) security won't satisfy your need. Other methods are not easy.
You can start by going through:
1. http://www.oliba.uab.es/CondorWeek2008/slides/Wednesday/16_00_zmiller_security_tutorial.ppt and then
2. section 3.6 in condor manual
Setting up encryption and integrity is easy. Setting up GSI/SSL/Kerberos authentication is OK. Setting up authorizations is involved.
On Sat, Feb 21, 2009 at 9:51 AM, Steven Timm <timm@xxxxxxxx>
hOn Fri, 20 Feb 2009, Rob wrote:Probably, but it will take some kind of authentication within the pool,
> Ian Chesal wrote:
>> Don't put condor_status on the machines. You'll want it to be available
>> from a network location for debugging purposes but you don't need to
>> putit on the machines running jobs.
> This is a rather insecure solution. An evil person at a public library PC
> may reinstall the condor_status executable and query the pool of PCs....
> I was looking for a solution, which configures the central manager such that
> it permits condor status queries *ONLY* to by the central manager itself.
> I thought the HOSTALLOW_READ macro in the central manager's
> config file would control this; but that does not seem to work.
> Hence, is there then no way to configure the central manager in such
> a way that it does not give the full pool information to all the pool PCs?
for instance, by restricting CLIENT and READ access to only those
who have possession of some kerberos or SSL certificate.
A tricky business and there's no good documentation I have
ever found as to which activity is which authentication level.
(ADMINISTRATOR, OWNER, WRITE, READ, CLIENT, DAEMON
and I think there is one other one).
In general you have to let the condor daemons in the pool have
not only read but write to the collector, but that does not
necessarily mean that all users on the machine need have the
Steven C. Timm, Ph.D (630) 840-8525
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.