RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1114809 - RFE: Centralise authentication of RHEL-HA (pacemaker)
Summary: RFE: Centralise authentication of RHEL-HA (pacemaker)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Chris Feist
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1158571
Blocks: 1205796
TreeView+ depends on / blocked
 
Reported: 2014-07-01 04:24 UTC by Anand Vaddarapu
Modified: 2023-09-14 02:10 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-05 22:13:45 UTC
Target Upstream Version:
Embargoed:
sauchter: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1158571 0 high CLOSED user and group support in gui - permissions to clusters managed by pcsd 2021-02-22 00:41:40 UTC

Internal Links: 1158571

Description Anand Vaddarapu 2014-07-01 04:24:05 UTC
Description of problem:
In a global organisations with possibly 1000s of clusters it is naive to assume there is enough manpower to define and manage cluster specific ACLs.

Pacemaker UI must be developed to use LDAP or AD to define ACLs centrally. Financial organisations in particular must demonstrate an audit trail of creation, access, privilege escalation, password lifecycle and deletion of a user id. The ability to do his centrally is the only practical way.

Comment 3 Andrew Beekhof 2014-07-01 23:28:30 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?

Comment 5 Andrew Beekhof 2014-07-11 02:43:40 UTC
(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.

Comment 10 Andrew Beekhof 2014-10-23 03:42:59 UTC
Moving this to pcs since the remaining concern is about the GUI

Comment 12 Chris Feist 2015-07-07 19:15:37 UTC
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).

Comment 13 Christoph 2015-08-12 07:40:00 UTC
@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?

Comment 14 Chris Feist 2015-08-12 19:21:05 UTC
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

Comment 22 Ken Gaillot 2016-02-25 22:46:47 UTC
(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

Comment 26 Red Hat Bugzilla 2023-09-14 02:10:50 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.