[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Condor-users] Condor Security
- Date: Wed, 7 Sep 2005 08:19:26 -0600
- From: "Cox, James A (TRAC)" <james.cox12@xxxxxxxxxxx>
- Subject: RE: [Condor-users] Condor Security
FWIW - we have "submit only" boxes that users must ssh into to submit jobs.
You can control who is allowed to ssh into those boxes fairly easily.
[mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Matt Hope
Sent: Wednesday, September 07, 2005 8:09 AM
To: Condor-Users Mail List
Subject: Re: [Condor-users] Condor Security
On 9/7/05, Baker D.J. <D.J.Baker@xxxxxxxxxxx> wrote:
> We have set up a fairy large Windows Condor pool, and now we would
> like to introduce some form of security in the pool. At the moment there
> is nothing stopping any user on the campus from installing condor on
> their machine, joining the pool and submitting jobs into the pool. We
> would like to be able to restrict access to the pool, and if possible
> only allow access following a request from the user.
> The pool comprises machines from a large number of departments. I've
> thought of implementing host based security, however this is complex to
> set up due the diverse mix of machines. We hoped to be able to define a
> list of machines with write permission -- worker nodes, and submission
> machines, however as I say while this is possible it is very complicated
> to implement.
> Could someone please advise us regarding how best to secure our pool. If
> possible we would like to be able to grant user/machine access as per
> requests, and restrict access otherwise. How best can we implement such
> a schema, please? Any advice would be welcomed.
Really hacky but I think should work for per machine blocking.
Place firewall between the negotiator/collector machine, you then
block their ports.
You then have to manually allow the execute and schedd machines
(though adding a machine as one implicitly adds it as another.
Like I said hacky but in your complete control.
per user blocking is rather more tricky. traditionally within condor
that is done on a per execute machine basis (i.e. via the START
expression for the startd...
If you control (completely) the execute machines you can set this
yourself (having them share an identical or deployed config file and
altering that then sending a condor_reconfig signal will do the
Condor-users mailing list