38,907
edits
(Updating to match new version of source page) |
(Updating to match new version of source page) |
||
Line 10: | Line 10: | ||
To add or remove rules from a security group, click ''Manage Rules'' beside that group. When the group description is displayed, you can add or remove rules by clicking the ''+Add Rule'' and ''Delete Rule'' buttons. | To add or remove rules from a security group, click ''Manage Rules'' beside that group. When the group description is displayed, you can add or remove rules by clicking the ''+Add Rule'' and ''Delete Rule'' buttons. | ||
The '''default security group''' contains rules which allow a VM access out to the internet, for example to download operating system upgrades or package installations, but does not allow another machine to access it, except for other VMs belonging to the same default security group. We recommend you do not remove rules from the default security group as this may cause problems when creating new VMs. You may recall, however, in the [[Cloud Quick Start]] you were directed to add a security rule for port 22 to allow incoming traffic so that you were able to connect to your VM ([[ | The '''default security group''' contains rules which allow a VM access out to the internet, for example to download operating system upgrades or package installations, but does not allow another machine to access it, except for other VMs belonging to the same default security group. We recommend you do not remove rules from the default security group as this may cause problems when creating new VMs. You may recall, however, in the [[Cloud Quick Start]] you were directed to add a security rule for port 22 to allow incoming traffic so that you were able to connect to your VM ([[Creating_a_Linux_VM#Firewall.2C_add_rules_to_allow_SSH|Firewall, add rules to allow SSH]]). | ||
[[File:Default_security_group_rules_en.png|400px|thumb| Default Security Group Rules (Click for larger image)]] | |||
The image on the right show the default security group rules that should be present: | |||
* 2 Egress rules, allow your instance to access outside network without any limitation, there is one rule for IPV4 and one for IPV6. | |||
* 2 Ingress rules, allow communication for all the vms that belong to that security group, for both IPV4 and IPV6. | |||
You can define multiple security groups and a VM can belong to more than one security group. When deciding on how to manage your security groups and rules, think carefully about what needs to be accessed and who needs to access it. Strive to minimize the IP addresses and ports in your Ingress rules. For example, if you will always be connecting to your VM via SSH from the same computer with a static IP it makes sense to allow SSH access only from that IP. To specify the allowed IP or IP range use the [https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR] box (use this web based tool for converting [http://www.ipaddressguide.com/cidr IP ranges to CIDR] rules). Further, if you only need to connect to one VM via SSH from the outside and then can use that as a gateway to any other Cloud VMs, it makes sense to put the SSH rule in a separate security group and add that group only to the gateway VM. However, you will also need to ensure your SSH keys are configured correctly to allow you to use SSH between VMs (see [[SSH Keys]]). | You can define multiple security groups and a VM can belong to more than one security group. When deciding on how to manage your security groups and rules, think carefully about what needs to be accessed and who needs to access it. Strive to minimize the IP addresses and ports in your Ingress rules. For example, if you will always be connecting to your VM via SSH from the same computer with a static IP it makes sense to allow SSH access only from that IP. To specify the allowed IP or IP range use the [https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR] box (use this web based tool for converting [http://www.ipaddressguide.com/cidr IP ranges to CIDR] rules). Further, if you only need to connect to one VM via SSH from the outside and then can use that as a gateway to any other Cloud VMs, it makes sense to put the SSH rule in a separate security group and add that group only to the gateway VM. However, you will also need to ensure your SSH keys are configured correctly to allow you to use SSH between VMs (see [[SSH Keys]]). | ||
Line 164: | Line 169: | ||
To use a QCOW2 image downloaded from an OpenStack cloud, as shown above, with VirtualBox you will need to convert the image in the qcow2 format to the vmdk format. This can be done with the <code>qemu-img</code> tool. This can be installed with something like | To use a QCOW2 image downloaded from an OpenStack cloud, as shown above, with VirtualBox you will need to convert the image in the qcow2 format to the vmdk format. This can be done with the <code>qemu-img</code> tool. This can be installed with something like | ||
{{Command|sudo apt-get install qemu- | {{Command|sudo apt-get install qemu-utils}} | ||
then do the conversion with | (previously the package was called <code>qemu-img</code>) then do the conversion with | ||
{{Command|qemu-img convert -f qcow2 vdisk.qcow2 -O vmdk vdisk.vmdk}} | {{Command|qemu-img convert -f qcow2 vdisk.qcow2 -O vmdk vdisk.vmdk}} | ||
Then you can create a new virtual machine and attach the vmdk image to it (see [http://techathlon.com/how-to-run-a-vmdk-file-in-oracle-virtualbox/ how to run a vmdk file in virtualbox] for detailed instructions on this). | Then you can create a new virtual machine and attach the vmdk image to it (see [http://techathlon.com/how-to-run-a-vmdk-file-in-oracle-virtualbox/ how to run a vmdk file in virtualbox] for detailed instructions on this). |