JohnStrunk / oso-gluster-ansible

Ansible for configuring Gluster to back OpenShift.io
Apache License 2.0
0 stars 4 forks source link

Add playbook to secure shared gluster storage #32

Closed ShyamsundarR closed 6 years ago

ShyamsundarR commented 6 years ago

Signed-off-by: ShyamsundarR srangana@redhat.com

ShyamsundarR commented 6 years ago

Problem: Ansible play to configure shared storage TLS may have partial host list from the inventory, leading to incorrect auth.ssl-allow list or failure to restart the shared storage volume on all nodes.

For example, running the play as follows, will have all nodes that are a part of the volume being created, but not nodes that form the entire cluster. ansible-ec2 -l tag_gluster_group_us_east_2a_c00_g00 ./playbooks/secure-shared-storage.yaml

Similarly a command as below, will have just a single node as a part of the play and not all that are part of the cluster. ansible-ec2 -l us_east_1b_gluster_001 ./playbooks/secure-shared-storage.yaml

This leads to missing ansible_nodename variable for the remaining nodes and also inability for the play to unmount and remount the shared storage volume on all participating hosts.

Abilities present: Irrespective of the host limit used in the play, it is possible to determine all hosts that are part of a group. This is under the assumption that we can determine the group that the hosts in the play is/are part of, and derive the list of hosts from the said group.

No-go's in terms of solution:

  1. Inability to determine ansible_nodename if the host is not part of the play, and hence not part of the fact gathering process, makes it not possible to set the auth.ssl-allow list correctly, if all hosts of a group are not part of the play

  2. Even if we determine all hosts in a group, if there are hosts outside the group but still part of the same gluster cluster, the determination and hence setting of the auth.ssl-allow will be erroneous.

Solution: We need a tag (or equivalent) that groups hosts that are part of the same gluster cluster. This can be leveraged to understand if all hosts (that form the gluster cluster) are part of the play and hence it is feasible to run the play correctly, otherwise to abandon it.

Elaborating, assume every host has a variable gluster-cluster-group and this variable is a group name that contains all hosts that belongs to the said gluster cluster. It is possible to iterate and thus determine across play_hosts and the cluster group variable so that all hosts are part of the play and only these hosts are part of the play.

ShyamsundarR commented 6 years ago

Addressed comment in https://github.com/JohnStrunk/oso-gluster-ansible/pull/32#issuecomment-376527689 as a part of the commit https://github.com/JohnStrunk/oso-gluster-ansible/pull/32/commits/4001a199ef68a14b9758d26621f0c58e94d4e1b4

ShyamsundarR commented 6 years ago

@JohnStrunk If needed we would have to fix the following for this PR, else this is ready for review.

Assumption: A Gluster cluster can have more nodes than what a volume can (which was the case, but is not now)

Problem: The play to setup shared storage security cannot be run on hosts that form a volume, and has to be run on the nodes that form the cluster.

Solution:

ShyamsundarR commented 6 years ago

(after checking out state of code at commit c91f6f4 (pre-split of the cluster into volume units)) BUT, that is wrong, the group is defined in inventory_groups, and the tag defines which volume the node serves, right?

Ok clarification :smile: , reorganizing the comment, as I wrote it, made this appear that the pre-split was wrong, it was meant to convey the explanation I provided above is wrong. IOW, my assumption that gluster_group tag meant it was a "cluster".

ShyamsundarR commented 6 years ago

Couldn't these just be "g-us-east-1a-c00"? Ack! corrected in commit https://github.com/JohnStrunk/oso-gluster-ansible/pull/32/commits/2152369c578ce067731d9daef06a8e1ec80962a4