I think there are a couple of things to consider:
- If the user can create regular computes and associate/dissociate security groups at will, altering their rules when needed, then why can't they do the same for database "computes"? It's important to note that even if Trove attempts to stop them, if they have access in Nova, they can do whatever they want.
- As Michael pointed out, if the user desires to run the service on a non-standard port (and the api schema supports such a parameter), how can we accommodate it?
- Take Cassandra, which can require ports 7000/7001, 7199, and 9160. If CONF.security_group_support/rules == True, should all four ports automatically be opened?
- If as a cloud provider, you rely on a DevOps model, there must be a self-service means of shutting off traffic to the database. The easiest way as a user to accomplish this would be to delete the security group rule (e.g. for 3306), or modify a rule's CIDR. However, if the user is not allowed to modify or add/drop rules, the admin is left on the hook.
- Administrators need the ability to add a SSH (22) security group rule in situations that require them to get on the VM to triage (first-boot or agent upgrade issues, etc.)
- Users shouldn't be able to open up non-related ports on a whim.
All things considered, I'm thinking this is the right approach: each service type has a set of ports that can be considered eligible, as defined by the cloud provider.
- Example #1: Cloud provider 'A' offers MySQL on 3306.
- Example #2: Cloud provider 'B' offers MySQL on 3399, with a reverse proxy open on 6646.
- Example #3: Cloud provider 'C' offers MySQL on 3306, with a custom agent (installed in the disk-image) on 9909
How can all of these be accomodated?
CONF.<service_type>_<port_type>_ports_eligible = List(Integer)
CONF.<service_type>_ports_applied = True/False
CONF.<service_type>_ports_user_modify = True/False
Example:
# existing properties
trove_security_groups_support = True
trove_security_group_rule_cidr = 0.0.0.0/0
# new properties
security_group_rule_cidr_user_modify = False
mysql_tcp_ports_eligible = [3306]
mysql_ports_applied = True
mysql_ports_user_modify = False
cassandra_tcp_ports_eligible = [7000, 7001, 7199, 9160]
cassandra_ports_applied = True
cassandra_ports_user_modify = False
memcached_tcp_ports_eligible = [11212]
memcached_udp_ports_eligible = [11213]
memcached_ports_applied = True
memcached_ports_user_modify = False
As seen with the current behavior, if trove_security_groups_support == False, the rest of this logic can be ignored/skipped. Assuming it is set to True, the following should be in effect:
If ports_applied is True, then all ports that are eligible are automatically applied on instance creation. If ports_applied is False, then none are automatically applied (i.e. a security group with no rules). If user_modify is True, the user is free to add/drop/modify security group rules, as long as the port(s) are eligible (and if a cidr is included, cidr_user_modify must be set to True). If user_modify is False, then the administrator is the only one capable of modifying security group rules. (Corner Case: If an administrator adds a rule to an instance that includes a port that is not in the eligibility list, even if user_access is True, the user cannot drop it)
Given that today we have the following CONF properties:
trove_security_groups_support = True
trove_security_groups_rules_support = False
trove_security_group_rule_protocol = tcp
trove_security_group_rule_port = 3306
trove_security_group_rule_cidr = 0.0.0.0/0
This means some deprecation is necessary. The best course of action for this (I'm thinking) is to introduce a sub-header in the CONF for the new security group properties, and add validation that a property under the new sub-header can't be present if any of the old trove_security_group_* properties are present.