Is there a way for a cloud user (using euca2ools) to check which virtual subnet their VMs will be running on? (Assuming that they do not have knowledge of config file contents -- i.e., VNET_ADDRSPERNET)
I am setting up a small test cloud to support multiple users, and would like each user to be able to set up their security groups to either completely isolate their VLAN from other users, or only provide limited access to their virtual resources to other cloud users.
Also, if anyone could point me to more comprehensive documentation on security groups (so far I only know of the 1.6 User Guide and the euca2ools man pages), it would be greatly appreciated.
Thanks!
Hello,
the way you do this, is to create a security group (which will have a name say 'test'). You can then add the rules you want to that security group (you will need the name of the security group). Finally when you start an instance, you specify which security group it will belong to: this last step ensure that the instance will inherit the rules specified by the security group.
This way there is not need for the user to know which subnet the instance will belong to, but it just need to remember the name of the security group with the right sets of rules. You can search for documentation on the web: AWS uses the same mechanism. Feel free to ask specific question about security group here.
cheers
graziano
I think you misunderstood my question, as I did not provide enough information regarding the context. Here's a bit more info.
I am looking to use OpenSplice to allow "cloud users" to share information within the cloud via a pub-sub framework (this is for research purposes -- I realize it might seem a bit odd). This requires that traffic to a couple ports on VMs are allowed. I understand how to do this, with the knowledge of the subnet to allow traffic from. Note that I do not want to simply allow 0.0.0.0/0 -- the idea is that userA and userB want to share information within the cloud, so they allow traffic from one another in their security groups. However, they don't want to share it with userC, or simply any one that can access the VMs from the public interface.
However, I feel that this solution is inappropriate, because I need to know which cloud users are actively using which subnets. Furthermore, If one user terminates their instances, wouldn't it be possible for another user to start up an instance and get the previous user's subnet?
Perhaps I am asking for functionality that doesn't really exist, since this isn't a typical need. If that's the case, so be it. I'm just trying to figure out if there's a less hackish way to achieve what I'm trying to do.
Please let me know if you'd like me to explain the context a bit better.
Hello,
I may be confused now: isn't the -u option in euca-authorize enough?
The private subnet used by Eucalyptus can be reused, but the rules applied to that subnet comes from the security group. Thus there is no way for a user to 'inherit' the rules form another user security group.
Feel free to give more details if I misunderstood again your needs.
cheers
graziano
I apologize for the long 2-part reply, but if you bear with me, I think we can get through this ;) -- I appreciate the help!
In response to above:
---------------------
I saw the -u and -o options in the euca-authorize man page, but wasn't sure what it meant by "User ID" and "group" -- are these referring to the UIDs and groups on the Cloud Controller box (shown when running id or groups commands), or to some sort of Eucalyptus credentials? I think a couple example usages would help clear up my confusion.
Clarification of my "problem" within its context:
-------------------------------------------------
I think my original question has been muddied by the lack of context. I am creating a private cloud setup in my research lab, and would like it to mimic an "enterprise" private cloud as best we can with the hardware we have.
The remainder of this post includes a high-level description of the scenario I am trying to mimic, and then attempts to pose my question again, within this context.
Supoose there are 4 parties:
- Private Cloud Administration Team: Running the Private Cloud
- Departments A, B, C: Cloud Users
Depts. A, B, and C are able to sign up via the web interface, download their credentials, and use euca2ools to interact with the Private Cloud. They do not have any knowledge of the cloud internals -- they interact with it only though the "API" presented by euca2ools.
We can assume that departments A and B know the usernames that one another signed up (on the web interface) with, and that they are using the known default ports for their program.
Depts. A and B would like to share data between their VMs, using some software that binds a few TCP/IP ports. Note that A and B do not want Dept C (or the rest of the world) to be able to access the ports used by their software.
The revised questions
-----------------------
What is the most robust solution for allowing software in A's and B's VM's to communicate? I'm pretty sure that Eucalyptus Security Groups (via euca2ool's euca-authorize) is the tool for the job, but I'm not sure how to accomplish this. Is this what the -u option is for?
Hello,
the -u options specify a user (notice that there is a different between AWS and eucalyptus: AWS uses digits, Eucalyptus uses names) and the -o options specify the group. So you can specify a specific security group of a user. Getting to your example, if BOB is from Dept A and ALICE is from Dept B and ALICE wants to allow BOB's instances of group sales to her instances of group default for port 80, she should do
euca-authorize -P tcp -p 22 -u BOB -o sales default
This will allow Bob's instances belonging to security group sales access to the web server on Alice's instances on the default group.
Does this make sense?
cheers
graziano
graziano,
I found your post to be very clear. I didn't realize that -u and -o had to be used in conjunction with one another, but now it makes sense.
However, I'm clearly still misunderstanding something, or running into a rather nasty bug. When I attempt to use the -u and -o options, the protocol (-P) option and port (-p) options seem to be completely ignored, and instead of allowing traffic only on the specified port & protocol, full access is granted.
I have verified that this is the case using netcat to listen on a variety of tcp ports on the [jonszy, group2] boxes. They are most definitely receiving data from the [admin, default] boxes,
$ euca-describe-groups
GROUP jonszy default default group
PERMISSION jonszy default ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0
GROUP jonszy group2 A test group
$ euca-authorize -P tcp -p 8080 -u admin -o default group2
GROUP group2
PERMISSION group2 ALLOWS USER admin GRPNAME default
$ euca-describe-groups
GROUP jonszy default default group
PERMISSION jonszy default ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0
GROUP jonszy group2 A test group
PERMISSION jonszy group2 ALLOWS tcp 0 65535 GRPNAME default
PERMISSION jonszy group2 ALLOWS udp 0 65535 GRPNAME default
PERMISSION jonszy group2 ALLOWS icmp -1 -1 GRPNAME default
Version info:
$ euca-version
1.0-31337 2009-04-04
$ cat /etc/eucalyptus/eucalyptus-version
1.6.2
eucalyptus.conf
# /etc/eucalyptus/eucalyptus.conf
#
# These are the Ubuntu Enterprise Cloud's default Eucalyptus parameters.
#
# Affects: All
# See: **NOTE** below
EUCALYPTUS="/"
EUCA_USER="eucalyptus"
MAX_CORES="16"
#
# Affects: CLC, Walrus, SC
DISABLE_DNS="Y"
DISABLE_ISCSI="Y"
#
# Affects: CC, NC
# See: **NOTE** below
ENABLE_WS_SECURITY="Y"
LOGLEVEL="DEBUG"
VNET_PUBINTERFACE="eth1"
VNET_PRIVINTERFACE="eth0"
VNET_MODE="MANAGED"
#
# Affects: CC
# See: **NOTE** below
CC_PORT="8774"
SCHEDPOLICY="ROUNDROBIN"
POWER_IDLETHRESH="300"
POWER_WAKETHRESH="300"
NC_SERVICE="axis2/services/EucalyptusNC"
VNET_DHCPDAEMON="/usr/sbin/dhcpd3"
VNET_DHCPUSER="dhcpd"
NODES=""
VNET_ADDRSPERNET="32"
#VNET_SUBNET=""
#VNET_NETMASK=""
#VNET_DNS=""
#VNET_PUBLICIPS=""
#
# Affects: NC
NC_PORT="8775"
HYPERVISOR="kvm"
MANUAL_INSTANCES_CLEANUP=0
VNET_BRIDGE="br0"
INSTANCE_PATH="/var/lib/eucalyptus/instances/"
##########################################################################
#
# Administrative overrides and customizations may go below, in accordance
# with the manpage for eucalyptus.conf(5).
#
# However, to modify Eucalyptus parameters, you are advised to use
# euca_conf(8), which will update eucalyptus.local.conf(5) and ensure
# smooth package upgrades.
#
# **NOTE**: To activate changes of these parameters on a CC, you must:
# sudo restart eucalyptus-cc CLEAN=1
# HOWEVER, if you do this, all currently running virtual
# machines in this cluster will lose network connectivity.
#
##########################################################################
eucalyptus.local.conf:
# /etc/eucalyptus/eucalyptus.local.conf
# This file is read and written by euca_conf(8)
# WARNING: You should *never* edit this file directly.
# To modify Eucalyptus parameters, either use euca_conf(8), or
# edit /etc/eucalyptus/eucalyptus.conf according to eucalyptus.conf(5).
# network configuration from the input configuration file
VNET_MODE="MANAGED"
VNET_SUBNET="172.0.0.0"
VNET_NETMASK="255.0.0.0"
VNET_DNS="192.168.2.1"
VNET_ADDRSPERNET="32"
VNET_PUBLICIPS="192.168.2.40-192.168.2.253"
Just curious if I could get a few people to try setting up a user/group-based rule and posting their results to help me determine if this is a config issue, or a bug (in which case, if I need to contact someone at the UEC project or not).
I'm using UEC, so it'd be great if I could see some results from folks who are and aren't using UEC.
Thanks again Eucalyptus Community :)
Hello,
I just checked and it turns out that the behavior you see it is what EC2 used to do. That is, once you specify user and group, all ports were open between them. EC2 moved away from it, and now allows a user to specify a port range, but we don't have that yet but it should be in the next Eucalyptus release.
cheers
graziano
graziano, thank you so much for verifying this! Could you point me to doucmentation/mailing list post/source code that allowed you to determine this -- I just want to document this well so the next person that picks up my project can be sure to be on the lookout for this update.
By the way - will this be in a major release, or an update? I'm using UEC, and just want to have an idea whether I'll have to upgrade to a new version or use a special package source, or if I can expect to see this in one of my regular updates.
Thanks again!
Hello,
we have 2.0 upcoming: so yes it's a major release upgrade but we should have upgrade path from older version. UEC should pick it up too before the next release. There should be a launchpad bug, but I don't know it off hand: 2.0 should be release shortly though (few weeks at worst).
cheers
graziano