Hmm.... So, use rsync to push the scripts to each server, making sure to only send the data relevant to each specific server. Right?
Um, isn't that basically what Ansible does by default? It pulls together the relevant information for each server, then transfers the scripts to that server, and runs them. What am I missing? --David Reagan On Sun, Jun 7, 2015 at 1:16 AM, Anand Buddhdev <arh...@gmail.com> wrote: > On Thursday, 4 June 2015 22:34:33 UTC+2, David Reagan wrote: > > Hi David, > > We had the same issue, where we didn't like our entire git repository > exposed on all servers while using ansible-pull. > > We have solved our problem differently. Instead of letting ansible-pull do > a git checkout, we have a small shell script on each host, which uses rsync > to pull in the playbooks, roles, group_vars and host_vars. > > We try not to keep any private information in the playbooks and roles. All > private information is in group_vars and host_vars. And then on the server > side, we use rsync filters to only send those group_vars and host_vars > files to a host that it needs. So a host should never have access to > private data of another host. > > Perhaps you should consider such an approach. It's more work, of course, > but we like our idea, and it works well for us. > > Regards, > Anand > > ansible-pull checks out your entire project repository, then runs >> whichever playbook you tell it to. That repo is basically a map to your >> entire infrastructure. >> >> So, how do you ensure a compromised server doesn't reveal all that >> information to an attacker? (With the assumption that the attacker has root >> access, and that a single rooted server doesn't mean your entire >> infrastructure is rooted.) >> >> ansible-pull can purge the repo after it runs, but that doesn't stop an >> attacker from running ansible-pull with that option turned off in order to >> get a copy of the whole repo. Or just read the repo the next time >> ansible-pull is running. >> >> If you use ansible-vault, then your vault password is either in the cron >> job, or in a file on the server that the attacker has access to, and knows >> the location of. >> >> So far, all I can think of to mitigate these issues, is a repo per >> server, and a vault password per repo.... Which kinda destroys most of why >> people use configuration management. >> >> Am I just not thinking of it in the right way, or maybe misunderstanding >> how something works? >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/HuCM9Gd_XPI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > ansible-project+unsubscr...@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/0f552b80-f25b-4fa0-80b1-b2d00ed215bf%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/0f552b80-f25b-4fa0-80b1-b2d00ed215bf%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+unsubscr...@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/CANo%2B_AfLBj8FV8aya_hA%3D4HyUifiSVQ-bFfhn_bg9XW%3DJsW0ig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
