Move configuration examples out of fleetctl-CLI documentation (#1253)
- Move configuration files examples from 2-fleetctl-CLI.md into /configuration-files/README.md. - Update example configuration files with "agent options" and remove all references to "osquery options" - Update numbering for documentation files
This commit is contained in:
@@ -1,32 +1,21 @@
|
||||
# fleetctl CLI
|
||||
|
||||
- [Setting Up Fleet via the CLI](#setting-up-fleet-via-the-cli)
|
||||
- [Setting Up Fleet](#setting-up-fleet)
|
||||
- [Running Fleet](#running-fleet)
|
||||
- [`fleetctl config`](#fleetctl-config)
|
||||
- [`fleetctl setup`](#fleetctl-setup)
|
||||
- [Connecting a host](#connecting-a-host)
|
||||
- [Query hosts](#query-hosts)
|
||||
- [Update osquery options](#update-osquery-options)
|
||||
- [Logging in to an existing Fleet instance](#logging-in-to-an-existing-Fleet-instance)
|
||||
- [Logging in with SAML (SSO) authentication](#logging-in-with-SAML-SSO-authentication)
|
||||
- [Using fleetctl for configuration](#using-fleetctl-for-configuration)
|
||||
- [Convert osquery JSON](#convert-osquery-json)
|
||||
- [Osquery queries](#osquery-queries)
|
||||
- [Query packs](#query-packs)
|
||||
- [Moving queries and packs from one Fleet environment to another](#moving-queries-and-packs-from-one-fleet-environment-to-another)
|
||||
- [Host labels](#host-labels)
|
||||
- [Osquery configuration options](#osquery-configuration-options)
|
||||
- [Auto table construction](#auto-table-construction)
|
||||
- [Fleet configuration options](#fleet-configuration-options)
|
||||
- [Enroll secrets](#enroll-secrets)
|
||||
- [File carving with Fleet](#file-carving-with-fleet)
|
||||
- [Logging in to an existing Fleet instance](#logging-in-to-an-existing-fleet-instance)
|
||||
- [Using fleetctl to configure Fleet](#using-fleetctl-to-configure-fleet)
|
||||
- [File carving](#file-carving)
|
||||
- [Configuration](#configuration)
|
||||
- [Usage](#usage)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
|
||||
## Setting up Fleet via the CLI
|
||||
## Setting up Fleet
|
||||
|
||||
This document walks through setting up and configuring Fleet via the CLI. If you already have a running fleet instance, skip ahead to [Logging In To An Existing Fleet Instance](#logging-in-to-an-existing-fleet-instance) to configure the `fleetctl` CLI.
|
||||
This section walks through setting up and configuring Fleet via the CLI. If you already have a running fleet instance, skip ahead to [Logging In To An Existing Fleet Instance](#logging-in-to-an-existing-fleet-instance) to configure the `fleetctl` CLI.
|
||||
|
||||
This guide illustrates:
|
||||
|
||||
@@ -35,7 +24,7 @@ This guide illustrates:
|
||||
|
||||
### Running Fleet
|
||||
|
||||
For the sake of this tutorial, I will be using the local development Docker Compose infrastructure to run Fleet locally. This is documented in some detail in the [developer documentation](../3-Contributing/1-Building-Fleet.md#development-infrastructure), but the following are the minimal set of commands that you can run from the root of the repository (assuming that you have a working Go/JavaScript toolchain installed along with Docker Compose):
|
||||
For the sake of this tutorial, we will be using the local development Docker Compose infrastructure to run Fleet locally. This is documented in some detail in the [developer documentation](../3-Contributing/1-Building-Fleet.md#development-infrastructure), but the following are the minimal set of commands that you can run from the root of the repository (assuming that you have a working Go/JavaScript toolchain installed along with Docker Compose):
|
||||
|
||||
```
|
||||
docker-compose up -d
|
||||
@@ -134,50 +123,9 @@ When the query is done (or you have enough results), CTRL-C and look at the `res
|
||||
}
|
||||
```
|
||||
|
||||
### Update osquery options
|
||||
|
||||
By default, each osquery node will check in with Fleet every 10 seconds. Let's say, for testing, you want to increase this to every 2 seconds. If this is the first time you've ever modified osquery options, let's download them locally:
|
||||
|
||||
```
|
||||
fleetctl get options > options.yaml
|
||||
```
|
||||
|
||||
The `options.yaml` file will look something like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: options
|
||||
spec:
|
||||
config:
|
||||
decorators:
|
||||
load:
|
||||
- SELECT uuid AS host_uuid FROM system_info;
|
||||
- SELECT hostname AS hostname FROM system_info;
|
||||
options:
|
||||
disable_distributed: false
|
||||
distributed_interval: 10
|
||||
distributed_plugin: tls
|
||||
distributed_tls_max_attempts: 3
|
||||
distributed_tls_read_endpoint: /api/v1/osquery/distributed/read
|
||||
distributed_tls_write_endpoint: /api/v1/osquery/distributed/write
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 10
|
||||
pack_delimiter: /
|
||||
overrides: {}
|
||||
```
|
||||
|
||||
Let's edit the file so that the `distributed_interval` option is 2 instead of 10. Save the file and run:
|
||||
|
||||
```
|
||||
fleetctl apply -f ./options.yaml
|
||||
```
|
||||
|
||||
Now run a live query again. You should notice results coming back more quickly.
|
||||
|
||||
## Logging in to an existing Fleet instance
|
||||
|
||||
If you have an existing Fleet instance (version 2.0.0 or above), then simply run `fleetctl login` (after configuring your local CLI context):
|
||||
If you have an existing Fleet instance, run `fleetctl login` (after configuring your local CLI context):
|
||||
|
||||
```
|
||||
fleetctl config set --address https://fleet.corp.example.com
|
||||
@@ -210,11 +158,23 @@ contexts:
|
||||
|
||||
Note the token can also be set with `fleetctl config set --token`, but this may leak the token into a user's shell history.
|
||||
|
||||
## Using fleetctl for configuration
|
||||
## Using fleetctl to configure Fleet
|
||||
|
||||
A Fleet configuration is defined using one or more declarative "messages" in yaml syntax. Check out the [configuration files](./configuration-files/README.md) section of the documentation for example yaml files.
|
||||
A Fleet configuration is defined using one or more declarative "messages" in yaml syntax.
|
||||
|
||||
### Convert osquery JSON
|
||||
Fleet configuration can be retrieved and applied using the `fleetctl` tool.
|
||||
|
||||
### `fleetctl get`
|
||||
|
||||
The `fleetctl get <fleet-entity-here> > <configuration-file-name-here>.yml` command allows you retrieve the current configuration and create a new file for specified Fleet entity (queries, packs, etc.)
|
||||
|
||||
### `fleetctl apply`
|
||||
|
||||
The `fleetctl apply -f <configuration-file-name-here>.yml` allows you to apply the current configuration in the specified file.
|
||||
|
||||
Check out the [configuration files](./configuration-files/README.md) section of the documentation for example yaml files.
|
||||
|
||||
### `fleetctl convert`
|
||||
|
||||
`fleetctl` includes easy tooling to convert osquery pack JSON into the
|
||||
`fleetctl` format. Use `fleetctl convert` with a path to the pack file:
|
||||
@@ -242,319 +202,7 @@ spec:
|
||||
query: select * from processes
|
||||
```
|
||||
|
||||
### Osquery queries
|
||||
|
||||
For especially long or complex queries, you may want to define one query in one file. Continued edits and applications to this file will update the query as long as the `metadata.name` does not change. If you want to change the name of a query, you must first create a new query with the new name and then delete the query with the old name. Make sure the old query name is not defined in any packs before deleting it or an error will occur.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: docker_processes
|
||||
description: The docker containers processes that are running on a system.
|
||||
query: select * from docker_container_processes;
|
||||
```
|
||||
|
||||
To define multiple queries in a file, concatenate multiple `query` resources together in a single file with `---`. For example, consider a file that you might store at `queries/osquery_monitoring.yml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_version
|
||||
description: The version of the Launcher and Osquery process
|
||||
query: select launcher.version, osquery.version from kolide_launcher_info launcher, osquery_info osquery;
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_schedule
|
||||
description: Report performance stats for each file in the query schedule.
|
||||
query: select name, interval, executions, output_size, wall_time, (user_time/executions) as avg_user_time, (system_time/executions) as avg_system_time, average_memory, last_executed from osquery_schedule;
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_info
|
||||
description: A heartbeat counter that reports general performance (CPU, memory) and version.
|
||||
query: select i.*, p.resident_size, p.user_time, p.system_time, time.minutes as counter from osquery_info i, processes p, time where p.pid = i.pid;
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_events
|
||||
description: Report event publisher health and track event counters.
|
||||
query: select name, publisher, type, subscriptions, events, active from osquery_events;
|
||||
```
|
||||
|
||||
### Query packs
|
||||
|
||||
To define query packs, reference queries defined elsewhere by name. This is why the "name" of a query is so important. You can define many of these packs in many files.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: pack
|
||||
spec:
|
||||
name: osquery_monitoring
|
||||
disabled: false
|
||||
targets:
|
||||
labels:
|
||||
- All Hosts
|
||||
queries:
|
||||
- query: osquery_version
|
||||
name: osquery_version_differential
|
||||
interval: 7200
|
||||
- query: osquery_version
|
||||
name: osquery_version_snapshot
|
||||
interval: 7200
|
||||
snapshot: true
|
||||
- query: osquery_schedule
|
||||
interval: 7200
|
||||
removed: false
|
||||
- query: osquery_events
|
||||
interval: 86400
|
||||
removed: false
|
||||
- query: osquery_info
|
||||
interval: 600
|
||||
removed: false
|
||||
```
|
||||
|
||||
The `targets` field allows you to specify the `labels` field. With the `labels` field, the hosts that become members of the specified labels, upon enrolling to Fleet, will automatically become targets of the given pack.
|
||||
|
||||
#### Moving queries and packs from one Fleet environment to another
|
||||
|
||||
When managing multiple Fleet environments, you may want to move queries and/or packs from one "exporter" environment to a another "importer" environment.
|
||||
|
||||
1. Navigate to `~/.fleet/config` to find the context names for your "exporter" and "importer" environment. For the purpose of these instructions we will use the context names `exporter` and `importer` respectively.
|
||||
2. Run the command `fleetctl get queries --yaml --context exporter > queries.yaml && fleetctl apply -f queries.yml --context importer`. This will import all the queries from your exporter Fleet instance into your importer Fleet instance. _Note, this will also write a list of all queries in yaml syntax to a file names `queries.yml`._
|
||||
3. Run the command `fleetctl get packs --yaml --context exporter > packs.yaml && fleetctl apply -f packs.yml --context importer`. This will import all the packs from your exporter Fleet instance into your importer Fleet instance. _Note, this will also write a list of all packs in yaml syntax to a file names `packs.yml`._
|
||||
|
||||
### Host labels
|
||||
|
||||
The following file describes the labels which hosts should be automatically grouped into. The label resource should include the actual SQL query so that the label is self-contained:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: label
|
||||
spec:
|
||||
name: slack_not_running
|
||||
query: >
|
||||
SELECT * from system_info
|
||||
WHERE NOT EXISTS (
|
||||
SELECT *
|
||||
FROM processes
|
||||
WHERE name LIKE "%Slack%"
|
||||
);
|
||||
```
|
||||
|
||||
Labels can also be "manually managed". When defining the label, reference hosts
|
||||
by hostname:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: label
|
||||
spec:
|
||||
name: Manually Managed Example
|
||||
label_membership_type: manual
|
||||
hosts:
|
||||
- hostname1
|
||||
- hostname2
|
||||
- hostname3
|
||||
```
|
||||
|
||||
### Osquery configuration options
|
||||
|
||||
The following file describes options returned to osqueryd when it checks for configuration. See the [osquery documentation](https://osquery.readthedocs.io/en/stable/deployment/configuration/#options) for the available options. Existing options will be over-written by the application of this file.
|
||||
|
||||
#### Overrides option
|
||||
|
||||
The overrides option allows you to segment hosts, by their platform, and supply these groups with unique osquery configuration options. When you choose to use the overrides option for a specific platform, all options specified in the default configuration will be ignored for that platform.
|
||||
|
||||
In the example file below, all Darwin and Ubuntu hosts will only receive the options specified in their respective overrides sections.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: options
|
||||
spec:
|
||||
config:
|
||||
options:
|
||||
distributed_interval: 3
|
||||
distributed_tls_max_attempts: 3
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 10
|
||||
decorators:
|
||||
load:
|
||||
- "SELECT version FROM osquery_info"
|
||||
- "SELECT uuid AS host_uuid FROM system_info"
|
||||
always:
|
||||
- "SELECT user AS username FROM logged_in_users WHERE user <> '' ORDER BY time LIMIT 1"
|
||||
interval:
|
||||
3600: "SELECT total_seconds AS uptime FROM uptime"
|
||||
overrides:
|
||||
# Note configs in overrides take precedence over the default config defined
|
||||
# under the config key above. Hosts receive overrides based on the platform
|
||||
# returned by `SELECT platform FROM os_version`. In this example, the base
|
||||
# config would be used for Windows and CentOS hosts, while Mac and Ubuntu
|
||||
# hosts would receive their respective overrides. Note, these overrides are
|
||||
# NOT merged with the top level configuration.
|
||||
platforms:
|
||||
darwin:
|
||||
options:
|
||||
distributed_interval: 10
|
||||
distributed_tls_max_attempts: 10
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 300
|
||||
disable_tables: chrome_extensions
|
||||
docker_socket: /var/run/docker.sock
|
||||
file_paths:
|
||||
users:
|
||||
- /Users/%/Library/%%
|
||||
- /Users/%/Documents/%%
|
||||
etc:
|
||||
- /etc/%%
|
||||
|
||||
ubuntu:
|
||||
options:
|
||||
distributed_interval: 10
|
||||
distributed_tls_max_attempts: 3
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 60
|
||||
schedule_timeout: 60
|
||||
docker_socket: /etc/run/docker.sock
|
||||
file_paths:
|
||||
homes:
|
||||
- /root/.ssh/%%
|
||||
- /home/%/.ssh/%%
|
||||
etc:
|
||||
- /etc/%%
|
||||
tmp:
|
||||
- /tmp/%%
|
||||
exclude_paths:
|
||||
homes:
|
||||
- /home/not_to_monitor/.ssh/%%
|
||||
tmp:
|
||||
- /tmp/too_many_events/
|
||||
decorators:
|
||||
load:
|
||||
- "SELECT * FROM cpuid"
|
||||
- "SELECT * FROM docker_info"
|
||||
interval:
|
||||
3600: "SELECT total_seconds AS uptime FROM uptime"
|
||||
```
|
||||
|
||||
### Auto table construction
|
||||
|
||||
You can use Fleet to query local SQLite databases as tables. For more information on creating ATC configuration from a SQLite database, see the [Osquery Automatic Table Construction documentation](https://osquery.readthedocs.io/en/stable/deployment/configuration/#automatic-table-construction)
|
||||
|
||||
If you already know what your ATC configuration needs to look like, you can add it to an options config file:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: options
|
||||
spec:
|
||||
overrides:
|
||||
platforms:
|
||||
darwin:
|
||||
auto_table_construction:
|
||||
tcc_system_entries:
|
||||
query: "select service, client, allowed, prompt_count, last_modified from access"
|
||||
path: "/Library/Application Support/com.apple.TCC/TCC.db"
|
||||
columns:
|
||||
- "service"
|
||||
- "client"
|
||||
- "allowed"
|
||||
- "prompt_count"
|
||||
- "last_modified"
|
||||
```
|
||||
|
||||
### Fleet configuration options
|
||||
|
||||
The following file describes configuration options applied to the Fleet server.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
host_expiry_settings:
|
||||
host_expiry_enabled: true
|
||||
host_expiry_window: 10
|
||||
host_settings:
|
||||
# "additional" information to collect from hosts along with the host
|
||||
# details. This information will be updated at the same time as other host
|
||||
# details and is returned by the API when host objects are returned. Users
|
||||
# must take care to keep the data returned by these queries small in
|
||||
# order to mitigate potential performance impacts on the Fleet server.
|
||||
additional_queries:
|
||||
time: select * from time
|
||||
macs: select mac from interface_details
|
||||
org_info:
|
||||
org_logo_url: "https://example.org/logo.png"
|
||||
org_name: Example Org
|
||||
server_settings:
|
||||
server_url: https://fleet.example.org:8080
|
||||
smtp_settings:
|
||||
authentication_method: authmethod_plain
|
||||
authentication_type: authtype_username_password
|
||||
domain: example.org
|
||||
enable_smtp: true
|
||||
enable_ssl_tls: true
|
||||
enable_start_tls: true
|
||||
password: supersekretsmtppass
|
||||
port: 587
|
||||
sender_address: fleet@example.org
|
||||
server: mail.example.org
|
||||
user_name: test_user
|
||||
verify_ssl_certs: true
|
||||
sso_settings:
|
||||
enable_sso: false
|
||||
entity_id: 1234567890
|
||||
idp_image_url: https://idp.example.org/logo.png
|
||||
idp_name: IDP Vendor 1
|
||||
issuer_uri: https://idp.example.org/SAML2/SSO/POST
|
||||
metadata: "<md:EntityDescriptor entityID="https://idp.example.org/SAML2"> ... /md:EntityDescriptor>"
|
||||
metadata_url: https://idp.example.org/idp-meta.xml
|
||||
```
|
||||
|
||||
#### SMTP authentication
|
||||
|
||||
**Warning:** Be careful not to store your SMTP credentials in source control. It is recommended to set the password through the web UI or `fleetctl` and then remove the line from the checked in version. Fleet will leave the password as-is if the field is missing from the applied configuration.
|
||||
|
||||
The following options are available when configuring SMTP authentication:
|
||||
|
||||
- `smtp_settings.authentication_type`
|
||||
- `authtype_none` - use this if your SMTP server is open
|
||||
- `authtype_username_password` - use this if your SMTP server requires authentication with a username and password
|
||||
- `smtp_settings.authentication_method` - required with authentication type `authtype_username_password`
|
||||
- `authmethod_cram_md5`
|
||||
- `authmethod_login`
|
||||
- `authmethod_plain`
|
||||
|
||||
### Enroll secrets
|
||||
|
||||
The following file shows how to configure enroll secrets. Note that secrets can be changed or made inactive, but not deleted. Hosts may not enroll with inactive secrets.
|
||||
|
||||
The name of the enroll secret used to authenticate is stored with the host and is included with API results.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: enroll_secret
|
||||
spec:
|
||||
secrets:
|
||||
- active: true
|
||||
name: default
|
||||
secret: RzTlxPvugG4o4O5IKS/HqEDJUmI1hwBoffff
|
||||
- active: true
|
||||
name: new_one
|
||||
secret: reallyworks
|
||||
- active: false
|
||||
name: inactive_secret
|
||||
secret: thissecretwontwork!
|
||||
```
|
||||
|
||||
## File carving with Fleet
|
||||
## File carving
|
||||
|
||||
Fleet supports osquery's file carving functionality as of Fleet 3.3.0. This allows the Fleet server to request files (and sets of files) from osquery agents, returning the full contents to Fleet.
|
||||
|
||||
|
||||
@@ -1,5 +1,12 @@
|
||||
# Configuration files
|
||||
|
||||
- [Queries](#queries)
|
||||
- [Packs](#packs)
|
||||
- [Labels](#labels)
|
||||
- [Enroll secrets](#enroll-secrets)
|
||||
- [Organization settings](#organization-settings)
|
||||
- [Auto table construction](#auto-table-construction)
|
||||
|
||||
Entities in Fleet, such as queries, packs, labels, agent options, and enroll secrets, can be managed with configuration files in yaml syntax.
|
||||
|
||||
This page contains links to examples that can help you understand the configuration options for your Fleet yaml file(s).
|
||||
@@ -32,3 +39,330 @@ When you reason about how to manage these config files, consider following the [
|
||||
- When defining configurations, specify the latest stable API version.
|
||||
- Configuration files should be stored in version control before being pushed to the cluster. This allows quick roll-back of a configuration if needed. It also aids with cluster re-creation and restoration if necessary.
|
||||
- Don’t specify default values unnecessarily – simple and minimal configs will reduce errors.
|
||||
|
||||
### Queries
|
||||
|
||||
For especially long or complex queries, you may want to define one query in one file. Continued edits and applications to this file will update the query as long as the `metadata.name` does not change. If you want to change the name of a query, you must first create a new query with the new name and then delete the query with the old name. Make sure the old query name is not defined in any packs before deleting it or an error will occur.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: docker_processes
|
||||
description: The docker containers processes that are running on a system.
|
||||
query: select * from docker_container_processes;
|
||||
```
|
||||
|
||||
To define multiple queries in a file, concatenate multiple `query` resources together in a single file with `---`. For example, consider a file that you might store at `queries/osquery_monitoring.yml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_version
|
||||
description: The version of the Launcher and Osquery process
|
||||
query: select launcher.version, osquery.version from kolide_launcher_info launcher, osquery_info osquery;
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_schedule
|
||||
description: Report performance stats for each file in the query schedule.
|
||||
query: select name, interval, executions, output_size, wall_time, (user_time/executions) as avg_user_time, (system_time/executions) as avg_system_time, average_memory, last_executed from osquery_schedule;
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_info
|
||||
description: A heartbeat counter that reports general performance (CPU, memory) and version.
|
||||
query: select i.*, p.resident_size, p.user_time, p.system_time, time.minutes as counter from osquery_info i, processes p, time where p.pid = i.pid;
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: query
|
||||
spec:
|
||||
name: osquery_events
|
||||
description: Report event publisher health and track event counters.
|
||||
query: select name, publisher, type, subscriptions, events, active from osquery_events;
|
||||
```
|
||||
|
||||
### Packs
|
||||
|
||||
To define query packs (packs), reference queries defined elsewhere by name. This is why the "name" of a query is so important. You can define many of these packs in many files.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: pack
|
||||
spec:
|
||||
name: osquery_monitoring
|
||||
disabled: false
|
||||
targets:
|
||||
labels:
|
||||
- All Hosts
|
||||
queries:
|
||||
- query: osquery_version
|
||||
name: osquery_version_differential
|
||||
interval: 7200
|
||||
- query: osquery_version
|
||||
name: osquery_version_snapshot
|
||||
interval: 7200
|
||||
snapshot: true
|
||||
- query: osquery_schedule
|
||||
interval: 7200
|
||||
removed: false
|
||||
- query: osquery_events
|
||||
interval: 86400
|
||||
removed: false
|
||||
- query: osquery_info
|
||||
interval: 600
|
||||
removed: false
|
||||
```
|
||||
|
||||
The `targets` field allows you to specify the `labels` field. With the `labels` field, the hosts that become members of the specified labels, upon enrolling to Fleet, will automatically become targets of the given pack.
|
||||
|
||||
#### Moving queries and packs from one Fleet environment to another
|
||||
|
||||
When managing multiple Fleet environments, you may want to move queries and/or packs from one "exporter" environment to a another "importer" environment.
|
||||
|
||||
1. Navigate to `~/.fleet/config` to find the context names for your "exporter" and "importer" environment. For the purpose of these instructions we will use the context names `exporter` and `importer` respectively.
|
||||
2. Run the command `fleetctl get queries --yaml --context exporter > queries.yaml && fleetctl apply -f queries.yml --context importer`. This will import all the queries from your exporter Fleet instance into your importer Fleet instance. _Note, this will also write a list of all queries in yaml syntax to a file names `queries.yml`._
|
||||
3. Run the command `fleetctl get packs --yaml --context exporter > packs.yaml && fleetctl apply -f packs.yml --context importer`. This will import all the packs from your exporter Fleet instance into your importer Fleet instance. _Note, this will also write a list of all packs in yaml syntax to a file names `packs.yml`._
|
||||
|
||||
### Labels
|
||||
|
||||
The following file describes the labels which hosts should be automatically grouped into. The label resource should include the actual SQL query so that the label is self-contained:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: label
|
||||
spec:
|
||||
name: slack_not_running
|
||||
query: >
|
||||
SELECT * from system_info
|
||||
WHERE NOT EXISTS (
|
||||
SELECT *
|
||||
FROM processes
|
||||
WHERE name LIKE "%Slack%"
|
||||
);
|
||||
```
|
||||
|
||||
Labels can also be "manually managed". When defining the label, reference hosts
|
||||
by hostname:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: label
|
||||
spec:
|
||||
name: Manually Managed Example
|
||||
label_membership_type: manual
|
||||
hosts:
|
||||
- hostname1
|
||||
- hostname2
|
||||
- hostname3
|
||||
```
|
||||
|
||||
### Enroll secrets
|
||||
|
||||
The following file shows how to configure enroll secrets.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: enroll_secret
|
||||
spec:
|
||||
secrets:
|
||||
- secret: RzTlxPvugG4o4O5IKS/HqEDJUmI1hwBoffff
|
||||
- secret: reallyworks
|
||||
- secret: thissecretwontwork!
|
||||
```
|
||||
|
||||
### Organization settings
|
||||
|
||||
The following file describes organization settings applied to the Fleet server.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
agent_options:
|
||||
config:
|
||||
decorators:
|
||||
load:
|
||||
- SELECT uuid AS host_uuid FROM system_info;
|
||||
- SELECT hostname AS hostname FROM system_info;
|
||||
options:
|
||||
disable_distributed: false
|
||||
distributed_interval: 10
|
||||
distributed_plugin: tls
|
||||
distributed_tls_max_attempts: 3
|
||||
distributed_tls_read_endpoint: /api/v1/osquery/distributed/read
|
||||
distributed_tls_write_endpoint: /api/v1/osquery/distributed/write
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 10
|
||||
pack_delimiter: /
|
||||
overrides: {}
|
||||
host_expiry_settings:
|
||||
host_expiry_enabled: true
|
||||
host_expiry_window: 10
|
||||
host_settings:
|
||||
# "additional" information to collect from hosts along with the host
|
||||
# details. This information will be updated at the same time as other host
|
||||
# details and is returned by the API when host objects are returned. Users
|
||||
# must take care to keep the data returned by these queries small in
|
||||
# order to mitigate potential performance impacts on the Fleet server.
|
||||
additional_queries:
|
||||
time: select * from time
|
||||
macs: select mac from interface_details
|
||||
org_info:
|
||||
org_logo_url: "https://example.org/logo.png"
|
||||
org_name: Example Org
|
||||
server_settings:
|
||||
server_url: https://fleet.example.org:8080
|
||||
smtp_settings:
|
||||
authentication_method: authmethod_plain
|
||||
authentication_type: authtype_username_password
|
||||
domain: example.org
|
||||
enable_smtp: true
|
||||
enable_ssl_tls: true
|
||||
enable_start_tls: true
|
||||
password: supersekretsmtppass
|
||||
port: 587
|
||||
sender_address: fleet@example.org
|
||||
server: mail.example.org
|
||||
user_name: test_user
|
||||
verify_ssl_certs: true
|
||||
sso_settings:
|
||||
enable_sso: false
|
||||
entity_id: 1234567890
|
||||
idp_image_url: https://idp.example.org/logo.png
|
||||
idp_name: IDP Vendor 1
|
||||
issuer_uri: https://idp.example.org/SAML2/SSO/POST
|
||||
metadata: "<md:EntityDescriptor entityID="https://idp.example.org/SAML2"> ... /md:EntityDescriptor>"
|
||||
metadata_url: https://idp.example.org/idp-meta.xml
|
||||
```
|
||||
|
||||
#### Agent options
|
||||
|
||||
The `agent_options` key describes options returned to osqueryd when it checks for configuration. See the [osquery documentation](https://osquery.readthedocs.io/en/stable/deployment/configuration/#options) for the available options. Existing options will be over-written by the application of this file.
|
||||
|
||||
> In Fleet v4.0.0, "osquery options" are renamed to "agent options" and are now configured using the organization settings (config) configuration file. [Check out out the Fleet v3 documentation](https://github.com/fleetdm/fleet/blob/3.13.0/docs/1-Using-Fleet/2-fleetctl-CLI.md#update-osquery-options) if you're using an older version of Fleet.
|
||||
|
||||
##### Overrides option
|
||||
|
||||
The `overrides` key allows you to segment hosts, by their platform, and supply these groups with unique osquery configuration options. When you choose to use the overrides option for a specific platform, all options specified in the default configuration will be ignored for that platform.
|
||||
|
||||
In the example file below, all Darwin and Ubuntu hosts will only receive the options specified in their respective overrides sections.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
agent_options:
|
||||
config:
|
||||
options:
|
||||
distributed_interval: 3
|
||||
distributed_tls_max_attempts: 3
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 10
|
||||
decorators:
|
||||
load:
|
||||
- "SELECT version FROM osquery_info"
|
||||
- "SELECT uuid AS host_uuid FROM system_info"
|
||||
always:
|
||||
- "SELECT user AS username FROM logged_in_users WHERE user <> '' ORDER BY time LIMIT 1"
|
||||
interval:
|
||||
3600: "SELECT total_seconds AS uptime FROM uptime"
|
||||
overrides:
|
||||
# Note configs in overrides take precedence over the default config defined
|
||||
# under the config key above. Hosts receive overrides based on the platform
|
||||
# returned by `SELECT platform FROM os_version`. In this example, the base
|
||||
# config would be used for Windows and CentOS hosts, while Mac and Ubuntu
|
||||
# hosts would receive their respective overrides. Note, these overrides are
|
||||
# NOT merged with the top level configuration.
|
||||
platforms:
|
||||
darwin:
|
||||
options:
|
||||
distributed_interval: 10
|
||||
distributed_tls_max_attempts: 10
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 300
|
||||
disable_tables: chrome_extensions
|
||||
docker_socket: /var/run/docker.sock
|
||||
file_paths:
|
||||
users:
|
||||
- /Users/%/Library/%%
|
||||
- /Users/%/Documents/%%
|
||||
etc:
|
||||
- /etc/%%
|
||||
|
||||
ubuntu:
|
||||
options:
|
||||
distributed_interval: 10
|
||||
distributed_tls_max_attempts: 3
|
||||
logger_plugin: tls
|
||||
logger_tls_endpoint: /api/v1/osquery/log
|
||||
logger_tls_period: 60
|
||||
schedule_timeout: 60
|
||||
docker_socket: /etc/run/docker.sock
|
||||
file_paths:
|
||||
homes:
|
||||
- /root/.ssh/%%
|
||||
- /home/%/.ssh/%%
|
||||
etc:
|
||||
- /etc/%%
|
||||
tmp:
|
||||
- /tmp/%%
|
||||
exclude_paths:
|
||||
homes:
|
||||
- /home/not_to_monitor/.ssh/%%
|
||||
tmp:
|
||||
- /tmp/too_many_events/
|
||||
decorators:
|
||||
load:
|
||||
- "SELECT * FROM cpuid"
|
||||
- "SELECT * FROM docker_info"
|
||||
interval:
|
||||
3600: "SELECT total_seconds AS uptime FROM uptime"
|
||||
host_expiry_settings:
|
||||
...
|
||||
```
|
||||
|
||||
#### SMTP authentication
|
||||
|
||||
**Warning:** Be careful not to store your SMTP credentials in source control. It is recommended to set the password through the web UI or `fleetctl` and then remove the line from the checked in version. Fleet will leave the password as-is if the field is missing from the applied configuration.
|
||||
|
||||
The following options are available when configuring SMTP authentication:
|
||||
|
||||
- `smtp_settings.authentication_type`
|
||||
- `authtype_none` - use this if your SMTP server is open
|
||||
- `authtype_username_password` - use this if your SMTP server requires authentication with a username and password
|
||||
- `smtp_settings.authentication_method` - required with authentication type `authtype_username_password`
|
||||
- `authmethod_cram_md5`
|
||||
- `authmethod_login`
|
||||
- `authmethod_plain`
|
||||
|
||||
### Auto table construction
|
||||
|
||||
You can use Fleet to query local SQLite databases as tables. For more information on creating ATC configuration from a SQLite database, see the [Osquery Automatic Table Construction documentation](https://osquery.readthedocs.io/en/stable/deployment/configuration/#automatic-table-construction)
|
||||
|
||||
If you already know what your ATC configuration needs to look like, you can add it to an options config file:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: options
|
||||
spec:
|
||||
overrides:
|
||||
platforms:
|
||||
darwin:
|
||||
auto_table_construction:
|
||||
tcc_system_entries:
|
||||
query: "select service, client, allowed, prompt_count, last_modified from access"
|
||||
path: "/Library/Application Support/com.apple.TCC/TCC.db"
|
||||
columns:
|
||||
- "service"
|
||||
- "client"
|
||||
- "allowed"
|
||||
- "prompt_count"
|
||||
- "last_modified"
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user