Matt Garman
2015-Jun-04 18:29 UTC
[CentOS] managing logins for different classes of servers
Our environment has several "classes" of servers, such as "development", "production", "qa", "utility", etc. Then we have all our users. There's no obvious mapping between users and server class. Some users may have access to only one class, some may span multiple classes, etc. And for maximum complexity, some classes of machines use local (i.e. /etc/passwd, /etc/shadow) authentication, others use Kerberos. With enough users and enough classes, it gets to be more than one can easily manage with a simple spreadsheet or other crude mechanism. Plus the ever-growing risk of giving a user access to a class he shouldn't have. Is there a simple centralized solution that can simplify the management of this? One caveat though is that our "production" class machines should not have any external dependencies. These are business-critical, so we try to minimize any single point of failure (e.g. a central server). Plus the production class machines are distributed in multiple remote locations. Any thoughts?
m.roth at 5-cent.us
2015-Jun-04 19:34 UTC
[CentOS] managing logins for different classes of servers
Matt Garman wrote:> Our environment has several "classes" of servers, such as > "development", "production", "qa", "utility", etc. Then we have all > our users. There's no obvious mapping between users and server class. > Some users may have access to only one class, some may span multiple > classes, etc. And for maximum complexity, some classes of machines > use local (i.e. /etc/passwd, /etc/shadow) authentication, others use > Kerberos. > > With enough users and enough classes, it gets to be more than one can > easily manage with a simple spreadsheet or other crude mechanism. > Plus the ever-growing risk of giving a user access to a class he > shouldn't have. > > Is there a simple centralized solution that can simplify the > management of this? One caveat though is that our "production" class > machines should not have any external dependencies. These are > business-critical, so we try to minimize any single point of failure > (e.g. a central server). Plus the production class machines are > distributed in multiple remote locations. > > Any thoughts?I agree completely with your manager: nobody but the production admins, and the "system owners", should be allowed on the machine, unless you want to allow selected sr. people to be able to get on in the event that something that's just gone into production has just broken, to see if it can be a quick fix, or whether you need to roll it back. Likewise, neither developers nor "ordinary users" should be allowed on the q/a systems, which ought to be clones of production, with the exceptions of the new releases. I'm not sure whether "ordinary users" should be allowed on dev systems, unless they need to look in on what's going on. In a true professional environment, only the admins get to move things to prod; dev can promote in the VCS, and the testers can bring that in, then promote so that the admins can roll that out during a prearranged maintenance window. All of this is easily done. We have the organization-wide AD (sigh), which authenticates, and allows single sign-on, single password. Then there's authorization.... We have a large /etc/password, but if you're not allowed on, your shell is /bin/noLogin. <g> mark
Binet, Valere (NIH/NIA/IRP) [C]
2015-Jun-04 20:28 UTC
[CentOS] managing logins for different classes of servers
We use group membership and ?AllowGroups? in /etc/ssh/sshd_config We define which group(s) can go on which machines in our puppet manifest and let puppet enforce the ssh_config content accordingly. For the machines not connecting to our LDAP server for authorization, we tell puppet which users to create on which machines. It?s still complex but at least we don?t rely on manual config based on an excel sheet. Val?re Binet [C] IT Security Administrator Kelly Government Solutions On-Site at the NIH NIH / NIA / IRP Tel : 410 558 8013 mailto: binetv at nia.nih.gov NCTS performance comments and survey at: https://niairpkiosk.irp.nia.nih.gov/content/ncts-user-survey On 6/4/15, 3:34 PM, "m.roth at 5-cent.us" <m.roth at 5-cent.us> wrote:>Matt Garman wrote: >> Our environment has several "classes" of servers, such as >> "development", "production", "qa", "utility", etc. Then we have all >> our users. There's no obvious mapping between users and server class. >> Some users may have access to only one class, some may span multiple >> classes, etc. And for maximum complexity, some classes of machines >> use local (i.e. /etc/passwd, /etc/shadow) authentication, others use >> Kerberos. >> >> With enough users and enough classes, it gets to be more than one can >> easily manage with a simple spreadsheet or other crude mechanism. >> Plus the ever-growing risk of giving a user access to a class he >> shouldn't have. >> >> Is there a simple centralized solution that can simplify the >> management of this? One caveat though is that our "production" class >> machines should not have any external dependencies. These are >> business-critical, so we try to minimize any single point of failure >> (e.g. a central server). Plus the production class machines are >> distributed in multiple remote locations. >> >> Any thoughts? > >I agree completely with your manager: nobody but the production admins, >and the "system owners", should be allowed on the machine, unless you want >to allow selected sr. people to be able to get on in the event that >something that's just gone into production has just broken, to see if it >can be a quick fix, or whether you need to roll it back. > >Likewise, neither developers nor "ordinary users" should be allowed on the >q/a systems, which ought to be clones of production, with the exceptions >of the new releases. > >I'm not sure whether "ordinary users" should be allowed on dev systems, >unless they need to look in on what's going on. > >In a true professional environment, only the admins get to move things to >prod; dev can promote in the VCS, and the testers can bring that in, then >promote so that the admins can roll that out during a prearranged >maintenance window. > >All of this is easily done. We have the organization-wide AD (sigh), which >authenticates, and allows single sign-on, single password. Then there's >authorization.... We have a large /etc/password, but if you're not allowed >on, your shell is /bin/noLogin. <g> > > mark > >_______________________________________________ >CentOS mailing list >CentOS at centos.org >http://lists.centos.org/mailman/listinfo/centos
Maybe Matching Threads
- managing logins for different classes of servers
- nfs (or tcp or scheduler) changes between centos 5 and 6?
- Managing bigger scripts
- [LLVMdev] Infinite loop in llc on ARMv7 (LLVM HEAD from June 17)
- [LLVMdev] Infinite loop in llc on ARMv7 (LLVM HEAD from June 17)