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
2. RUDDER INTRODUCTION  2
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
4. What’s RUDDER? Configuration Management? • Yes, but automating configuration is not enough! • Built on configuration management abilities •  4
5. What’s RUDDER? RUDDER is a tool that allows: Configuring systems • Auditing systems • Maintaining security guidelines • Providing compliance reports •  5
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
7. Architecture  7
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
9. Our goal today Deploy and configure osquery on our infrastructure • Ensure our configuration complies with CIS guidelines • Provide efficient compliance visualization •  9
10. POLICY DESIGN  10
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
12. NODES AND GROUPS  12
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
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
15. Node properties Usable in: Groups • Search • Configuration data •  15
16. Machines classification - Groups The server has a very precise knowledge about the nodes • Hardware • So ware • Network •  16
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
18. Design groups Group hierarchy by layers • By OS • By location: DC, cloud provider, etc. • By application • etc. • Group intersection •  18
19. Let’s build groups! Nothing more complicated than this! By OS • By site (using a property) •  19
20. Techniques Generic policy template • Configurable • Can embed files • (=playbook, modules, etc.) • Uses core system resources (file, services, packages, etc.) •  20
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
22. Pre-built techniques Let’s have a look at techniques coming with Rudder •  22
23. Techniques Now we’ll create a technique by ourselves. •  23
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
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
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
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
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
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
30. Conditions Conditions can be combined using boolean operators: ! for not • | for or • . for and • ( and ) for grouping •  30
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
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
33. Techniques design Think about parameters you need • A technique should not depend on anything external •  33
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
35. Common problem in techniques Hardcode things • Rely on external data • Conditions when not necessary •  35
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
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
38. Quick search Access anything! • Small query syntax (similar to github) • in:node is:hostname •  38
39. Rules Business logic •  39
40. CIS rules We’ll use a plugin for this! It provides directly appliable policies. •  40
41. POLICY APPLICATION  41
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
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
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
45. Local application Interesting local tracability features: rudder agent history • rudder agent log • rudder agent diff •  45
46. Debugging Compliance view • Technical logs • Remote run from Compliance tab • rudder agent run -i • rudder directive run -i/-v •  46
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
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
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
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
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
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
53. Compliance Computed from reports • Gives visibility •  53
54. COMPLIANCE & TRACABILITY  54
55. Event log All changes made to the applied configuration are stored (forever!) Everything is traced •  55
56. Imagine we want to know who created the osquery directive Let’s have a look! •  56
57. INTEGRATIONS  57
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
59. API Everything visible in the Web interface (and more!= is available through the API)  59
60. Let’s extract some compliance in a spreadsheet We want CIS compliance as a speadsheet file.  60
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
62. QUESTIONS?  62
63. Thank you! Workshop tomorrow with a more detailed introduction and hands-on • docs.rudder.io • chat.rudder.io (or #rudder on freenode!) •  63