Bug 1114809
| Summary: | RFE: Centralise authentication of RHEL-HA (pacemaker) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Anand Vaddarapu <avaddara> |
| Component: | pcs | Assignee: | Chris Feist <cfeist> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | cluster-qe <cluster-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | byodlows, cfeist, c.handel, cluster-maint, fdinitto, jruemker, jscalf, kgaillot, rsteiger, sauchter, tojeline |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | Flags: | sauchter:
needinfo-
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-05 22:13:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1158571 | ||
| Bug Blocks: | 1205796 | ||
|
Description
Anand Vaddarapu
2014-07-01 04:24:05 UTC
While there are obviously challenges associated with managing 1000's of clusters, Pacemaker - doesn't store any passwords - offloads authentication to the GUI in most use-cases - uses PAM, which I believe can be configured to use LDAP/AD, when authentication is needed so the challenges listed in the second paragraph are not among them. We need much more information about the intended use case here before we can make recommendations or consider new features: - is access to be primarily via the GUI or CLI? - are the 1000's of clusters in a single admin domain? - are there groups of users with common privilege sets, or are they all unique? - if there are common sets, how many? 10? 100? 1000? - is access 'all-or-nothing' or will some users only have access to edit or control specific resources? (In reply to Stuart Auchterlonie from comment #4) > - offloads authentication to the GUI in most use-cases > > What other authentication use-cases are you considering? None. It was only an observation that most less-privileged admin interaction with the cluster is likely to be via the GUI which takes care of the authentication for us. Even when the CLI is used on a cluster node, we rely on the authentication already performed by the OS to let the user in. The only time pacemaker is involved in authentication is when people initiate remote connections directly to the CIB (ie. by an alternate GUI) which is so far unsupported. > > - uses PAM, which I believe can be configured to use LDAP/AD, when > authentication is needed > > Login control through AD/LDAP via PAM is good, but it seems we need more > detail. We get username/password details via a handshake protocol, pass it to PAM, PAM gives us a "yes or no". I don't have any further details on how PAM works internally but as mentioned above, this particular feature is not part of a common workflow. > > Is access to be primarily via the GUI or CLI? > > What difference would it make? Quite a lot. If using the CLI, the fact that they are logged in tells us who they authenticated as. Since the GUI is a website, it obviously cannot do this and must do authentication itself. > Control of user/password > admin through a CLI/API would allow remote management of access. > > - are the 1000's of clusters in a single admin domain? > > Admin domains would be split between lines of business (lob),say <100. > > - are there groups of users with common privilege sets, or are they all > unique? > > There would *not* be general, read only access. There would be a fully > privileged admin id per lob domain and a read only id for gathering > information per lob. Ok, so we're talking about 1 extra 'account' per LOB (aka. < 100 to manage in across the 1000+ clusters). CC'ing Chris for feedback on how this would work from a pcs perspective. > If CLI access was ssh based then using public/private > key authentication would allow management of those ids by a third without a > need to manage the third ids password. Pacemaker doesn't get involved with how the user gets on to the machine to use the CLI. They can continue using whatever provisioning methods they have already. Moving this to pcs since the remaining concern is about the GUI Bumping this to 7.3, We are currently implementing user and group support (through PAM authentication) in bug 1158571. But this bug encompasses more issues (including auditing). @Chris Feist does this mean it is possible to use pam-groups as roles in pacemaker? And users which pam believes are in these groups automaticly have the corresponding roles in pacemaker? If yes, can i get acces to #1158571 to subscribe me? Bug 1158571 (which you should now be able to view), is for setting permissions for various cluster actions (like stop/start nodes, etc.). I believe you can already use pam groups in pacemaker ACLs to controller who can view/change certain items (resource settings, etc.). If you have issues on your systems using groups lets us know by filing a bug so we can track that issue. Thanks, Chris (In reply to Chris Feist from comment #14) > I believe you can already use pam groups in pacemaker ACLs to controller who > can view/change certain items (resource settings, etc.). If you have issues > on your systems using groups lets us know by filing a bug so we can track > that issue. This is a planned but not yet implemented feature: see #1253191 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |