Support Center > Search Results > SecureKnowledge Details
CloudGuard Network Security Automation for KVM Based Platforms Technical Level
Solution

Overview

This article describes how cloud-init automation within the CloudGuard IaaS image can be leveraged to bootstrap a virtual machine built to run on the KVM hypervisor by various platforms. The bootstrap process includes multiple methods of user-data input as well as user-data formats. As of this writing, these Generic and OpenStack images are provided by the Check Point Cloud Alliance or Telco teams at customer request. The automation descibed within will be added to Generally Available images in the future.


Metadata Input Methods

Config Drive

The most common method of providing metadata is a config drive. A config drive is a predefined file structure of VM configuration information that is contained in a specially labeled ISO and then attached at VM creation time. Upon first boot, the OS starts a bootstrapping service that searches for this mounted ISO via a blkid label and\or filesystem type and then reads the metadata from the file structure. It is possible to input basic VM meta information or complex multi-part scripts, service provider logos and more via this method.

While Check Point references the standards of cloud-init, some variations may exist. The Check Point image with this updated bootstrapping utilizes a naming convention that distinguishes the image automation within the image Generic and OpenStack.


HTTP metadata service

Virtual machine information may be polled from an HTTP metadata service within OpenStack KVM platform providers. Be aware that not all OpenStack or KVM operators enable this service. The data available via the HTTP meta-service is the same as what is provided via config drive (vendor, network, meta, and user data). The CG IaaS bootstrap service shows preference to a mounted config drive at first boot; when an attached config drive is not detected, the bootstrap service will attempt to poll the http service for the configuration data. One benefit of HTTP metadata vs. config drive is that it is dynamic, presenting network interface changes to the VM post deployment. Conversely, config drive data is only populated by the platform at VM instantiation.


Check Point OpenStack Labeled QCOW Image Requirements

  1. ISO label is set as "config-2"
  2. The file structure for an OpenStack deployment has the following requirements:
    1. The configuration files (vendor, network, meta, and user data) must be placed in the ISO /openstack/latest/ directory by the platform.
    2. vendor_data.json
      1. Check Point does not utilize this file.
    3. network_data.json
      1. May specify DHCP or static interface configurations per interface.
      2. If configured as DHCP, the bootstrapping automation polls for a DHCP provided address on specified interfaces, consumes that DHCP address, and statically assigns it to the interface.
    4. meta_data.json
      1. SSH Key
      2. Virtual machine name is provided by the platform. This VM name is consumed as the OS hostname unless a hostname is specified in user_data.
    5. user_data
      1. 16k file limit
      2. Description of additional data provided in user_data section.

Check Point Generic Labeled QCOW Image Requirements

  1. ISO must be type “ISO9660”
  2. The ISO file structure has the following requirements:
    1. The user_data file can be placed anywhere within the ISO (Check Point recommends the root directory).
    2. 16k file limit
    3. Description of additional data provided in the user_data section.
  3. Generic images DHCP note
    1. Generic images rely on interface addressing/configuration to be provided in the user_data file.
    2. If no interface data is provided, the on-boarding service will attempt to configure eth0 with a static IP, obtained via DHCP. 

Check Point user_data Customization Formats

  1. This section applies to both OpenStack and Generic images.
  2. User_data may be provided via HTTP metadata service or config drive; not all platform operators enable HTTP metadata services.
  3. Config Drive ISO file structure has the following options:
    1. The Check Point bootstrapping service will parse user_data and determine the format of the scripts to parse automatically.
    2. user_data has no format requirement besides properly following the convention of the chosen file format.
    3. The order of operation for the Check Point bootstrapping service (also known as “Just deplOy Everything” ) is MIME, cloud-config, and bash.
    4. In the event that MIME or cloud-config are not detected, the user_data is processed as a bash script.
    5. The user_data file may be presented as cloud-config in a yaml format.
    6. user_data may be presented as bash format.
    7. user_data may be presented as multi-part mime format.
    8. This method supports text/cloud-config and text/x-shellscript.
      1. An example of when to use multi-part mime is terraform templates.
      2. For complex configurations using a mixture of cloud-config and bash it is suggested to utilize multi-part mime.

Examples

Cloud-config user_data gateway yaml

The minimum group of settings required for a proper cloud-config Gateway deployment include:

  • blink_config
  • ssh_authorized_keys

    #Example file. Removing a stanza will result in system defaults for that section.
#cloud-config
blink_config:   configure: "true"   gateway_cluster_member: "false"   download_info: "true"   upload_info: "true"   ftw_sic_key: "vpn123"
ssh_authorized_keys: - ssh-rsa AAAAB3NzV1zfVGaJD801Xt6EiQ2LWPEwVc3e5GsCkCgWyBb6HLkMyR0VLZzM7QLrXJgcC/ dev@dev - ssh-rsa /8tiDGO2Ngq5O59igrKM/Q8X+yFKakISNbOg+iV8bZsPdLKfIjpb1HELFKe+eFijmbqzT replace@me
system:   hostname: CloudGuard   domainname: labnet.com   dns1: 1.1.1.1   dns2: 8.8.8.8   dns3: 4.2.2.2   ntp1:     address: ntp.checkpoint.com     version: 4   ntp2:     address: ntp2.checkpoint.com     version: 4
# Please configure interfaces per OpenStack or Generic image instructions !!!!!
interfaces:   - name: eth0     ipv4-address: 192.168.1.35     subnet-length: 24   - name: eth1     ipv4-address: DHCP
routing:   static:     - dst: 4.2.2.4/32       nexthop: 1.0.1.1     - dst: 1.1.1.1/32       nexthop: 10.0.2.1     - dst: 4.3.2.0/24       nexthop: eth0     - dst: 4.3.2.8/32       nexthop: blackhole
cpusers: - name: admin   shell: /bin/bash   password-hash: - name: expert   password-hash: $1$Gz8EHpk6$L7YYYtIN6zThsBp0n6cAI0 - name: john   password-hash: $1$Gz8EHpk6$L7YYYtIN6zThsBp0n6cAI0   shell: /bin/cli.sh   ssh_authorized_keys:     - ssh-rsa $1$6CogNXN/$G0dWAbB0/KCY.HEzuLa8uexamplekey123 dev@dev - name: joe   password-hash: $1$Gz8EHpk6$L7YYYtIN6zThsBp0n6cAI0   shell: /bin/bash   ssh_authorized_keys:     - ssh-rsa $1$6CogNXN/$G0dWAbB0/KCY.HEzuLa8uexamplekey123 replace@me
clishcmd: - 'set as 6408.45314' - 'set as 6408.45314' - 'set bgp external remote-as 6408.45312 on' - 'set bgp external remote-as 6408.45312 local-address 100.100.1.3 on' - 'set bgp external remote-as 6408.45312 description INSIDE' - 'set bgp external remote-as 6408.45312 peer 100.100.1.1 on' - 'set bgp external remote-as 6408.45312 peer 100.100.1.1 ping on' - 'set bgp external remote-as 6408.45313 on' - 'set bgp external remote-as 6408.45313 local-address 100.100.1.13 on' - 'set bgp external remote-as 6408.45313 description OUTSIDE' - 'set bgp external remote-as 6408.45313 peer 100.100.1.11 on' - 'set bgp external remote-as 6408.45313 peer 100.100.1.11 ping on'
write_files: - path: /home/admin/write_files   permissions: '0644'   owner: admin:root   content: |     My file content
- path: /home/admin/base64_write_files.jpeg   permissions: '0644'   owner: admin:root   encoding: b64   content: |     /9j/4AAQSkZJRgABAQIAJgAmAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB     AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB     5peaMhIa91kjG_THIS_IS_A_BASE_64_ENCRYPTED_JPG_Zm3I7ihjxrlw0pLNDneVDlrVc0pNFW     hxtDiqSmnDXRV_THIS_IS_JUST_AN_EXAMPLE_NOT_REQUIRED_sS+Mus+8s+7P8ivNyL+FY/l5P     +YrxlNn4ir7yr/NGYYf7Uv8Asf0eHxkzvYj+bHnzwIZF/fGh/wA26/6WJ4ylyf6X+lvm7GDH1g/w     K4D/ACq4f9GuHjMvP//Z

Cloud-config user_data Security Management Server yaml

As of this writing, SMS Generic and OpenStack images are NOT blink enabled. These images utilize the same deployment mechanism Check Point has embedded for some time. The config_system stanza will accept any input that is referenced in sk69701.


  # Non-Blink All-In-One (SMS + GW) or SMS images only!!!!! 
#cloud-config
config_system:   configure: "true"   hostname: SMS   mgmt_admin_name: "admin"   mgmt_admin_passwd: "vpn123"   mgmt_gui_clients_radio: any   install_security_managment: "true"   install_security_gw: "false"   install_mgmt_primary: "true"   install_mgmt_secondary: "false"   download_info: "true"   upload_info: "true"   mgmt_gui_clients_radio: any   primary: 1.1.1.1   secondary: 8.8.8.8   tertiary: 4.2.2.1   ntp_primary: ntp.checkpoint.com   ntp_primary_version: 4   ntp_secondary: ntp2.checkpoint.com   ntp_secondary_version: 4

Blink (bash) Gateway user_data

While sk120193 describes blink operations in detail, the blink function within the Generic and OpenStack image only accept the following example.


  #!/bin/bash
  adminHash='$1$Gz8EHpk6$L7YYYtIN6zThsBp0n6cAI0'
  sicKey="vpn123"
  allowUpload="true"
  allowDownload="true"
  clusterMember="false"
  #
  echo "begin blink" >> /var/log/run-cloud-user-data

  blink_config -s
  "gateway_cluster_member=${clusterMember}&ftw_sic_key=${sicKey}&upload_info=${allowUpload}&download_info=${allowDownload}"
  echo "end blink" >> /var/log/run-cloud-user-data

  #

Adding simple clish commands to this same user_data example enables more complex configurations:


  #!/bin/bash
  adminHash='$1$Gz8EHpk6$L7YYYtIN6zThsBp0n6cAI0'
  sicKey="vpn123"
  allowUpload="true"
  allowDownload="true"
  clusterMember="false"
  #
  echo "begin blink" >> /var/log/run-cloud-user-data

  blink_config -s
  "gateway_cluster_member=${clusterMember}&ftw_sic_key=${sicKey}&upload_info=${allowUpload}&download_info=${allowDownload}"
  echo "end blink" >> /var/log/run-cloud-user-data

  #
  clish -c "lock database override"
  #clish -c "set user admin shell /bin/bash" -s
  clish -c "set user admin password-hash ${adminHash}" -s
  clish -c "set interface eth0 ipv4-address 120.120.120.113 mask-length 24" -s
  clish -c "set interface eth0 state on" -s
  clish -c "set static-route default nexthop gateway address 120.120.120.29 priority 1 on" -s
  clish -c "set hostname CP_Hostname" -s
  echo "end config" >> /var/log/run-cloud-user-data

  

ISO Creation

There are various tools to create an ISO, genisofs, mkisofs and xorriso are the most common.

  • bash_prompt:> genisoimage -output /tmp/myUserData-gw.iso -volid config-2 -joliet -r ~/cloud-init/myUserData/openstack.gw/
  • bash_prompt:> mkisofs -r -V config-2 -o /tmp/myUserData-gw.iso /tmp/cloud-init/myUserData/openstack.gw/
  • bash_prompt:> xorriso -as mkisofs -o /tmp/myUserData-gw.iso /tmp/cloud-init/myUserData/openstack.gw/
This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.
Applies To:
  • openstack
  • kvm
  • bootstrapping
  • cloud-init

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment