Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A RUDDER walkthrough: manage your configurations through compliance

Rudder
February 04, 2020

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

Rudder

February 04, 2020
Tweet

More Decks by Rudder

Other Decks in Technology

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