It should be possible to define AWS Security Groups in resource pool, not only network

[keymon]

Problem description

AWS Security Groups is a property that can be specified per EC2 instance during its creation. It is also used in other resources like ELBs, RDS instances, etc... Different instances and resources can use different Security Groups, regardless the VPC and subnet they are located.

But BOSH AWS CPI only allows assign security groups in the network definition (networks.<id>.cloud_properties.security_groups), so that ALL the instances defined in that network will have the same security groups.

To workaround the issue, if it is required different security groups in different instances in the same network, one is forced to "artificially" split the network definition in two networks. If several security groups are required, several different networks must be defined, making the manifest difficult to understand and manage. See below for an example.

Expected behaviour

As security groups in AWS is a property assigned per instance, it is desirable that security groups can be defined in the resource_pool, as in resource_pool.<id>.cloud_properties.security_groups.

As the CPI currently allows the SG definition in the network, such feature should not be removed, instead we can add the new feature as:

• resource_pool.<id>.cloud_properties.security_groups completely overrides the ones defined in the networks.
• resource_pool.<id>.cloud_properties.security_groups is merged with the ones defined in the network.
• Two new properties, resource_pool.<id>.cloud_properties.security_groups to override and resource_pool.<id>.cloud_properties.additional_security_groups to merge.

Example use case

We want to implement RDS for Cloud Controller and UAA, and setup security groups to only allow API/CloudController and UAA instances connect to our RDS instance.

For that, we create a new AWS security group called cf_rds_clients, which needs to be assigned ONLY to API instances and UAA.

With the current implementation we must define a new network in the manifest only for the api and uaa jobs, which is counter intuitive and requires additional work.

If SG can be defined in the resource pool, we simple need to define a new resource pool type for api and uaa.

Example of workaround

In a normal network definition like this:

- name: cf1
  subnets:
    - range: 10.0.16.0/24
      reserved:
        - 10.0.16.2 - 10.0.16.9
      static:
        - 10.0.16.10 - 10.0.16.40
      gateway: 10.0.16.1
      dns:
        - 10.0.0.2
      cloud_properties:
        subnet: (( grab terraform_outputs.cf1_subnet_id ))

If we want to setup a new SG, we need to split that network, allocating a range of IPs which will be reserved in the old network but used in the new one.

- name: cf2
  subnets:
    - range: 10.0.17.0/24
      reserved:
        - 10.0.17.2 - 10.0.17.9
        - 10.0.17.41 - 10.0.17.50
      static:
        - 10.0.17.10 - 10.0.17.40
      dynamic:
        - 10.0.17.51 - 10.0.17.255
      gateway: 10.0.17.1
      dns:
        - 10.0.0.2
      cloud_properties:
        subnet: (( grab terraform_outputs.cf2_subnet_id ))

- name: cf2_rds
  subnets:
    - range: 10.0.17.0/24
      reserved:
        - 10.0.17.2 - 10.0.17.9
        - 10.0.17.10 - 10.0.17.40
        - 10.0.17.51 - 10.0.17.255
      static: []
      dynamic:
        - 10.0.17.41 - 10.0.17.50
      gateway: 10.0.17.1
      dns:
        - 10.0.0.2
      cloud_properties:
        subnet: (( grab terraform_outputs.cf2_subnet_id ))
        security_groups:
          - (( grab terraform_outputs.default_security_group ))
          - (( grab terraform_outputs.cf_rds_client_security_group ))

[saliceti]

+1
It would be even better to be able to choose security groups at the job level.

[keymon]

I think implementation should be done here