TAPP Review: Barracuda WAF Module

barracuda_waf_module_review.md

barracudanetworksindia/puppet-cudawafaws

Reference documentation:

• Puppet Visual Index
• Puppet Type Reference
• Puppet Style Guide
• Puppet Facter: Core Facts
• Puppet Custom Functions
• Puppet Custom Facts
• Puppet: Updating manifests for 3.x to 4.x

General Notes:

• Modules written do not make use of Puppet DSL
  • All modules should be rewritten to take advantage of capabilities within Puppet DSL rather than relying on Ruby scripts
• Adherence to Puppet Style
  • Please review the Puppet Style Guide
  • For instance, alignment of hash rockets
• Puppet types have weak to no validation
  • Should bolster your types by providing constraints on user provided data and conformance standards
• Puppet manifest classes are not documented in known standards
  • puppet describe face depends on Puppet strings style of documentation
    • Reference: Puppet strings
    • Example: init.pp from puppetlabs/ntp
• Data types should be used for parameters in Puppet DSL classes
  • Data types
  • Abstract data types
• Puppet DSL should contain data validation
  • Should provide proper validation of data provided by module users
    • Use data types where possible as this will provide basic validation
    • Provide additonal validation via custom functions
      • Example: validate_ipaddress
• Modules folder should not be included in module
  • Each module owned by Barracuda should be submitted to the Forge separately or should be managed within this module
  • Any module not owned by Barracuda but on Puppet Forge should be listed as a dependency in the metadata.json file
• Hieradata folder should not exist in module
  • Example Hiera data should be provided in Markdown (README format)
    • Syntax highlighting in GitHub Markdown
    • Languages supported by GitHub Markdown syntax highlighting
• Environment.conf should not exist in repository exposed for customer use
  • Remove file

README.md

• README should be written out to follow a similar style used by Puppet
  • Example: puppetlabs/ntp/README.MD

manifests/site.pp.example

• File should not exist in customer facing repository as it can cause confusion

manifests/site.pp

• Node definitions should not exist in customer facing repository (site.pp)
  • Node definition examples should be provided in GitHub Markdown since Puppet is a supported language)

modules/aws

• Should be removed as this can be listed as a dependency in metadata.json of a respective module

modules/awscudawafconfig/manifests/init.pp

• Class contains no code
  • Remove unnecessary init.pp since it is not required

modules/awscudawafconfig/manifests/config.pp

• Resource attributes should be exposed as parameters to make modules as flexible as possible for customer use
  • Example: puppetlabs/ntp/init.pp
• Word style ordering metaparameters preferred for linking resource types
  • require, before, subscribe, notify over arrows when ordering resource types
    • Puppet type ordering

modules/awscudawafconfig/cuda-wafconfig

• Not sure why file exists

modules/awscudawafconfig/files/config_full_new.rb

• Running a script to accomplish what is possible within Puppet is an antipattern
  • Refactor code to make use of EPP templating

modules/vrsinaws/manifests/init.pp

• Class contains no code
  • Remove unnecessary init.pp since it is not required

modules/vrsinaws/manifests/vrsconfig.pp

• Resource attributes should be exposed as parameters to make modules as flexible as possible for customer use
  • Example: puppetlabs/ntp/init.pp
• Word style ordering metaparameters preferred for linking resource types
  • require, before, subscribe, notify over arrows when ordering resource types
    • Puppet type ordering

modules/vrsinaws/files/configure_vrs.rb

• Running a script to accomplish what is possible within Puppet is an antipattern
  • Refactor code to make use of EPP templating

modules/wafloginforaws/manifests/init.pp

• Resource attributes should be exposed as parameters to make modules as flexible as possible for customer use
  • Example: puppetlabs/ntp/init.pp
• Word style ordering metaparameters preferred for linking resource types
  • require, before, subscribe, notify over arrows when ordering resource types
    • Puppet type ordering

modules/wafloginforaws/files/waflogintoken.rb

• Running a script to accomplish what is possible within Puppet is an antipattern
  • Refactor code to make use of EPP templating

modules/ntp

• Should be removed as this can be listed as a dependency in metadata.json of a respective module

modules/profiles

• Should be provided in GitHub Markdown since Puppet is a supported language)
• Design pattern for Profiles indicates classes should be namespaced as child classes only
  • profile::cuda_aws vs profile or profiles

modules/roles

• Should be provided in GitHub Markdown since Puppet is a supported language)
• Design pattern for Profiles indicates classes should be namespaced as child classes only
  • role::cuda_aws vs role or roles

modules/stdlib

• Should be removed as this can be listed as a dependency in metadata.json of a respective module