freeIPA provides the ability for user accounts to hold SSH public key information however there are no real controls available to the domain admin or user on the behavior of the keys.
Our use case at my company is that we have staff who have access to dozens of service accounts used by our various applications. These staff need to move files around via scp to directories owned by these accounts. Previous to our IPA deployment the staff had pubkeys hard coded into all their servers for the service accounts they needed to manage. However once we centralized these accounts in IDM the central ssh key capability of IDM was realized to be largely unusable.
For example account app1 would be used in DEV, UAT, CAT and PROD environments however since this was not a local account anymore (it was migrated to IPA) creating a key for dev is now technically usable in higher environments like prod. No sufficient ability to define a context for where that key was valid exists today in IPA. Keys are simply available for use when registered on a user account in the directory.
Our solution (attached) is a script that takes advantage of some of the capability of the authorized_key control mechanisms to provide a simple ACL on a per key basis.
While this works for us, the feeling is that IPA should handle this directly and be able to define policy rules for pubkey context.
Attached is the chat I had with rcritten about this and his suggestion to post the ticket for review:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
{{{#!text gregwork: rcrit: hello gregwork: so I came up with a solution to managing ssh public keys in IPA gregwork: http://fpaste.org/73504/ gregwork: this provides access control on a key level gregwork: for what target hosts that key is valid for gregwork: i did this to fix my problem, but really this feels like it should be better managed by IDM gregwork: (ipa) rcrit: interesting gregwork: otherwise you run into the problems we have where we have one big ipa container for people gregwork: and their access might need to be different rcrit: gregwork, yeah, but users can write their own keys rcrit: so they coudl just update their key w/o this command, right? gregwork: absolutely, this is an opt-in security control rcrit: be an interesting 389-ds plug to add something like this to all keys gregwork: the use case is we have staff who have sudo rights to escalate to dozens of service accounts that exist in IDM gregwork: they need to move files around via scp gregwork: so previous to our IDM deployment they had pubkeys for all the service accounts gregwork: the problem for us came when we centralized the service accounts in IDM gregwork: leveraging the central ssh key capability of IDM became unmanageable gregwork: app1 in prod often had the same id in dev, uat and cat gregwork: code is tested and promoted from lower environments to production gregwork: so having the same name is useful gregwork: the problem is once you are centralized gregwork: creating a key for dev is now technically useable in prod gregwork: because there is no target context for the key gregwork: it just is attached to the user gregwork: hence the script gregwork: where people managing the account can define context for the keys the export in IPA gregwork: so if somebody stole the private key for app1 gregwork: that key might only work in UAT gregwork: based on the access context in the sshkey field rcrit: pretty cool. This is probably worthy an upstream RFE if you wouldn't mind filing a ticket for it gregwork: where do i do that rcrit: https://fedorahosted.org/freeipa/report . }}}
Example script for simple SSH Pubkey ACL sshKeyAuth.sh
Does the IPA HBAC system not meet your needs? I can't recall from our IRC conversation.
IIUC you want to use public keys of one user (developer, etc.) with another account (application), is that correct? There is a ticket for that: #2356.
Replying to [comment:1 rcritten]:
No it does not, I included the IRC conversation in the ticket.. is that not visible for you ?
Wow.
Replying to [comment:2 jcholast]:
This is not about user impersonation.
The problem is that there is no IPA-native mechanism to provide access control to SSH Public Keys. My Solution (attached in the ticket) provides that control, however when I first talked to rcritten he suggested I create this RFE ticket for review.
Example:
1) CompanyX starts to develop a new e-commerce tool, that tool runs as the IPA managed account "ebiz".
2) CompanyX deploys some servers in the dev environment and their developers install an SSH public key on the ebiz account such that they can automate tasks and file copy.
3) When CompanyX promotes the application out of DEV to their QA environment the SSH public key that was created for DEV is now technically usable on the QA servers.
In this case defining an HBAC rule on who can connect to where doesnt matter since as long as you have the private key you can use that key on either group of servers.
I am sorry but I fail to understand what is not working in the current implementation. You can configure SSH to use pam access stack after the authentication is conducted whether an SSH key was user, password or GSSAPI. So in PAM access phase the SSSD will be called and the account would be checked whether it has permissions regarding the host or not. So let us say that there are environments:
DEV, QE and PROD. Machines in DEV will be in host group dev, machines in QE will be in host group qe and machines in PROD will be in group prod. Lest us say that you have an account X that can access development environment using SSH keys. Without any access control (allow_all) he in fact can access any machine the key is valid for. However it you create a rule saying that X is enabled to access only group of hosts dev then when the account would try to access any host in other groups it will be access denied. This is a generic solution regardless of whether you use SSH, password or SSO. Why this does not work for you? What am I missing?
Replying to [comment:6 dpal]:
This is a generic solution regardless of whether you use SSH, password or SSO. Why this does not work for you? What am I missing?
I think the main issue here is that in Greg's place they use the same account (say for example "apache") for all the environments, DEV, QE, PROD
So they put the public keys of all the users in the (DEV, QE, PROD groups on the account in order to access the "apache" user accunt in each group's machines.
The side effect is that DEVs can access "apache" also on PROD's machines.
I think a clever implementation of #2356 perhaps coupled with HBAC (or not) could solve the issue my allowing certain SSH public keys only on specific groups of machines.
Another option would be to not use the same name in all environments and change thre user to be apache-dev on DEV, apache-prod on PROD, etc... but that may be inconvenient in some cases.
Well my solution allows the user to define what server/servers/netblock that key is valid for. I would love for some proper hook in HBAC so I could define policy for it, hence the RFE.
While I understand the intent I do not understand the constraint. Having different accounts or even same accounts with the right HBAC should solve the problem as is. I do not understand what is missing in the existing implementation. So I see three explanations: there is really something is missing and I am failing to grasp it, there is some kind of constraint that you have that we assume you should not have, there is a misunderstanding on how to use HBAC as is for the case you have.
I do not understand how defining which keys can be used on which machines would be different from what we already have now. The keys are the authentication credential. It is used to establish identity in the same way as password or certificate. Access control is enforced once the identity is established. HBAC allows to define different privileges for an account on different groups of hosts i.e. in different environments.
I am still asking: what is wrong with this approach? What is the constraint that prevents this approach from working?
I had to run, updating the ticket with some more info based on the conversation today.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Conversation from #freeipa on irc.freenode.net {{{ <gregwork> maybe some more context on why this is needed and why current HBAC is not sufficient <gregwork> my org has many apps that are deployed/developed long before IPA <gregwork> the apps run as some username, first deployed in DEV and then promoted to the higher environments (UAT/QA/CAT) and then finally PROD <gregwork> so you have some app with say an account called ebiz <gregwork> that was previously a local account <gregwork> in that servers passwd file <gregwork> when we enrolled everything in IPA those accounts were also migrated <gregwork> we have 1 IPA (4x nodes) for the company <gregwork> so now the "ebiz" account is still available in all zones <gregwork> but it is a central account <gregwork> in ipa <gregwork> now the account itself doesnt have a password (mostly) and access is provisioned via ssh keys <gregwork> previously these were hard pubkeys kept in /home/ebiz/.ssh/authorized_keys <gregwork> but we are trying to leverage the fancy ipaSShPubKey feature in freeipa <gregwork> the issue is that if we add the DEVEL pubkey to ebiz in IDM, that is also now valid on non DEVEL servers <gregwork> because there is no control context for the pubkey <gregwork> the workaround solution i included in the RFE ticket allows the user to specify control context <gregwork> but really this should be something that is managed by IPA and possibly policy <gregwork> dpal: does that make sense ? }}}
Replying to [comment:10 gprocunier]:
I had to run, updating the ticket with some more info based on the conversation today. ...
I understand the use case as I think I did from the very beginning. What I do not understand is why you can't use HBAC for it?
HBAC is built for this type of cases. What I am trying to say is that it is fine to add the DEVEL pubkey to ebiz in IDM, that is also now valid on non DEVEL servers. You can create host groups for different environments and define HBAC rules to control access. When this is done though the authentication phase would be successful on any server the access would not be granted based on the host based access control rules. Configuring HBAC is similar to configuring SSH key contexts you propose but it is already there without any changes. So question is still why we need another mechanism if there is already one to accomplish the same? I might be wrong and we really need it. I just fail to understand why. Sorry. I assume that you use latest SSSD on the clients that delivers the keys from the server integrates with SSH. Is this the case? If yes then you can use HBAC because SSSD will enforce it. If you do not use SSSD how do you take advantage of this feature in the first place?
Replying to [comment:5 gprocunier]:
Replying to [comment:2 jcholast]: IIUC you want to use public keys of one user (developer, etc.) with another account (application), is that correct? There is a ticket for that: #2356. This is not about user impersonation.
How is this not about impersonation? In your example the developer authenticates as user ebiz with his SSH key, i.e. the developer is impersonating ebiz. If impersonation was implemented and there was an impersonation rule saying "any user in group 'developers' can authenticate as user 'ebiz' on any host in hostgroup 'DEV'", it would solve your problems, wouldn't it?
OK, I reread this once again. I think what was missing is that different environments have different SSH keys for the same account. So when account X is in DEV environment the key is Kdev and when in PROD it is Kprod so IPA should have a way to map user public SSH keys to different host groups. Is this what you are asking?
So the feature is to: a. Allow multiple public SSH keys per user account b. Pick the right SSH key depending upon which host group the system the user is accessing belongs to.
Is this the correct understanding of a problem?
Replying to [comment:13 dpal]:
OK, I reread this once again. I think what was missing is that different environments have different SSH keys for the same account. So when account X is in DEV environment the key is Kdev and when in PROD it is Kprod so IPA should have a way to map user public SSH keys to different host groups. Is this what you are asking? So the feature is to: a. Allow multiple public SSH keys per user account b. Pick the right SSH key depending upon which host group the system the user is accessing belongs to. Is this the correct understanding of a problem?
Essentially yes.
Please note that this request should be now solvable with the new [FreeIPA 4.1] http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust ID Views feature. It is possible to define ID View and different SSH keys for IPA/AD users per hostgroup.
Testing ID Views+SSH keys in particular will require SSSD 1.12.3 which is still in works. It is being tracked in ticket #4509.
Replying to [comment:17 mkosek]: ...
Note that if you are running on CentOS/RHEL, this functionality should be part of 7.1 Beta.
#4509 was fixed in 4.1.3, moving to the same milestone and closing the ticket. Please let us know if the new functionality does not suite these needs.
Metadata Update from @gprocunier: - Issue assigned to someone - Issue set to the milestone: FreeIPA 4.1.3
Login to comment on this ticket.