FAQ
Today, we have a setup where all of our playbooks, roles, etc are owned and
run by root on our 'management instance'. Some important key files are
protected/encrypted in the root home directory that playbooks need to
access at times - this is why we root owns this. To allow others to run
certain playbooks, we have given them specific sudo access for those exact
commands, put them in scripts and version controlled them.

Our ideal world is to have two groups of users:

1) Can deploy, start/stop components via playbooks across the board without
specific whitelisting (but not access the root keys)
2) Users in groups that allow them to run certain playbooks but not others

Just wondering how other people are managing this?

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/47772896-ce77-4844-9129-c8e5e4ee55a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Vitaliy Zhhuta at Aug 8, 2014 at 1:32 pm
    for such kind of tasks Ansible created Tower http://www.ansible.com/tower

    Пʼятниця, 8 серпня 2014 р. 08:44:24 UTC+3 користувач Gary Malouf написав:
    Today, we have a setup where all of our playbooks, roles, etc are owned
    and run by root on our 'management instance'. Some important key files are
    protected/encrypted in the root home directory that playbooks need to
    access at times - this is why we root owns this. To allow others to run
    certain playbooks, we have given them specific sudo access for those exact
    commands, put them in scripts and version controlled them.

    Our ideal world is to have two groups of users:

    1) Can deploy, start/stop components via playbooks across the board
    without specific whitelisting (but not access the root keys)
    2) Users in groups that allow them to run certain playbooks but not others

    Just wondering how other people are managing this?
    --
    You received this message because you are subscribed to the Google Groups "Ansible Project" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
    To post to this group, send email to ansible-project@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6b9a3ed0-544e-4e66-bc9c-90c938ba48b9%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gary Malouf at Aug 8, 2014 at 1:39 pm
    I hear that, but atm we can not afford to go that direction. I was more
    asking what users who have not been able to afford the commercial product
    are doing in the mean-time.
    On Friday, August 8, 2014 6:42:55 AM UTC-4, Vitaliy Zhhuta wrote:

    for such kind of tasks Ansible created Tower http://www.ansible.com/tower

    Пʼятниця, 8 серпня 2014 р. 08:44:24 UTC+3 користувач Gary Malouf написав:
    Today, we have a setup where all of our playbooks, roles, etc are owned
    and run by root on our 'management instance'. Some important key files are
    protected/encrypted in the root home directory that playbooks need to
    access at times - this is why we root owns this. To allow others to run
    certain playbooks, we have given them specific sudo access for those exact
    commands, put them in scripts and version controlled them.

    Our ideal world is to have two groups of users:

    1) Can deploy, start/stop components via playbooks across the board
    without specific whitelisting (but not access the root keys)
    2) Users in groups that allow them to run certain playbooks but not others

    Just wondering how other people are managing this?
    --
    You received this message because you are subscribed to the Google Groups "Ansible Project" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
    To post to this group, send email to ansible-project@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/944d6b00-1ae9-4586-a028-a7d2e44d0371%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael DeHaan at Aug 8, 2014 at 2:41 pm
    I'm not going to sell things on this list, but pricing has recently been
    updated if you have not checked recently - so it might actually make sense
    for you.

    It's a lot more complex to get this right than you think, so it may be
    worthwhile if you have such needs.



    On Fri, Aug 8, 2014 at 9:39 AM, Gary Malouf wrote:

    I hear that, but atm we can not afford to go that direction. I was more
    asking what users who have not been able to afford the commercial product
    are doing in the mean-time.

    On Friday, August 8, 2014 6:42:55 AM UTC-4, Vitaliy Zhhuta wrote:

    for such kind of tasks Ansible created Tower http://www.ansible.com/tower

    Пʼятниця, 8 серпня 2014 р. 08:44:24 UTC+3 користувач Gary Malouf написав:
    Today, we have a setup where all of our playbooks, roles, etc are owned
    and run by root on our 'management instance'. Some important key files are
    protected/encrypted in the root home directory that playbooks need to
    access at times - this is why we root owns this. To allow others to run
    certain playbooks, we have given them specific sudo access for those exact
    commands, put them in scripts and version controlled them.

    Our ideal world is to have two groups of users:

    1) Can deploy, start/stop components via playbooks across the board
    without specific whitelisting (but not access the root keys)
    2) Users in groups that allow them to run certain playbooks but not
    others

    Just wondering how other people are managing this?
    --
    You received this message because you are subscribed to the Google Groups
    "Ansible Project" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to ansible-project+unsubscribe@googlegroups.com.
    To post to this group, send email to ansible-project@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/ansible-project/944d6b00-1ae9-4586-a028-a7d2e44d0371%40googlegroups.com
    <https://groups.google.com/d/msgid/ansible-project/944d6b00-1ae9-4586-a028-a7d2e44d0371%40googlegroups.com?utm_medium=email&utm_source=footer>
    .

    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Ansible Project" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
    To post to this group, send email to ansible-project@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwoakHYPgwRBaB_mLyRmhxWGc_XdpRLyCy3aj-qG87UBQ%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupansible-project @
postedAug 8, '14 at 5:44a
activeAug 8, '14 at 2:41p
posts4
users3

People

Translate

site design / logo © 2021 Grokbase