A RUDDER walkthrough: manage your configurations through compliance

🎥 https://www.youtube.com/watch?v=ggrQwkpjtp8
🧑 Alexis Mousset
📅 Configuration Management Camp 2020

This talk is designed for people wanting to discover or learn more about how things are done on a day-to-day basis with Rudder. Based on our experience helping Rudder users achieve their automation and compliance goals, this session will detail real-world examples, and describe and explain step-by-step the development and application of policies.

We will cover:

• policy development workflow (advanced reporting analysis, debugging methods)
• best practices in policy organization
• various productivity tips
• reporting and compliance focused policies (component names, rules organization, et.)
• commonly encountered problems
• API usage to collect information (Excel export, ...)
• audit vs. configuration

Transcript

1. RUDDER WALKTHROUGH
   
   1
   

   View Slide

2. RUDDER INTRODUCTION
   
   2
   

   View Slide

3. Introduction
   The goal is to give you an idea of what it’s like to
   work with RUDDER
   •
   Start from the basics but quickly go to more
   interesting parts
   •
   Focus on new features for people who already know
   RUDDER
   •
   
   3
   

   View Slide

4. What’s
   RUDDER?
   Configuration Management?
   •
   Yes, but automating configuration is not enough!
   •
   Built on configuration management abilities
   •
   
   4
   

   View Slide

5. What’s
   RUDDER?
   RUDDER is a tool that allows:
   Configuring systems
   •
   Auditing systems
   •
   Maintaining security guidelines
   •
   Providing compliance reports
   •
   
   5
   

   View Slide

6. Technically
   A central server containing:
   •
   A git repo with all configuration templates
   •
   A database of managed nodes with complete inventories
   •
   A database of reporting about whats happens on the managed
   systems
   •
   An agent on each managed system, that downloads
   and applies the policies
   •
   
   6
   

   View Slide

7. Architecture
   
   7
   

   View Slide

8. What’s
   RUDDER?
   A Rudder node is a machine managed by Rudder. In
   order to manage a machine with Rudder you need to:
   Install the Rudder agent on it
   •
   Configure the agent, to set its reference server
   (called its policy server)
   •
   Accept the machine on the server
   •
   
   8
   

   View Slide

9. Our goal
   today
   Deploy and configure osquery on our infrastructure
   •
   Ensure our configuration complies with CIS
   guidelines
   •
   Provide efficient compliance visualization
   •
   
   9
   

   View Slide

10. POLICY DESIGN
    
    10
    

    View Slide

11. General dev
    process
    Everything can be done from the same interface.
    Classify nodes with groups
    •
    Design the policy templates named techniques
    •
    Creates instances of the templates called directives
    •
    Apply policy instances to groups using rules
    •
    Check outcome
    •
    … Repeat!
    •
    
    11
    

    View Slide

12. NODES AND GROUPS
    
    12
    

    View Slide

13. Nodes
    A node is a computer with a Rudder agent
    •
    Includes inventory and configuration agent
    •
    Inventory is there for classification (and source of
    config data)
    •
    
    13
    

    View Slide

14. Node
    properties
    Node properties are node data filled by the user Key-
    value store associated to each node,
    Values can be:
    Configurable from:
    String
    •
    JSON
    •
    Web interface
    •
    API
    •
    Third party plugins
    •
    
    14
    

    View Slide

15. Node
    properties
    Usable in:
    Groups
    •
    Search
    •
    Configuration data
    •
    
    15
    

    View Slide

16. Machines
    classification -
    Groups The server has a very precise knowledge about the
    nodes
    •
    Hardware
    •
    So ware
    •
    Network
    •
    
    16
    

    View Slide

17. Managed
    machines
    classification -
    Groups
    Classification is done on server side: nodes only
    have access to what they have to apply
    •
    security
    •
    visibility
    •
    Group = search criteria over inventory data
    •
    
    17
    

    View Slide

18. Design groups
    Group hierarchy by layers
    •
    By OS
    •
    By location: DC, cloud provider, etc.
    •
    By application
    •
    etc.
    •
    Group intersection
    •
    
    18
    

    View Slide

19. Let’s build
    groups!
    Nothing more complicated than this!
    By OS
    •
    By site (using a property)
    •
    
    19
    

    View Slide

20. Techniques
    Generic policy template
    •
    Configurable
    •
    Can embed files
    •
    (=playbook, modules, etc.)
    •
    Uses core system resources (file, services, packages,
    etc.)
    •
    
    20
    

    View Slide

21. Types of
    techniques
    Standard techniques: built and editable with the
    technique editor
    •
    Pre-built techniques: part of base install or in a
    plugin
    •
    Ready to use
    •
    Not modifiable
    •
    
    21
    

    View Slide

22. Pre-built
    techniques
    Let’s have a look at techniques coming with Rudder
    •
    
    22
    

    View Slide

23. Techniques
    Now we’ll create a technique by ourselves.
    •
    
    23
    

    View Slide

24. Generic
    methods
    A generic method is:
    a basic building block of techniques
    •
    an elementary state of the system
    •
    independent of the underlying system
    •
    a state, not an action (mostly)
    •
    
    24
    

    View Slide

25. Generic
    methods
    Some generic methods do not define a state:
    Actions
    •
    service restart
    •
    command execution
    •
    Variable definition
    •
    from a file
    •
    from a command
    •
    Condition definition
    •
    see later
    •
    
    25
    

    View Slide

26. Conditions A condition express when the generic method must be
    applied.
    Examples:
    We are on a Debian 9 system
    •
    The the ntp package is installed
    •
    The content of the configuration file has just been
    modified
    •
    etc.
    •
    
    26
    

    View Slide

27. Conditions
    Condition can limit where a method must be applied :
    This enables writing policies compatible with different
    operating systems.
    debian
    •
    debian_9
    •
    centos
    •
    systemd
    •
    
    27
    

    View Slide

28. Conditions
    Condition can limit when a method must be applied :
    This enables using actions (like service restart) by
    limiting them to a specific context
    package_present_ntp_repaired
    •
    file_content__etc_ntp_conf_repaired
    •
    Hr00.Min00_05
    •
    
    28
    

    View Slide

29. Conditions
    Every method will define a result condition that is one
    of the conditions displayed in method details:
    It can be:
    Success: When the state was already compliant
    •
    Repaired: When the state has been modified by the
    agent to become compliant
    •
    Error: When the expected state could not be reached
    •
    
    29
    

    View Slide

30. Conditions
    Conditions can be combined using boolean operators:
    ! for not
    •
    | for or
    •
    . for and
    •
    ( and ) for grouping
    •
    
    30
    

    View Slide

31. osquery
    technique
    We need to install osquery first
    •
    Let’s build a technique using the technique editor!
    •
    We need to keep two parameter configurable:
    tls_client_cert and tls_client_key
    •
    We want it to work on both CentOS and Ubuntu
    systems (at least)
    •
    Let’s do it
    •
    
    31
    

    View Slide

32. Techniques
    resources
    Allow to encapsulate liked files
    •
    Automatically copied where the technique is applied
    •
    File browser
    •
    Special variable to access local file path
    •
    
    32
    

    View Slide

33. Techniques
    design
    Think about parameters you need
    •
    A technique should not depend on anything external
    •
    
    33
    

    View Slide

34. Techniques
    design
    Report component:
    Useful for:
    By default, uses the generic method name
    •
    Can be improved and customized
    •
    Documentation
    •
    Quick access (multiple editions on the same file)
    •
    Compliance
    •
    
    34
    

    View Slide

35. Common
    problem in
    techniques
    Hardcode things
    •
    Rely on external data
    •
    Conditions when not necessary
    •
    
    35
    

    View Slide

36. Directives
    Document et organize for the future with:
    Policy instances, appliable
    •
    = technique + parameters
    •
    Will bring the specificities
    •
    brings the data
    •
    Markdown description
    •
    Tags
    •
    
    36
    

    View Slide

37. Let’s create
    one
    For our osquery installation and configuration
    •
    Provide values (cn be hardcoded or variables)
    •
    Provide a default value for …
    •
    Now overridable using node properties
    •
    
    37
    

    View Slide

38. Quick search
    Access anything!
    •
    Small query syntax (similar to github)
    •
    in:node is:hostname
    •
    
    38
    

    View Slide

39. Rules
    Business logic
    •
    
    39
    

    View Slide

40. CIS rules
    We’ll use a plugin for this!
    It provides directly appliable policies.
    •
    
    40
    

    View Slide

41. POLICY APPLICATION
    
    41
    

    View Slide

42. Policy
    generation
    Then the node will download their policies, and apply
    them.
    Compute the policy to apply on each node
    •
    Asynchronous (compute everything, then distribute)
    •
    Based on all available information
    •
    Checks for undefined variables in directive
    parameters
    •
    Computes expected reports (to track missing
    reports)
    •
    You can trigger it from the server
    •
    Even automatically
    •
    
    42
    

    View Slide

43. Policy
    generation
    Generating policies has several qualities:
    Nodes only have access to what they need
    •
    Checking for errors (inconsistent policies, undefined
    variables, etc.) on the server, and avoid breaking
    locally
    •
    
    43
    

    View Slide

44. Local
    application The agent:
    You can run it with rudder agent run -u
    Downloads the policies
    •
    Applies them locally
    •
    Either in enforce
    •
    Or audit mode
    •
    
    44
    

    View Slide

45. Local
    application
    Interesting local tracability features:
    rudder agent history
    •
    rudder agent log
    •
    rudder agent diff
    •
    
    45
    

    View Slide

46. Debugging
    Compliance view
    •
    Technical logs
    •
    Remote run from Compliance tab
    •
    rudder agent run -i
    •
    rudder directive run -i/-v
    •
    
    46
    

    View Slide

47. Reporting
    When the agent runs, it generates a run log, which
    contains what it did and the state of the different
    checked components.
    This report is transmitted to the server which stores it.
    You can access these in:
    The server knows which reports are expected, and will
    indicate all discrepancies.
    ("No news is good news" is not enough for compliance)
    Explicit better than implicit
    Changes graphs by rule
    •
    Technical log by nodes
    •
    
    47
    

    View Slide

48. Let’s add a
    new node!
    It’s an existing prod node
    •
    Should be already correct
    •
    Let’s check with audit mode
    •
    Then switch to enforce
    •
    
    48
    

    View Slide

49. Acceptation
    Inventory: A new agent automatically sends its
    inventory to its server
    •
    The server will then treat it and display node as a
    pending node
    •
    You can then either accept
    •
    or refuse it.
    •
    Note: a Rudder ID is the node’s unique identifier in
    UUID format.
    •
    It looks like b409510a-c6b1-48fc-b8d4-e6be080a773a
    •
    You can see it in rudder agent info output
    •
    
    49
    

    View Slide

50. Pending
    nodes Once your node is accepted:
    1. Its policies will be computed
    2. They will be made available to the node
    3. The node will start applying them
    4. The node will report to the server
    5. The server will display compliance
    
    50
    

    View Slide

51. Audit mode
    Avoid making any changes on a node
    •
    Because it is sensitive
    •
    Because of an update freeze
    •
    Test a directive before applying it everywhere
    •
    Set audit mode then change it to enforce
    •
    Audit configurations without enforcing them
    •
    Set audit mode permanently
    •
    
    51
    

    View Slide

52. Audit mode
    Audit mode can be changed from
    •
    a global setting, used as a default value for other places
    •
    a node specific setting, that overrides the global setting
    •
    a directive specific setting, that overrides the global setting
    •
    If audit and enforce settings conflict, audit always
    wins!
    •
    
    52
    

    View Slide

53. Compliance
    Computed from reports
    •
    Gives visibility
    •
    
    53
    

    View Slide

54. COMPLIANCE & TRACABILITY
    
    54
    

    View Slide

55. Event log
    All changes made to the applied configuration are
    stored (forever!)
    Everything is traced
    •
    
    55
    

    View Slide

56. Imagine we
    want to know
    who created
    the osquery
    directive
    Let’s have a look!
    •
    
    56
    

    View Slide

57. INTEGRATIONS
    
    57
    

    View Slide

58. Integrations
    Plugins (come to Felix’s talk!)
    •
    Monitoring (Zabbix, Centreon)
    •
    Automation (Rundeck, Ansible)
    •
    Features (notification, etc.)
    •
    Full API (including policy definition)
    •
    For anything else!
    •
    
    58
    

    View Slide

59. API
    Everything visible in the Web interface (and more!= is
    available through the API)
    
    59
    

    View Slide

60. Let’s extract
    some
    compliance in
    a spreadsheet
    We want CIS compliance as a speadsheet file.
    
    60
    

    View Slide

61. We can use a
    jq filter
    curl -k -H "X-API-Token: 26KVA5KASlyTyvgdTEtbSSK0xeepy77p" -X GET
    'https://localhost/rudder/api/latest/compliance/rules' | jq
    '.data.rules[] | select(.name == "CIS - redhat7") | .compliance'
    
    61
    

    View Slide

62. QUESTIONS?
    
    62
    

    View Slide

63. Thank you!
    Workshop tomorrow with a more detailed
    introduction and hands-on
    •
    docs.rudder.io
    •
    chat.rudder.io (or #rudder on freenode!)
    •
    
    63
    

    View Slide