Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] Possibility to manage ssh authorized_keys and accounts via hiera #54

Open
KervyN opened this issue Aug 21, 2017 · 7 comments

Comments

@KervyN
Copy link

KervyN commented Aug 21, 2017

Hi,
sorry for that, maybe dump, question, but is it possible to manage the ssh authorized_keys and accounts via hiera?

I would like to roll out a basic set of keys for root (all the senior uber duper admins) and on some hosts a couple more (maybe db admins, or admins in training).
Additional to that question: We have a seperate user with a seperate uid on each host (host1.example.com -> host1(uid 12345), host2.example.com -> someotheruser(uid 54324) and so on).
I would like to define them in the hiera config so I have one single point of truth where which accounts are generated.

Currently everything is done manual, and the puppet configuration is more than obscure. I try to refactor everything to the current state of the art with hiera, r10k, modules and roles.

@jschaeff
Copy link
Contributor

Yes it's possible. The documentation of this module explains how te declare the accounts and the ssh_keys via hiera.

For your uid management, I suggest you put a node level hierarchy (nodes/%{trusted['certname']}.yaml) and you can override configurations from common.yaml

My advices : read the hiera merging strategy documentation, test a hierarchy and play with the puppet lookup command

@KervyN
Copy link
Author

KervyN commented Sep 5, 2017

Hi, thank you. Is it also possible to have groups of ssh keys? Like @admins(admin1, admin2, admin3) @Team-project1(dev1,dev2,admin3,pm2) ?

@jschaeff
Copy link
Contributor

jschaeff commented Sep 6, 2017

To do this, I use a hack:

  • declare accounts::user 'project1' in hiera
  • declare an accounts::group in hiera with explicit name keys_for_project1 and put every user you want.
  • realize the shared account for this group :
accounts::user{'project1':
  authorized_keys => ['@keys_for_project1']
}

@KervyN
Copy link
Author

KervyN commented Sep 6, 2017

Maybe I need to find some other idea to realise this. We have ~300 hosts, which are exclusive for single projects, every host got its own users based on the project, with multiple devs accessing this particular user.

Wouldn't be practical to have this in my manifest. Thats why I wanted to have this kind of stuff in hiera and have the module just create/manage the user(s)

common.yaml:
accounts::user:
  root:
    authorized_keys:
      - @admins

host1.example.com.yaml
accounts::user:
  project1:
    authorized_keys:
      - @team-project1
      - DBAdude

host2.example.com.yaml
accounts::user:
  root:
    authorized_keys:
      - @admins
      - dbadude
  project2:
    authorized_keys:
      - frank-the-tank
      - jenkins-deployment-key

So with your solution I would need to make something like (correct me if I am wrong):

if fqdn == host2.example.com
  accounts::user{'project2':
    authorized_keys => ['@keys_for_project1']
  }
elsif fqdn == host1.example.com
....
end

@jschaeff
Copy link
Contributor

jschaeff commented Sep 6, 2017 via email

@KervyN
Copy link
Author

KervyN commented Sep 7, 2017

But this would enroll all the project accounts on all servers, wouldn't it?
Or maybe I am just to stupid to understand correctly.

@jschaeff
Copy link
Contributor

jschaeff commented Sep 7, 2017

Or it's a bit complicated to explain.

Say in your common.yaml you set

accounts::usergroups:
  projects:
  authorized_keys_for_project:

Without any user in those groups

If you realise

 if lookup('accounts::usergroups')['projects'] {
  accounts::user{'@projects': 
    authorized_keys => ['@keys_for_project1']
  }
}

Then a host without specific usergroup defined in hiera will not realize anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants