Home > Blogs > OpenStack Blog for VMware


A Deeper Look Into OpenStack Policy Update

Written by Xiao Gao, with valuable feedbacks and inputs from Mark Voelker.

While working with customers that are switching over to VMware Integrated OpenStack (VIO) from a different OpenStack distribution, customers expressed the need to update policies. Reasons were:

  • Backward compatibility with their legacy OpenStack deployment.
  • Internal company process and procedure alignment.

While updating policy is not any more complicated on VIO when compared to other distributions, it is an operation that we traditionally advised our customers to avoid. Following are some of the reasons:

1). Upgrade. While many non-default changes can seem trivial and straightforward, VMware can’t guarantee upstream implementation will always be backward compatible when moving between releases. Therefore, responsibility of maintaining day-2 changes lies within the customer

2). Snowflake avoidance.  Upstream gate tests focus almost exclusively on default policies. The risk of exposing unexpected side effect increases when the security posture of an operation is relaxed or tightened.  Security is also a concern when relaxing policies.  Similarly, most popular OpenStack orchestration/monitoring tools such as Terraform, Gophercloud, or Nagios are implemented assuming default policies. When policies are made more restrictive, it can cause your favorite OpenStack tools to fail.

Snowflakes not only are difficult to support and maintain, often cause of unexpected outages.

3). Leverage external CMP for enhanced governance and control. External CMP such as the vRA is designed to integrate business processes into IAAS consumption. Instead of maintaining low-level policies changes, leverage out of box capabilities of vRA to control what users will have access to.

 

 

Implementation Options:

We understand there are scenarios where policy changes are required. Our recommendation for those scenarios is to leverage VIO custom playbook to make those changes.  The basic idea behind custom playbook:

  1. Customer will code up what has to change using Ansible.
  2. VIO will decide when to make required changes, to survive upgrades and other maintenance tasks.

While VIO doesn’t sanction contents of the custom playbook, it’s essential to write the playbook in a manner that is modular and agnostic to the OpenStack version.  Ideal playbook should be stateless, grouped based on operational action, and not restrictive towards alignment with the upstream (see example section for details).  Loggings is on by default.

Working Example:

Let’s look at an example.  Say we want regular users to be able to create shared networks.  To do that we need to modify /etc/neutron/policy.json and change:

“create_network:shared”: “rule:admin_only”

to:

“create_network:shared”: “”

There is number of ways to accomplish above task.  You can go down the path of j2 templates and introduce variables for each policy modification.  But this approach requires discipline from the operator to update his/her entire set of j2 policy template(s) before any significant upgrade to avoid drift or conflicts with upstream.  On the other hand, if you leverage direct file manipulation method, you will change only parameters that are required in your local environment, and leave everything else in constant alignment with upstream.

Below example uses lineinfile to manipulate files directly:

# The custom playbook is run on initial deployment configuration, on a patch,
# or on an upgrade.  It can also be run via the viocli command line:
#   viocli deployment run-custom-playbook
#
# Copy this file and all supporting files to:
#   /opt/vmware/vio/custom/custom-playbook.yml
#
---
- hosts: controller
  sudo: true
  any_errors_fatal: true

  tasks:
    - name: stat check for policy.json
      stat: path=/etc/neutron/policy.json
      register: policy_stat

- hosts: controller
  sudo: true
  any_errors_fatal: true

  tasks:
    - name: backup policy.json
      command: cp /etc/neutron/policy.json /etc/neutron/policy.{{ lookup('pipe', 'date +%Y%m%d%H%M%S') }}.json
      when: policy_stat.stat.exists

- hosts: controller
  sudo: true
  any_errors_fatal: true

  tasks:
    - name: custom playbook - allow users to create shared networks
      lineinfile:
        dest: /etc/neutron/policy.json
        regexp: "^(\\s*){{ item.key }}:\\s*\".*\"(,?)$"
        line: "\\1{{ item.key }}: {{ item.value }}\\2"
        backrefs: yes
      with_dict: {'"create_network:shared"': '""’ }

example uses back references (e.g., the parenthesis in the “regex” line and the \\1 and \\2 in the “line” line) to preserve the indentation/leading spaces on the beginning of each line and the comma at the end of the line (if it’s present).  Back reference makes the regex a tad more complicated-looking, and it keeps the formatting in place.

Log Outputs:

Below are sample logs:

 

 

 

 

 

 

Conclusion

This post outlined thought processes involved when updating OpenStack Policies.  I would love to hear back from you.

Also, VIO 4.1 is now GA.  You can Download a 60-day VIO evaluation now and get started.

This entry was posted in OpenStack Consumption, OpenStack on VMware, Technical, VMware Integrated OpenStack and tagged on by .

About Xiao Gao

Xiao Hu Gao is the Senior Technical Marketing Manager for OpenStack at VMware. He enjoys speaking to customers and partners about the benefits of using OpenStack with VMware technologies. Xiao has a background in DevOps, Data Center Design, and Software Defined Networking. Xiao holds CCIE certification #3000 and have filed several patents in the areas of Security and Cloud.

Leave a Reply

Your email address will not be published. Required fields are marked *

*