terraform: create security group on Openstack

[metahertz]

Currently the security group needs manually creating in Openstack and then defining by name in the TF automation for MI, this can be automated by terraform (much as we create the keypair in Openstack automatically) and would reduce complexity + documentation steps.

[stevendborrelli]

I agree. @matjohn2, did you have a list of rules that you would like to include in the security group?

We could think about public ip rules vs. private ip rules. Ideally, they would be the same.

List of ports we are using:

5050/tcp mesos-leader
5051/tcp mesos-worker
8080/tcp marathon
2181/zookeeper
2888/zookeeper
3888/zookeeper

Consul uses the following ports that need to be considered:

Server RPC (Default 8300). This is used by servers to handle incoming requests from other agents. TCP only.
Serf LAN (Default 8301). This is used to handle gossip in the LAN. Required by all agents. TCP and UDP.
Serf WAN (Default 8302). This is used by servers to gossip over the WAN to other servers. TCP and UDP.
CLI RPC (Default 8400). This is used by all agents to handle RPC from the CLI. TCP only.
HTTP API (Default 8500). This is used by clients to talk to the HTTP API. TCP only.
DNS Interface (Default 8600). Used to resolve DNS queries. TCP and UDP.

[sharma-abhishek-it]

Hey.

I would like to contribute and fix this issue. But since I am new to certain methods I have two options to continue:

1. Read the entire source code and understand what exactly each ansible role does and how multiple technologies are curated to run together with all details
2. Dive right into this issue with some help and then figure out things on the go, a pure bottom up approach

Would anyone please suggest whether I can go on about fixing it right now following approach 2 or go to approach 1 and get implementation details cleared out first?

[kenjones-cisco]

@sharma-abhishek-it Hopefully the following will help you get started!

Steven provided the ports above which should cover the inputs.

Then it is a matter of writing the terraform modules for the different cloud providers, see link for more details. https://www.terraform.io/docs/index.html

This is an example of one I did for Openstack (specific to another project but an example):

variable cluster_name {}

provider "openstack" {
}

resource "openstack_compute_secgroup_v2" "cluster" {
    name = "${ var.cluster_name }"
    description = "Security Group for ${ var.cluster_name }"
    rule {
        from_port = 1
        to_port = 65535
        ip_protocol = "tcp"
        self = true
    }
    rule {
        from_port = 1
        to_port = 65535
        ip_protocol = "udp"
        self = true
    }
    rule {
        from_port = 80
        to_port = 80
        ip_protocol = "tcp"
        cidr = "0.0.0.0/0"
    }
    rule {
        from_port = 443
        to_port = 443
        ip_protocol = "tcp"
        cidr = "0.0.0.0/0"
    }
}

output "cluster_name" {
    value = "${ openstack_compute_secgroup_v2.cluster.name }"
}

Matt, also did a great write up with examples on terraform as well. http://www.matt-j.co.uk/

[sharma-abhishek-it]

@kenjones-cisco Alright let me iterate what I understand so far. We need terraform configuration for providing rules to security group(s). Now since we support multiple providers we need to write config for each provider's security group. An example for specifying aws security group rules can be seen here from line 6. In a similar fashion we need to rewrite rules. as mentioned by Steven, for all the providers we currently support.

So first you will need to tell whether my understanding is correct.

Meanwhile I have a few questions regarding implementation.

• I believe we will be using variables for port numbers? Since we will be repeating config in each provider's security group block I think it is better to make it a bit DRY. Right now all we can do is map the values of port numbers to variables. Is there any other way to do this? A for loop would have been great, but it does not YET exist(look here)
• I think the rules will be written inside corresponding terraform/{provider}/*.tf files? I saw aws.tf and it has some existing rules. So these new rules will go in those blocks right?

[kenjones-cisco]

@sharma-abhishek-it Your understanding is correct.

The port numbers within each resource would be static, and DRY within each provider. But each provider is independent such that the same information will need to be repeated for each cloud provider currently supported.

Yes, the rules are written within terraform/{provider}/*.tf files. For aws it would be adding rules based on the list provided by Steven.

[sharma-abhishek-it]

@kenjones-cisco regarding variables I was meaning to load a .tfvars file where all the port numbers will be listed. That way without repeating the actual values of port no I will simply be using their corr. variable names in each provider.

That was one thing. Another thing is that terraform also accepts JSON and recommends it for machine generated files. Do you think we should generate the configuration for providers instead of writing it down for each separate one? Why I say that is we might need to add new ports tomorrow or something else completely different to run things like Kubernetes which needs a subnet of all machines for proper resource allocation. If we are generating those JSON then things are way more DRY. Don't know if that is out of scope of this issue or whether there are any drawbacks of it. For instance one drawback is that our generation script/tool will need to be tightly coupled with terraform provider's resource definitions. Although we are already tightly coupled since we are defining those tf files in the first place. Please share your thoughts on this.

[kenjones-cisco]

The .tvars would be a good approach for handling all the exposed ports.

I like where you are going with the generate direction, but I believe that part could be a second PR to enable automation of creating the terraform files.

@matjohn2 @stevendborrelli Please feel free to weigh in.

[sharma-abhishek-it]

oops seems like I cannot run infrastructure locally yet! Look hashicorp/terraform#265

guys am waiting on you to tell me how to proceed ahead on this one. Where do I run my code after developing it? I do not have any account with cloud provider... And my AWS free tier expired way back in time. Please help!

[langston-barrett]

@sharma-abhishek-it You can at least test your code in Vagrant once written. You can indeed use Vagrant with MI, just run vagrant up like you might expect. It is usually our first round of testing. If you submit a PR and ask for help testing on cloud providers, we can lend a hand.

[sharma-abhishek-it]

Regarding .tfvars file. I am trying to write all ports in one tfvars file that could be reused by any provider. My only concern is that some providers(e.g GCE) use strings for port no. like "22" while other(e.g AWS) use numbers 22. So in this case what should I do? Is it possible that it does not matter whether the port no. is a string or an integer(no.)? If it does matter should I make two variables then, like this

mesos_leader_port = 5050         # for use in AWS like formats
mesos_leader_port_str = "5050"   # for use in GCE like formats

[sharma-abhishek-it]

Guys any suggestions for the above? should I skip tfvars for now and instead hardcode these ports? That makes testing also easier since tfvars need to copied to the directory where terraform is run on. So we will need a script to do that and include those in tests as well. So should I skip using tfvars and just hardcode ports in the providers tf files?

[kenjones-cisco]

My thoughts, continue the hard coded approach for now to keep things simple.

[sharma-abhishek-it]

Hey guys I opened PR #651 and it failed all tests. Could anyone help me sort out where the test is failing and how to debug this? The output is here

I am seeing this -> KeyError: u'access_ip_v4'

[sharma-abhishek-it]

Hey guys stuck a bit on this. Issues are happening in my PR #651 but I do not have openstack setup on my dev desktop. So I believe I will need to do a local openstack and deploy things to debug this locally? What should I do?

[stevendborrelli]

Do you have access to an openstack cluster?

If not, you could try trystack.org or one of us will have to test it.

[sharma-abhishek-it]

Ok I will try out trystack.org. And terraform will handle setting up the cluster on trystack?

[antimack]

Hi. I've been working on implementing group creation for terraform/openstack and also some refactoring for auth and terraform variables, but I'm unable to push and create a remote branch for pull request. Could someone help me and grant an access? Thanks.

[langston-barrett]

@antimack I'm assuming you figured out how to make a clone, etc.? Did you need any other help?

[antimack]

@siddharthist I've forked the repo and created a pull request, so this isn't a problem anymore, thanks.

[josdotso]

I think automation of security group creation should focus on end usage. For example, a security group containing my control nodes has a homogeneous set of connection needs, while the same is true for compute and edge. Without the edge nodes in their own security group, we're likely to accidentally shoot ourselves in foot as we try to expose an app and instead expose the admin console (where this isn't prudent). Therefore, a security group for each type of node would be best, if it's being automated anyway. Manually, this would be too much work, IMHO.