Google Compute Engine

Images

An Image resource contains a boot loader, an operating system, and a root file system that is necessary for starting an instance. You must always specify an image when you create an instance or when you create a root persistent disk. By default, Google Compute Engine installs the root filesystem defined by the image on a root persistent disk.

Images belong to a project and can either be only accessible by that project (private) or accessible by any project (public). The project owner controls how accessible the image is. Depending on the contents of the image, some images cost money to use, while others are free. For example, Google-provided images of Red Hat Enterprise Linux (RHEL) and SUSE cost an additional fee to use.

This page describes the Image resource in detail, how to create an image from a root persistent disk, and how to create a new image altogether.

Contents

Accessing images

Images can be either public or private. Public images are available to all users, while private images are only available to the project that the image resides in. Accessing an image depends on whether an image is public or private and whether you have the right permissions.

Public images

Public images are visible by everybody and can be used by any Compute Engine project. Public images can be provided and maintained by Google, open-source communities, and third-party vendors. These images contain preloaded operating systems that can run on Compute Engine instances.

It is not currently possible for users to create public images. Users who want to share an image publicly should grant public access to the original Google Cloud Storage bucket where the source image file is stored.

Private images

Users create private images by default. Private images are only accessible from within the project that owns the image. As a user, you can create a new image from an existing root persistent disk or you can create a new image from scratch. To create a private image, see Creating an image from a root persistent disk.

Listing all images

You can see a list of all images available to your project by performing a gcutil listimages command. This lists all public and private images that your project can use.

gcutil --project=<project-id> listimages

Starting an instance from an image

Using an image differs if you are using gcutil or using the API.

Starting an instance in gcutil

To use an image in gcutil, you can either provide the fully-qualified URL to a specific image for private images or use prefix matching to use the latest Debian or CentOS image offered by Compute Engine. To use prefix matching, provide one of the following values with your --image flag in gcutil:

  • debian-7 - Fetches the latest Debian 7 image.
  • centos-6 - Fetches the latest CentOS 6 image.
  • rhel-6 - Fetches the latest Red Hat Enterprise Linux 6 image.
  • sles-11 - Fetches the latest SUSE Linux Enterprise Server 11 image.

For example, if you pass in --image=debian-7, gcutil first looks in your private images for a matching image name, and if it fails to find a match, it moves on to look in the Debian and CentOS projects. Once if finds a match in the image name, it choose the latest image version to use. A request to add an instance using prefix matching looks like the following:

gcutil --project=<project-id> addinstance mytestinstance --image=debian-7

If you want to unambiguously specify a certain image, you can pass in the full image name with the image project, in the following format:

projects/<project-id>/global/images/<image-name>

To use a specific image in your requests, provide the full image name with the image project using the --image flag. For example, to use a Debian image, make a request like so:

gcutil --project=<project-id> addinstance myinstance --image=projects/debian-cloud/global/images/debian-7-wheezy-vYYYYMMDD

Starting an instance in the API

In the API, prefix matching does not occur and you must provide the full URL to your desired image in your request. For example, to create a root persistent disk in the API, you must provide the sourceImage query parameter with the full URI to your desired image, like so:

https://www.googleapis.com/compute/v1/projects/<project>/zones/<zone>/disks?sourceImage=<image-url>

<image-url> must have the following format. As an example, this URL points to a Centos image:

http://www.googleapis.com/compute/v1/projects/centos-cloud/global/images/centos-6-vYYYYMMDD

For more information, see the API reference.

Deprecating an image

Google Compute Engine lets you deprecate a private image that you own by setting the deprecation status on the image. Each deprecation status causes a different response from the server, helping you transition users away from unsupported images in a manageable way. Possible deprecation statuses are:

  • DEPRECATED - This image is considered deprecated. When users attempt to use this image, the request will succeed but Google Compute Engine also returns a warning. New links to this image are still allowed.
  • OBSOLETE and DELETED - This image is obsolete or deleted and new users cannot use it. Google Compute Engine returns an error if users try to use the image in their requests. Existing links to this image are still allowed. Note that marking an image as deleted restricts its usage but users still need to manually delete their images to remove it from the image list.

To set the deprecation status of an image in gcutil, use the gcutil deprecateimage command:

gcutil --project=<project-id> deprecateimage --state=<deprecation-state> --replacement=<fully-qualified-image-url> [--deleted_on=<date-time> --deprecated_on=<date-time> --obsolete_on=<date-time>] <image-name>

Important Flags and Parameters:

--project=<project-id>
[Required] The project ID where this image lives.
--state=<deprecation-state>
[Required] The state of the image. Valid values are:
  • DEPRECATED - This image is considered deprecated. When users attempt to use this image, the request will succeed but Google Compute Engine also returns an warning. New links to this image are still allowed.
  • OBSOLETE - This image is obsolete and new users cannot use it. Google Compute Engine returns an error if users try to use the image in their requests. Existing links to this image are still allowed.
  • DELETED - This image is deleted and users cannot use it. Google Compute Engine returns an error if users attempt to use the image.
--replacement=<fully-qualified-image-url>
[Required] Fully-qualified URL to a recommended replacement image.
--deprecated_on=<date-time>
[Optional] A valid RFC3339 timestamp indicating when the image was or will be deleted. This is purely informational. Google Compute Engine does not enforce these date and times (e.g. Google Compute Engine won't automatically mark an image as deprecated once the date-time is reached).
--deleted_on=<date-time>
[Optional] A valid RFC3339 timestamp indicating when the image was or will be deleted. This is purely informational. Google Compute Engine does not enforce these date and times (e.g. Google Compute Engine won't automatically mark an image as deleted once the date-time is reached). Instead, you will need to run gcutil deleteimage to delete your image. For more information, see Deleting an image.
--obsolete_on=<date-time>
[Optional] A valid RFC3339 timestamp indicating when the image was or will be obsolete. This is purely informational. Google Compute Engine does not enforce these date and times (e.g. Google Compute Engine won't automatically mark an image as obsolete once the date-time is reached).
<image-name>
[Required] The name of the image to deprecate.

Deleting an image

You can only delete images that you or someone who has access to the project has added. To delete an image, run:

gcutil --project=<project-id> deleteimage <image-name>

Important Flags and Parameters:

--project=<project-id>
[Required] The project ID where this image lives.
<image-name>
[Required] The name of the image to delete.

Creating an image from a root persistent disk

These instructions describe how to create a new private image based on an existing image running on a root persistent disk. This is ideal for situations where you may have created and then modified a persistent boot disk to a certain state and would like to save that state to be reused.

Note: These instructions describe how to create a new instance with a public or shared image, customize the root disk, and then create a new image based on that instance. If you already have an instance and root persistent disk for which you want to make an image, skip to step 3.

To create a new image:

  1. Start a new instance and log into it.
  2. Customize your instance by adding packages, configuring startup daemons, and so on.
  3. Create an image of your instance using gcimagebundle tool that comes installed on the default Google Compute Engine image.
  4. Upload an image into Compute Engine through Google Cloud Storage.
  1. (Optional) Start a new instance or log into an existing instance

    If you want to start a new instance and customize a public or shared image, follow steps 1 and 3. If you already have an existing instance and root persistent disk from which you want to make an image, skip to step 3.

    Review the details about starting a new instance if necessary. Start a new instance as follows:

    $ gcutil --project=<project-id> addinstance --service_account_scopes=storage-rw,compute-rw --image=<image-name> myinst

    Note that you're passing in service account scopes so that you can upload your file to Google Cloud Storage in later steps.

    ssh into your instance:

    $ gcutil --project=<project-id> ssh myinst
  2. (Optional) Customize your instance

    Customize your instance as you like. The following example demonstrates logging in and installing Apache on an instance:

    $ gcutil --project=<project-id> ssh myinst
    ...snip ssh startup info...
    me@myinst:~$ sudo apt-get install apache2
    ...snip installation process...
    
  3. Create a tar file of your image

    Note: It is not currently possible to create an image based on a Windows instance. However, you can take a persistent disk snapshot of the instance's root persistent disk.

    When you are finished customizing your OS, create an image and bundle it into a .tar.gz file. The gcimagebundle tool included in Google Compute Engine images will create an image of the instance for you. The image is stored as a raw block file, packaged and compressed using gzip and tar. The raw block file contains the OS and all installed packages, plus all files in the root persistent disk. It does not include files or packages in a non-root persistent disk.

    The gcimagebundle tool can be accessed by calling gcimagebundle on instances created from Google-provided images. For help, call python gcimagebundle --help

    To save an image of your instance, run the following command:

    me@myinst:~$ sudo gcimagebundle \
      -d /dev/sda -o /tmp/ --log_file=/tmp/abc.log
    

    This command will create an image of the instance in the following location:

    /tmp/<long-hex-number>.image.tar.gz
  4. Upload an image into Compute Engine

    To use a custom image in Compute Engine virtual machine instances, you must first upload the image to Google Cloud Storage, add the image to your Compute Engine project, and apply that image to your instances. Use the following instructions to help you add your image to Compute Engine.

    1. Upload your tar file to Google Cloud Storage

      You must store your tar file on Google Cloud Storage. You will later load the file from that location when adding your new image to your project.

      To upload the tar file to Google Cloud Storage, use the gsutil command line tool that comes preinstalled on your instance.

      1. Set up gsutil.

        If this is your first time using gsutil on this instance AND you didn't set up your instance to use a service account to talk to Google Cloud Storage, run gsutil config and follow the instructions. Otherwise, you can skip this step.

        Note: If your instance is set up with a service account scope to Google Cloud Storage and you run gsutil config, the command creates user credentials that are used by subsequent gsutil commands instead of the service account credentials that were previously used.

      2. Create a bucket.

        The following restrictions apply when you create a Cloud Storage bucket to store your image file:

        Create your bucket using the following command:

        me@myinst:~$ gsutil mb gs://<bucket-name>

        Note: You must enable billing for your Google Cloud Storage account before you can use the Google Cloud Storage service. To understand how Google Cloud Storage bills for usage, see their pricing table.


      3. Copy your file to your new bucket.
        me@myinst:~$ gsutil cp /tmp/<your-image>.image.tar.gz gs://<bucket-name>
    2. Add your customized image to the Images collection

      Log out of your instance by typing exit. Add your saved image to your project's Images list using gcutil on your local machine, as described below. When you add your image to the Images collection, you must choose an image name that is unique among all images in the project and specify the URI of your image in Google Cloud Storage, using the URI scheme shown below.

      $ gcutil --project=<project-id> addimage <image-name> <image-uri>

      Important Flags and Parameters:

      --project=<project-id>
      [Required] The project ID where this image should live.
      <image-name>
      [Required] A name for this new image. Your <image-name> must start with a lowercase letter, be followed by 0-62 lowercase letters, numbers, or hyphens, and cannot end with a hyphen.
      <image-uri>
      [Required] A fully-qualified Google Cloud Storage URI in either of the following formats:
      • gs://<bucket-name>/<your-image>.image.tar.gz
      • https://storage.googleapis.com/<bucket-name>/<your-image>.image.tar.gz

      You can check if the image is ready to use by performing a gcutil getimage call, with returns the image state as well. Once the image is READY, you can use it for your instances.

    3. Use your custom image

      Whenever you want to start a new instance with your custom image, specify the --image flag with the name that you assigned your image in the previous step:

      $ gcutil --project=my-project addinstance --image=<image-name> <instance-1> <instance-2> <instance-n>

      This differs slightly from using an unaltered Debian or CentOS image. You only need to specify the image name for your custom image when adding an instance, as opposed to the fully-qualified image name if you were using an unaltered Debian or CentOS image from the debian-cloud or centos-cloud image.

      If you choose to create multiple instances with one command, gcutil uses the same image for all of the instances and each instance will have its own unique IP address.

Building an image from scratch

Google Compute Engine is capable of running a variety of operating systems and you can build an image from scratch with the operating system of your choice and use it on Google Compute Engine virtual machines. However, Google Compute Engine is a unique environment, with certain requirements to ensure that all images run optimally. This section describes these requirements and is intended as an advanced topic geared towards users who would like to use their own images instead of relying on public images.

Building an image is an advanced task and Compute Engine suggests that only users that specifically need a new image should try to build an image from scratch.

Note This section provides general recommendations and information for building an image on Google Compute Engine. Depending on your operating system, the steps to build your image may differ and you should refer to your operating system's documentation for specific instructions.

Basic operating system configuration

This section describes how to configure a very basic image that can boot within an instance. These are general recommendations and may differ depending on your operating system. Refer to the operating system's documentation for specific instructions.

Recommended

  • Set the timezone to UTC:
    sudo ln -sf /usr/share/zoneinfo/UTC /etc/localtime
  • Use the Google NTP server, metadata.google.internal (169.254.169.254), and remove all other NTP servers.
  • Use tunefs to check disks at desired intervals.
  • Log syslog messages to /dev/ttyS0, so you can debug with gcutil getserialportoutput.

Optional

  • Enable FIPS mode.
  • Consider updating packages while building images, and then add logic to update packages on first boot.

Kernel configurations

You can choose to build and run arbitrary OS kernels on Google Compute Engine if they are compliant with the hardware manifest described below. The following guidelines will help you build your own kernel binaries.

Hardware Manifest

The following is a list of devices that your kernel must support:

  • vCPU:
    • Intel(R) Xeon(R) CPU @ 2.60GHz stepping 07
    • CPUID: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc up nopl xtopology pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes avx hypervisor lahf_lm
  • PCI Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
  • ISA bridge: Intel 82371AB/EB/MB PIIX4 ISA (rev 03)
  • Ethernet controller:
    • Virtio-Net Ethernet Adapter
    • vendor = 0x1AF4 (Qumranet/Red Hat), device id = 0x1000. Subsystem ID 0x1.
    • We support Checksum offload
    • We support TSO v4
    • We support UFO
  • SCSI Storage Controller:
    • Virtio-SCSI Storage Controller
    • vendor = 0x1AF4 (Qumranet/Red Hat)
    • device id = 0x1004. Subsystem ID 0x8.
    • We support SCSI Primary Commands 4, SCSI Block Commands 3
    • We support one request queue only
    • Persistent disks report 4 KiB physical sectors / 512 byte logical sectors;
    • We only support block devices (disks)
    • We support the Hotplug / Events feature bit
  • Serial Ports:
    • two 16550A ports
    • ttyS0 on IRQ 4
    • ttyS1 on IRQ 3

Required Linux Kernel Options

# to enable paravirtualization functionality.
CONFIG_KVM_GUEST=y

# to enable the paravirtualized clock.
CONFIG_KVM_CLOCK=y

# to enable paravirtualized PCI devices.
CONFIG_VIRTIO_PCI=y

# to enable access to paravirtualized disks.
CONFIG_SCSI_VIRTIO=y

# to enable access to the networking.
CONFIG_VIRTIO_NET=y

Network configuration

In order to ensure high performance network capability, we strongly recommend the following configurations. For more information about Google Compute Engine networks, read the Networking and Firewalls documentation.

Strongly recommended

  • Use ISC DHCP client. Other clients may be used but have not been tested.
  • For best performance, set MTU to 1460. Google Compute Engine's DHCP server will serve this parameter as the interface-mtu option, which most clients respect.

Recommended

  • Disable IPv6, as it is not supported.
  • Delete the hostname file. It will be set by startup script, /usr/share/google/set-hostname. To delete the hostname file:
    $ rm /etc/hostname
  • Make sure /etc/hosts includes these entries and add them if they aren't included:
    127.0.0.1 localhost
    169.254.169.254 metadata.google.internal metadata
  • Prevent the instance from remembering its MAC address.

Optional

  • Disable the operating system firewall, unless you want to restrict outbound traffic.
    • Google Compute Engine provides a firewall for inbound traffic. For more information on firewalls, read the Networking and Firewalls documentation.

Installing packages

Google Compute Engine requires a small set of packages to be installed to make sure that the operating systems runs smoothly.

Required packages

  • Python 2.6 or higher
  • sshd

Strongly recommended

When setting up your packages, make sure to:

  • Enable automatic updates
  • Update all packages to the latest version

Optional

Google Compute Engine image packages

Google provides a suite of tools that configure the operating system to work properly with Google Compute Engine. The source code for these tools is hosted on GitHub. For every release, we provide a tarball for each tool, as well as a tarball for the whole repository. Each of the tools is described below:

For information about each package, review the respective README.md files.

Note that some of these scripts may require customization to work with your distribution. If so, it is recommended that you clone this GitHub repository and make the changes in that repository. This allows your customizations to be separate from the canonical scripts and the convenience of merging in future improvements. Patches are welcome but require a third-party contributor agreement to be signed.

SSH configurations

Users typically log into instances via SSH. It is important to run your images with a secure SSH configuration.

Recommended

  • Disable root ssh login.
  • Disable password authentication.
  • Disable host based authentication.
  • Enable strict host key checking.
  • Use ServerAliveInterval to keep connections open.

Next, create a sshd stub file /etc/ssh/sshd_not_to_be_run with just the contents “GOOGLE\n”. Google daemon will generate ssh keys based on the ssh metadata.

Remove ssh host keys

Don't use ssh host keys with your instance. Remove them as follows:

rm /etc/ssh/ssh_host_key
rm /etc/ssh/ssh_host_rsa_key*
rm /etc/ssh/ssh_host_dsa_key*
rm /etc/ssh/ssh_host_ecdsa_key*

As an example, the following SSH configuration files provide a good starting point for defining your own configuration files. For your /etc/ssh/ssh_config file, start with the following configurations:

Host *
Protocol 2
ForwardAgent no
ForwardX11 no
HostbasedAuthentication no
StrictHostKeyChecking no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
Tunnel no

# Google Compute Engine times out connections after 10 minutes of inactivity.
# Keep alive ssh connections by sending a packet every 7 minutes.
ServerAliveInterval 420

For your /etc/ssh/sshd_config file, start with the following configurations:

# Disable PasswordAuthentication as ssh keys are more secure.
PasswordAuthentication no

# Disable root login, using sudo provides better auditing.
PermitRootLogin no

PermitTunnel no
AllowTcpForwarding yes
X11Forwarding no

# Compute times out connections after 10 minutes of inactivity.  Keep alive
# ssh connections by sending a packet every 7 minutes.
ClientAliveInterval 420

# Restrict sshd to just IPv4 for now as sshd gets confused for things
# like X11 forwarding.

Security recommendations

You should always provide a secure operating system environment but it can be difficult to strike a balance between a secure and accessible environment. While many of the precautions below are not absolutely required, we strongly urge you to enable them. Insecure virtual machines are vulnerable to attack and can consume expensive resources.

OS security best practices

  • Minimize the amount of software installed by default (e.g. perform a minimal install of the OS).
  • Enable automatic updates.
  • By default, all network services disabled except for ssh, dhcp, and ntpd. You can allow a mailserver, such as postfix, to run if it is only accepting connections from localhost.
  • Do not allow externally listening ports except for sshd.
  • Install the denyhosts package to help prevent SSH brute-force login attempts.
  • Remove all unnecessary non-user accounts from the default install.
  • Set the shell of all non-user accounts to /sbin/nologin or /usr/sbin/nologin (depending on where your OS installed nologin) in /etc/passwd.
  • Configure your OS to use salted SHA512 for passwords in /etc/shadow.
  • Set up and configure pam_cracklib for strong passwords.
  • Set up and configure pam_tally to lock out accounts for 5 minutes after 3 failures.
  • Configure the root account to be locked by default in /etc/shadow. Run the following command to lock the root account:
    usermod -L root
  • Deny root in /etc/ssh/sshd_config by adding the following line:
    PermitRootLogin no
  • Create AppArmor or SELinux profiles for all default running network-facing services.
  • Use filesystem capabilities where possible to remove the need for the S*ID bit and to provide more granular control.
  • Enable compiler and runtime exploit mitigations when compiling network-facing software. For example, here are some of the mitigations that the GNU Compiler Collection (GCC) offers and how to enable them:
    • Stack smash protection: Enable this with -fstack-protector. By default, this option protects functions with a stack-allocated buffer longer than eight bytes. To increase protection by covering functions with buffers of at least four bytes, add --param=ssp-buffer-size=4.
    • Address space layout randomization (ASLR): Enable this by building a position-independent executable with -fPIC -pie.
    • Glibc protections: Enable these protections with -D_FORTIFY_SOURCE=2.
    • Global Offset Table (GOT) protection: Enable this runtime loader feature with -Wl,-z,relro,-z,now.
    • Compile-time errors for missing format strings: -Wformat -Wformat-security -Werror=format-security
  • Disable CAP_SYS_MODULE, which allows for loading and unloading of kernel modules. This feature is deprecated in the linux kernel. To disable this feature:
    echo 1 > /proc/sys/kernel/modules_disabled
  • Remove the kernel symbol table:
    sudo rm /boot/System.map
  • Disable booting a new kernel from the current one via the kexec() system call and KEXEC option in reboot().
    • Add LOAD_EXEC=false in /etc/default/kexec
    • Uninstall kexec-tools.

Kernel build options

The following options are security settings that Google Compute Engine recommends when building your own kernel:

Strongly recommended

It is strongly recommended that you set the following options when building your kernel.

  • CONFIG_STRICT_DEVMEM=y
    • Restrict /dev/mem to allow access to only PCI space, BIOS code and data regions.
  • CONFIG_DEVKMEM=n
    • Disable support for /dev/kmem.
    • Block access to kernel memory.
  • CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
    • Set low virtual memory that is protected from userspace allocation. To set this value, run the following:
      echo "vm.mmap_min_addr = 0" > /etc/sysctl.d/mmap_min_addr.conf

      For more information, see DEFAULT_MMAP_MIN_ADDR and mmap_min_addr.

  • CONFIG_DEBUG_RODATA=y
    • Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const data. This option may have a slight performance impact because a portion of the kernel code won't be covered by a 2MB TLB anymore.
  • CONFIG_DEBUG_SET_MODULE_RONX=y
    • Catches unintended modifications to loadable kernel module's text and read-only data. This option also prevents execution of module data.
  • CONFIG_CC_STACKPROTECTOR=y
    • Enables the -fstack-protector GCC feature. This feature puts a canary value at the beginning of critical functions, on the stack just before the return address, and validates the value just before actually returning. This also causes stack-based buffer overflows (that need to overwrite this return address) to overwrite the canary, which gets detected and the attack is then neutralized using a kernel panic.
  • CONFIG_COMPAT_VDSO=n
    • Ensures the VDSO isn’t at a predictable address to strengthen ASLR. If enabled, this feature would map the VDSO to the predictable old-style address, providing a predictable location for exploit code to jump to. Say N here if you are running a sufficiently recent glibc version (2.3.3 or later), to remove the high-mapped VDSO mapping and to exclusively use the randomized VDSO.
  • CONFIG_COMPAT_BRK=n
    • Don’t disable heap randomization.
  • CONFIG_X86_PAE=y
    • Set this option for a 32 bit kernel, as PAE is required for NX support. This also enables larger swapspace support for non-overcommit purposes.
  • CONFIG_SYN_COOKIES=y
    • Provides some protection against SYN flooding.
Recommended
  • CONFIG_SECURITY_YAMA=y
    • This selects Yama, which extends DAC support with additional system-wide security settings beyond regular Linux discretionary access controls. Currently, the setting is ptrace scope restriction.
  • CONFIG_SECURITY_YAMA_STACKED=y
    • This option forces Yama to stack with the selected primary LSM when Yama is available.

Kernel security settings

A great way to harden the security of the kernel is through the kernel settings file, /etc/sysctl.conf. The following settings are recommended when setting up the file:

Strongly recommended
# enables syn flood protection
net.ipv4.tcp_syncookies = 1

# ignores source-routed packets
net.ipv4.conf.all.accept_source_route = 0

# ignores source-routed packets
net.ipv4.conf.default.accept_source_route = 0

# ignores ICMP redirects
net.ipv4.conf.all.accept_redirects = 0

# ignores ICMP redirects
net.ipv4.conf.default.accept_redirects = 0

# ignores ICMP redirects from non-GW hosts
net.ipv4.conf.all.secure_redirects = 1

# ignores ICMP redirects from non-GW hosts
net.ipv4.conf.default.secure_redirects = 1

# don't allow traffic between networks or act as a router
net.ipv4.ip_forward = 0

# don't allow traffic between networks or act as a router
net.ipv4.conf.all.send_redirects = 0

# don't allow traffic between networks or act as a router
net.ipv4.conf.default.send_redirects = 0

# reverse path filtering - IP spoofing protection
net.ipv4.conf.all.rp_filter = 1

# reverse path filtering - IP spoofing protection
net.ipv4.conf.default.rp_filter = 1

# reverse path filtering - IP spoofing protection
net.ipv4.conf.default.rp_filter = 1

# ignores ICMP broadcasts to avoid participating in Smurf attacks
net.ipv4.icmp_echo_ignore_broadcasts = 1

# ignores bad ICMP errors
net.ipv4.icmp_ignore_bogus_error_responses = 1

# logs spoofed, source-routed, and redirect packets
net.ipv4.conf.all.log_martians = 1

# log spoofed, source-routed, and redirect packets
net.ipv4.conf.default.log_martians = 1

# implements RFC 1337 fix
net.ipv4.tcp_rfc1337 = 1

# randomizes addresses of mmap base, heap, stack and VDSO page
kernel.randomize_va_space = 2
Recommended
# provides protection from ToCToU races
fs.protected_hardlinks=1

# provides protection from ToCToU races
fs.protected_symlinks=1

# makes locating kernel addresses more difficult
kernel.kptr_restrict=1

# set ptrace protections
kernel.yama.ptrace_scope=1

# set perf only available to root
kernel.perf_event_paranoid=2

Packaging the image

A Google Compute Engine image is a gzipped tarball that contains the raw disk file. When an image is added, Google Compute Engine validates the contents of the image to ensure it can be used. Google Compute Engine offers the gcimagebundle tool which can package your image for you. To use gcimagebundle to package your image, run:

sudo gcimagebundle -d <boot-device> -o <output-directory>

If you would like to package the image yourself, use the following requirements for the image format.

Requirements

Your archive must satisfy these requirements before it can be added to Google Compute Engine.

  • The archive must be a valid gzipped tarball with the extension .tar.gz.
  • The tar format must be GNU or old-GNU format.
  • Operating system images must have a disk.raw file that is no larger than 10GB. For non-OS images, the disk.raw file can be as large as 30GB.
  • Non-boot images have an uncompressed size limit of 30 GB for disk.raw.
  • The disk.raw file must have an MS-DOS (MBR) partition table.

Strongly recommended

The following recommendations prevent the image from using more space than necessary, which reduces the overall storage cost of the image.

  • Create your tarball as sparse.
  • Create your disk.raw as sparse.

See the Create a blank image file example below.

Partitions

Images can have any primary and secondary partitioning scheme that is compatible with the MS-DOS partition table. Google-supplied images typically have the following partitioning scheme:

  • MS-DOS partition table
  • 1 primary ext4 formatted partition

Example: Create a blank image file

The following is an example script that describes how to create a blank image file. Note that this script is an example and your own experience may vary.

# Create sparse blank disk file.
$ truncate disk.raw ${DISK_SIZE_MB}

# If you can’t use truncate use dd instead.
# dd if=/dev/zero of=file.img bs=1 count=0 seek=${DISK_SIZE_MB}M

# Create MS-DOS partition table.
$ parted disk.raw mklabel msdos

# Create primary partition as ext4
$ parted disk.raw mkpart primary ext4 1 ${DISK_SIZE_MB}

# Create compressed and sparse image tarball
$ tar -Szcf image.tar.gz disk.raw

Upload an image into Compute Engine

To use a custom image in Compute Engine virtual machine instances, you must first upload the image to Google Cloud Storage, add the image to your Compute Engine project, and apply that image to your instances. Use the following instructions to help you add your image to Compute Engine.

  1. Upload your tar file to Google Cloud Storage

    You must store your tar file on Google Cloud Storage. You will later load the file from that location when adding your new image to your project.

    To upload the tar file to Google Cloud Storage, use the gsutil command line tool that comes preinstalled on your instance.

    1. Set up gsutil.

      If this is your first time using gsutil on this instance AND you didn't set up your instance to use a service account to talk to Google Cloud Storage, run gsutil config and follow the instructions. Otherwise, you can skip this step.

      Note: If your instance is set up with a service account scope to Google Cloud Storage and you run gsutil config, the command creates user credentials that are used by subsequent gsutil commands instead of the service account credentials that were previously used.

    2. Create a bucket.

      The following restrictions apply when you create a Cloud Storage bucket to store your image file:

      Create your bucket using the following command:

      me@myinst:~$ gsutil mb gs://<bucket-name>

      Note: You must enable billing for your Google Cloud Storage account before you can use the Google Cloud Storage service. To understand how Google Cloud Storage bills for usage, see their pricing table.


    3. Copy your file to your new bucket.
      me@myinst:~$ gsutil cp /tmp/<your-image>.image.tar.gz gs://<bucket-name>
  2. Add your customized image to the Images collection

    Log out of your instance by typing exit. Add your saved image to your project's Images list using gcutil on your local machine, as described below. When you add your image to the Images collection, you must choose an image name that is unique among all images in the project and specify the URI of your image in Google Cloud Storage, using the URI scheme shown below.

    $ gcutil --project=<project-id> addimage <image-name> <image-uri>

    Important Flags and Parameters:

    --project=<project-id>
    [Required] The project ID where this image should live.
    <image-name>
    [Required] A name for this new image. Your <image-name> must start with a lowercase letter, be followed by 0-62 lowercase letters, numbers, or hyphens, and cannot end with a hyphen.
    <image-uri>
    [Required] A fully-qualified Google Cloud Storage URI in either of the following formats:
    • gs://<bucket-name>/<your-image>.image.tar.gz
    • https://storage.googleapis.com/<bucket-name>/<your-image>.image.tar.gz

    You can check if the image is ready to use by performing a gcutil getimage call, with returns the image state as well. Once the image is READY, you can use it for your instances.

  3. Use your custom image

    Whenever you want to start a new instance with your custom image, specify the --image flag with the name that you assigned your image in the previous step:

    $ gcutil --project=my-project addinstance --image=<image-name> <instance-1> <instance-2> <instance-n>

    This differs slightly from using an unaltered Debian or CentOS image. You only need to specify the image name for your custom image when adding an instance, as opposed to the fully-qualified image name if you were using an unaltered Debian or CentOS image from the debian-cloud or centos-cloud image.

    If you choose to create multiple instances with one command, gcutil uses the same image for all of the instances and each instance will have its own unique IP address.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.