5c0f635966
Co-authored-by: Jacob Shandling <jacob@fleetdm.com> |
||
---|---|---|
.. | ||
kubernetes | ||
README.md |
Configuration files
Fleet can be managed with configuration files (YAML syntax) and the fleetctl command line tool. This page tells you how to write these configuration files.
Changes are applied to Fleet when the configuration file is applied using fleetctl. Check out the fleetctl documentation to learn how to apply configuration files.
Queries
The query
YAML file controls queries in Fleet.
You can define one or more queries in the same file with with ---
.
The following example file includes several queries:
---
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;
Continued edits and applications to this file will update the queries.
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.
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:
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:
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.
apiVersion: v1
kind: enroll_secret
spec:
secrets:
- secret: RzTlxPvugG4o4O5IKS/HqEDJUmI1hwBoffff
- secret: YBh0n4pvRplKyWiowv9bf3zp6BBOJ13O
Teams
Applies only to Fleet Premium.
The team
YAML file controls a team in Fleet.
You can define one or more teams in the same file with with ---
.
The following example file includes one team:
apiVersion: v1
kind: team
spec:
team:
name: Client Platform Engineering
features:
enable_host_users: false
enable_software_inventory: true
additional_queries:
time: SELECT * FROM time
macs: SELECT mac FROM interface_details
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
logger_tls_endpoint: /api/v1/osquery/log
logger_tls_period: 10
pack_delimiter: /
overrides: {}
command_line_flags: {}
secrets:
- secret: RzTlxPvugG4o4O5IKS/HqEDJUmI1hwBoffff
- secret: JZ/C/Z7ucq22dt/zjx2kEuDBN0iLjqfz
mdm:
macos_updates:
minimum_version: 12.3.1
deadline: 2022-01-04
Team settings
Team agent options
The team agent options specify options that only apply to this team. When team-specific agent options have been specified, the agent options specified at the organization level are ignored for this team.
The documentation for this section is identical to the Agent options documentation for the organization settings, except that the YAML section where it is set must be as follows. (Note the kind: team
key and the location of the agent_options
key under team
must have a name
key to identify the team to configure.)
apiVersion: v1
kind: team
spec:
team:
name: Client Platform Engineering
agent_options:
# the team-specific options go here
Secrets
The secrets
section provides the list of enroll secrets that will be valid for this team. If the section is missing, the existing secrets are left unmodified. Otherwise, they are replaced with this list of secrets for this team.
- Optional setting (array of dictionaries)
- Default value: none (empty)
- Config file format:
team: name: Client Platform Engineering secrets: - secret: RzTlxPvugG4o4O5IKS/HqEDJUmI1hwBoffff - secret: JZ/C/Z7ucq22dt/zjx2kEuDBN0iLjqfz
Modify an existing team
You can modify an existing team by applying a new team configuration file with the same name
as an existing team. The new team configuration will completely replace the previous configuration. In order to avoid overiding existing settings, we reccomend retreiving the existing configuration and modifying it.
Retrieve the team configuration and output to a YAML file:
% fleetctl get teams --name Workstations --yaml > workstation_config.yml
After updating the generated YAML, apply the changes:
% fleetctl apply -f workstation_config.yml
Depending on your Fleet version, you may see unsupported key
errors for the following keys when applying the new team configuration:
id
user_count
host_count
integrations
webhook_settings
description
agent_options
created_at
user_count
host_count
integrations
webhook_settings
You can bypass these errors by removing the key from your YAML or adding the --force
flag. This flag will force application of the changes without validation. Proceed with caution.
Mobile device management (MDM) settings
MDM features are not ready for production and are currently in development. These features are disabled by default.
The mdm
section of this configuration YAML lets you control MDM settings for each team in Fleet.
To specify Team MDM configuration, as opposed to Organization-wide MDM configuration, follow the below YAML format. Note the kind: team
field, as well as the name
and mdm
fields under team
.
apiVersion: v1
kind: team
spec:
team:
name: Client Platform Engineering
mdm:
# the team-specific mdm options go here
Organization settings
The config
YAML file controls Fleet's organization settings.
The following example file shows the default organization settings:
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
logger_tls_endpoint: /api/osquery/log
logger_tls_period: 10
pack_delimiter: /
overrides: {}
command_line_flags: {}
features:
enable_host_users: true
enable_software_inventory: true
fleet_desktop:
transparency_url: https://fleetdm.com/transparency
host_expiry_settings:
host_expiry_enabled: false
host_expiry_window: 0
integrations:
jira: null
zendesk: null
org_info:
org_logo_url: ""
org_name: Fleet
server_settings:
deferred_save_host: false
enable_analytics: true
live_query_disabled: false
server_url: ""
smtp_settings:
authentication_method: authmethod_plain
authentication_type: authtype_username_password
domain: ""
enable_smtp: false
enable_ssl_tls: true
enable_start_tls: true
password: ""
port: 587
sender_address: ""
server: ""
user_name: ""
verify_ssl_certs: true
sso_settings:
enable_jit_provisioning: false
enable_sso: false
enable_sso_idp_login: false
entity_id: ""
idp_image_url: ""
idp_name: ""
issuer_uri: ""
metadata: ""
metadata_url: ""
vulnerabilities:
databases_path: "/tmp/vulndbs"
periodicity: 1h
cpe_database_url: ""
cpe_translations_url: ""
cve_feed_prefix_url: ""
current_instance_checks: "auto"
disable_data_sync: false
recent_vulnerability_max_age: 30d
disable_win_os_vulnerabilities: false
webhook_settings:
failing_policies_webhook:
destination_url: ""
enable_failing_policies_webhook: false
host_batch_size: 0
policy_ids: null
host_status_webhook:
days_count: 0
destination_url: ""
enable_host_status_webhook: false
host_percentage: 0
interval: 24h
vulnerabilities_webhook:
destination_url: ""
enable_vulnerabilities_webhook: false
host_batch_size: 0
mdm:
apple_bm_default_team: ""
macos_updates:
minimum_version: ""
deadline: ""
Settings
All possible settings are organized below by section.
Each section's key must be one level below the spec
key, indented with spaces (not <tab>
charaters) as required by the YAML format.
For example, when adding the host_expiry_settings.host_expiry_enabled
setting, you'd specify the host_expiry_settings
section one level below the spec
key:
apiVersion: v1
kind: config
spec:
host_expiry_settings:
host_expiry_enabled: true
Features
The features
section of the configuration YAML lets you define what predefined queries are sent to the hosts and later on processed by Fleet for different functionalities.
Note: this section used to be named
host_settings
, but was renamed in Fleet v4.20.0,host_settings
is still supported for backwards compatibility.
features.additional_queries
This is the 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.
- Optional setting (dictionary of key-value strings)
- Default value: none (empty)
- Config file format:
features: additional_queries: time: SELECT * FROM time macs: SELECT mac FROM interface_details
- Deprecated config file format:
host_settings: additional_queries: time: SELECT * FROM time macs: SELECT mac FROM interface_details
features.enable_host_users
Whether or not Fleet sends the query needed to gather user-related data from hosts.
- Optional setting (boolean)
- Default value:
true
- Config file format:
features: enable_host_users: false
- Deprecated config file format:
host_settings: enable_host_users: false
features.enable_software_inventory
Whether or not Fleet sends the query needed to gather the list of software installed on hosts, along with other metadata.
- Optional setting (boolean)
- Default value:
true
- Config file format:
features: enable_software_inventory: false
- Deprecated config file format:
host_settings: enable_software_inventory: false
features.detail_query_overrides
This feature can be used to override "detail queries" hardcoded in Fleet.
IMPORTANT: This feature should only be used when debugging issues with Fleet's hardcoded queries. Use with caution as this may break Fleet ingestion of hosts data.
- Optional setting (dictionary of key-value strings)
- Default value: none (empty)
- Config file format:
features: detail_query_overrides: # null allows to disable the "users" query from running on hosts. users: null # this replaces the hardcoded "mdm" detail query. mdm: "SELECT enrolled, server_url, installed_from_dep, payload_identifier FROM mdm;"
Fleet Desktop
For more information about Fleet Desktop, see Fleet Desktop's documentation.
fleet_desktop.transparency_url
Available in Fleet Premium. Direct users of Fleet Desktop to a custom transparency URL page.
- Optional setting (string)
- Default value: Fleet's default transparency URL ("https://fleetdm.com/transparency")
- Config file format:
fleet_desktop: transparency_url: "https://example.org/transparency"
Host expiry settings
The host_expiry_settings
section lets you define if and when hosts should be removed from Fleet if they have not checked in. Once a host has been removed from Fleet, it will need to re-enroll with a valid enroll_secret
to connect to your Fleet instance.
host_expiry_settings.host_expiry_enabled
Whether offline hosts' expiration is enabled. If host_expiry_enabled
is set to true
, Fleet allows automatic cleanup of hosts that have not communicated with Fleet in some number of days.
- Optional setting (boolean)
- Default value:
false
- Config file format:
host_expiry_settings: host_expiry_enabled: true
host_expiry_settings.host_expiry_window
If a host has not communicated with Fleet in the specified number of days, it will be removed.
- Optional setting (integer)
- Default value:
0
(must be > 0 when enabling host expiry) - Config file format:
host_expiry_settings: host_expiry_window: 10
Integrations
For more information about integrations and Fleet automations in general, see the Automations documentation. Only one automation can be enabled for a given automation type (e.g., for failing policies, only one of the webhooks, the Jira integration, or the Zendesk automation can be enabled).
It's recommended to use the Fleet UI to configure integrations since secret credentials (in the form of an API token) must be provided. See the Automations documentation for the UI configuration steps.
Organization information
org_info.org_name
The name of the organization.
- Required setting (string)
- Default value: none (provided during Fleet setup)
- Config file format:
org_info: org_name: Fleet
org_info.org_logo_url
The URL of the logo of the organization.
- Optional setting (string)
- Default value: none (uses Fleet's logo)
- Config file format:
org_info: org_logo_url: https://example.com/logo.png
Server settings
server_settings.debug_host_ids
There's a lot of information coming from hosts, but it's sometimes useful to see exactly what a host is returning in order to debug different scenarios.
For example, let's say the hosts with ids 342 and 98 are not behaving as you expect in Fleet. You can enable verbose logging with the following configuration:
---
apiVersion: v1
kind: config
spec:
server_settings:
debug_host_ids:
- 342
- 98
Once you have collected the logs, you can easily disable the debug logging by applying the following configuration:
---
apiVersion: v1
kind: config
spec:
server_settings:
debug_host_ids: []
Warning: This will potentially log a lot of data. Some of that data might be private. Please verify it before posting it in a public channel or a GitHub issue.
- Optional setting (array of integers)
- Default value: empty
- Config file format:
server_settings: debug_host_ids: - 342 - 98
server_settings.deferred_save_host
Whether saving host-related information is done synchronously in the HTTP handler of the host's request, or asynchronously. This can provide better performance in deployments with many hosts. Note that this is an experimental feature.
- Optional setting (boolean)
- Default value:
false
- Config file format:
server_settings: deferred_save_host: true
server_settings.enable_analytics
If sending usage analytics is enabled or not.
- Optional setting (boolean)
- Default value:
true
- Config file format:
server_settings: enable_analytics: false
server_settings.live_query_disabled
If the live query feature is disabled or not.
- Optional setting (boolean)
- Default value:
false
- Config file format:
server_settings: live_query_disabled: true
server_settings.server_url
The base URL of the fleet server, including the scheme (e.g. "https://").
- Required setting (string)
- Default value: none (provided during Fleet setup)
- Config file format:
server_settings: server_url: https://fleet.example.org:8080
SMTP settings
It's recommended to use the Fleet UI to configure SMTP since a secret password must be provided. Navigate to Settings -> Organization settings -> SMTP Options to proceed with this configuration.
SSO settings
For additional information on SSO configuration, including just-in-time (JIT) user provisioning, creating SSO users in Fleet, and identity providers configuration, see Configuring single sign-on (SSO).
sso_settings.enable_jit_provisioning
Available in Fleet Premium. Enables just-in-time user provisioning.
- Optional setting (boolean)
- Default value:
false
- Config file format:
sso_settings: enable_jit_provisioning: true
sso_settings.enable_sso
Configures if single sign-on is enabled.
- Optional setting (boolean)
- Default value:
false
- Config file format:
sso_settings: enable_sso: true
sso_settings.enable_sso_idp_login
Allow single sign-on login initiated by identity provider.
- Optional setting (boolean)
- Default value:
false
- Config file format:
sso_settings: enable_sso_idp_login: true
sso_settings.entity_id
The required entity ID is a Uniform Resource Identifier (URI) that you use to identify Fleet when configuring the identity provider. It must exactly match the Entity ID field used in identity provider configuration.
- Required setting if SSO is enabled, must have at least 5 characters (string)
- Default value: ""
- Config file format:
sso_settings: entity_id: "https://example.com"
sso_settings.idp_image_url
An optional link to an image such as a logo for the identity provider.
- Optional setting (string)
- Default value: ""
- Config file format:
sso_settings: idp_image_url: "https://example.com/logo"
sso_settings.idp_name
A required human-friendly name for the identity provider that will provide single sign-on authentication.
- Required setting if SSO is enabled (string)
- Default value: ""
- Config file format:
sso_settings: idp_name: "SimpleSAML"
sso_settings.issuer_uri
The issuer URI supplied by the identity provider.
- Optional setting (string)
- Default value: ""
- Config file format:
sso_settings: issuer_uri: "https://example.com/saml2/sso-service"
sso_settings.metadata
Metadata (in XML format) provided by the identity provider.
- Optional setting, either
metadata
ormetadata_url
must be set if SSO is enabled, but not both (string). - Default value: "".
- Config file format:
sso_settings: metadata: "<md:EntityDescriptor entityID="https://idp.example.org/SAML2"> ... /md:EntityDescriptor>"
sso_settings.metadata_url
A URL that references the identity provider metadata.
- Optional setting, either
metadata
ormetadata_url
must be set if SSO is enabled, but not both (string). - Default value: "".
- Config file format:
sso_settings: metadata_url: https://idp.example.org/idp-meta.xml
Vulnerability settings
vulnerabilities.databases_path
Path to a directory on the local filesystem (accessible to the Fleet server) where the various vulnerability databases will be stored.
- Optional setting, must be set to enable vulnerability detection (string).
- Default value: "/tmp/vulndb".
- Config file format:
vulnerabilities: databases_path: "/path/to/dir"
Webhook settings
For more information about webhooks and Fleet automations in general, see the Automations documentation.
webhook_settings.interval
The interval at which to check for webhook conditions. This value currently configures both the host status and failing policies webhooks, but not the recent vulnerabilities webhook. (See the Recent vulnerabilities section for details.)
- Optional setting (time duration as a string)
- Default value:
24h
- Config file format:
webhook_settings: interval: "12h"
Failing policies webhook
The following options allow the configuration of a webhook that will be triggered if selected policies are not passing for some hosts.
webhook_settings.failing_policies_webhook.destination_url
The URL to POST
to when the condition for the webhook triggers.
- Optional setting, required if webhook is enabled (string).
- Default value: "".
- Config file format:
webhook_settings: failing_policies_webhook: destination_url: "https://example.org/webhook_handler"
webhook_settings.failing_policies_webhook.enable_failing_policies_webhook
Defines whether to enable the failing policies webhook. Note that currently, if the failing policies webhook and the osquery.enable_async_host_processing
options are set, some failing policies webhooks could be missing. Some transitions from succeeding to failing or vice-versa could happen without triggering a webhook request.
- Optional setting (boolean).
- Default value:
false
. - Config file format:
webhook_settings: failing_policies_webhook: enable_failing_policies_webhook: true
webhook_settings.failing_policies_webhook.host_batch_size
Maximum number of hosts to batch on POST
requests. A value of 0
, the default, means no batching. All hosts failing a policy will be sent on one POST
request.
- Optional setting (integer).
- Default value:
0
. - Config file format:
webhook_settings: failing_policies_webhook: host_batch_size: 100
webhook_settings.failing_policies_webhook.policy_ids
The IDs of the policies for which the webhook will be enabled.
- Optional setting (array of integers).
- Default value: empty.
- Config file format:
webhook_settings: failing_policies_webhook: policy_ids: - 1 - 2 - 3
Host status webhook
The following options allow the configuration of a webhook that will be triggered if the specified percentage of hosts are offline for the specified amount of time.
webhook_settings.host_status_webhook.days_count
Number of days that hosts need to be offline for to count as part of the percentage.
- Optional setting, required if webhook is enabled (integer).
- Default value:
0
. - Config file format:
webhook_settings: host_status_webhook: days_count: 5
webhook_settings.host_status_webhook.destination_url
The URL to POST
to when the condition for the webhook triggers.
- Optional setting, required if webhook is enabled (string).
- Default value: "".
- Config file format:
webhook_settings: host_status_webhook: destination_url: "https://example.org/webhook_handler"
webhook_settings.host_status_webhook.enable_host_status_webhook
Defines whether the webhook check for host status will run or not.
- Optional setting (boolean).
- Default value:
false
. - Config file format:
webhook_settings: host_status_webhook: enable_host_status_webhook: true
webhook_settings.host_status_webhook.host_percentage
The percentage of hosts that need to be offline to trigger the webhook.
- Optional setting, required if webhook is enabled (float).
- Default value:
0
. - Config file format:
webhook_settings: host_status_webhook: host_percentage: 10
Vulnerabilities webhook
The following options allow the configuration of a webhook that will be triggered if recently published vulnerabilities are detected and there are affected hosts. A vulnerability is considered recent if it has been published in the last 30 days (based on the National Vulnerability Database, NVD).
Note that the recent vulnerabilities webhook is not checked at webhook_settings.interval
like other webhooks. It is checked as part of the vulnerability processing and runs at the vulnerabilities.periodicity
interval specified in the fleet configuration.
webhook_settings.vulnerabilities_webhook.destination_url
The URL to POST
to when the condition for the webhook triggers.
- Optional setting, required if webhook is enabled (string).
- Default value: "".
- Config file format:
webhook_settings: vulnerabilities_webhook: destination_url: "https://example.org/webhook_handler"
webhook_settings.vulnerabilities_webhook.enable_vulnerabilities_webhook
Defines whether to enable the vulnerabilities webhook.
- Optional setting (boolean).
- Default value:
false
. - Config file format:
webhook_settings: vulnerabilities_webhook: enable_vulnerabilities_webhook: true
webhook_settings.vulnerabilities_webhook.host_batch_size
Maximum number of hosts to batch on POST
requests. A value of 0
, the default, means no batching. All hosts affected will be sent on one POST
request.
- Optional setting (integer).
- Default value:
0
. - Config file format:
webhook_settings: vulnerabilities_webhook: host_batch_size: 100
Agent options
The agent_options
key controls the settings applied to the agent on all your hosts. These settings are applied when each host checks in.
See the osquery documentation for the available options. This document shows all examples in command line flag format. Remove the dashed lines (--
) for Fleet to successfully update the setting. For example, use distributed_interval
instead of --distributed_interval
.
Agent options are validated using the latest version of osquery.
You can verify that your agent options are valid by using the fleetctl apply command with the --dry-run
flag. This will report any error and do nothing if the configuration was valid. If you don't use the latest version of osquery, you can override validation using the --force
flag. This will update agent options even if they are invalid.
Existing options will be overwritten by the application of this file.
command_line_flags
option
This feature requires Orbit, the Fleet agent manager.
The command_line_flags
key inside of agent_options
allows you to remotely manage the osquery command line flags. These command line flags are options that typically require osquery to restart for them to take effect. But with Orbit, you can use the command_line_flags
key to take care of that. Orbit will write these to the flagfile on the host and pass it to osquery.
To see the full list of these osquery command line flags, please run osquery
with the --help
switch.
Just like the other agent_options
above, remove the dashed lines (--
) for Fleet to successfully update them.
Here is an example of using the command_line_flags
key:
apiVersion: v1
kind: config
spec:
agent_options:
command_line_flags: # requires Fleet's osquery installer
verbose: true
disable_watchdog: false
logger_path: /path/to/logger
Note that the command_line_flags
key does not support the overrides
key, which is documented below.
You can verfiy that these flags have taken effect on the hosts by running a query against the osquery_flags
table.
If you revoked an old enroll secret, this feature won't work for hosts that were added to Fleet using this old enroll secret. This is because Orbit uses the enroll secret to receive new flags from Fleet. For these hosts, all existing features will work as expected.
For further documentation on how to rotate enroll secrets, please see this guide.
If you prefer to deploy a new package with the updated enroll secret:
- Check which hosts need a new enroll secret by running the following query:
SELECT * FROM orbit_info WHERE enrolled = false
.
The hosts that don't have Orbit installed will return an error because the
orbit_info
table doesn't exist. You can safely ignore these errors.
-
In Fleet, head to the Hosts page and select Add hosts to find the fleetctl package command with an active enroll secret.
-
Copy and run the fleetctl package command to create a new package. Distribute this package to the hosts that returned results in step 1.
-
Done!
In order for these options to be applied to your hosts, the
osquery
agent must be configured to use thetls
config plugin and pointed to the correct endpoint. If you are using Orbit to enroll your hosts, this is done automatically.
"--config_plugin=tls",
"--config_tls_endpoint=" + path.Join(prefix, "/api/v1/osquery/config")
apiVersion: v1
kind: config
spec:
agent_options:
extensions
option
This feature requires Orbit, the Fleet agent manager, along with a custom TUF auto-update server.
The extensions
key inside of agent_options
allows you to remotely manage and deploy osquery extensions. Just like other agent_options
the extensions
key can be applied either to a team specific one or the global one.
This is best illustrated with an example. Here is an example of using the extensions
key:
apiVersion: v1
kind: config
spec:
agent_options:
extensions: # requires Fleet's osquery installer
hello_world:
channel: 'stable'
platform: 'macos'
In the above example, we are configuring our hello_world
extension. We do this by creating a hello_world
sub-key under extensions
, and then specifying the channel
and platform
keys for that extension.
Next, you will need to make sure to push the binary file of our hello_world
extension as a target on your TUF server. This step needs to follow these conventions:
- The binary file of the extension, must have the same name as the extension, followed by the
.ext
. In the above case, the filename should behello_world.ext
- The target name for the TUF server must be named as
extensions/<extension_name>
. For the above example, this would beextensions/hello_world
platform
is one ofmacos
,linux
, orwindows
If you are using fleetctl
to manage your TUF server, these same conventions apply. You can run the following command to add a new target:
fleetctl updates add --path /path/to/local/TUF/repo --target /path/to/extensions/binary/hello_world.ext --name extensions/hello_world --platform macos --version 0.1
After successfully configuring the agent options, and pushing the extension as a target on your TUF server, Orbit will periodically check with the TUF server for updates to these extensions.
If you are using a self-hosted TUF server, you must also manage all of Orbit's versions, including osquery, Fleet Desktop and osquery extensions.
Fleet recommends deploying extensions created with osquery-go or natively with C++, instead of Python. Extensions written in Python requires the user to compile it into a single packaged binary along with all the dependencies.
Example Agent options YAML
apiVersion: v1
kind: config
spec:
agent_options:
config:
options:
distributed_interval: 3
distributed_tls_max_attempts: 3
logger_tls_endpoint: /api/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. Be aware that these overrides are NOT merged
# with the top-level configuration!! This means that settings values defined
# on the top-level config.options section will not be propagated to the platform
# override sections. So for example, the config.options.distributed_interval value
# will be discared on a platform override section, and only the section value
# for distributed_interval will be used. If the given setting is not specified
# in the override section, its default value will be enforced.
# Going back to the example, if the override section is windows,
# overrides.platforms.windows.distributed_interval will have to be set again to 5
# for this setting to be enforced as expected, otherwise the setting will get
# its default value (60 in the case of distributed_interval).
# 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.
platforms:
darwin:
options:
distributed_interval: 10
distributed_tls_max_attempts: 10
logger_tls_endpoint: /api/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_tls_endpoint: /api/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:
# ...
agent_options.config
The config key sets the osqueryd configuration options for your agents. In a plain osquery deployment, these would typically be set in osquery.conf
. Each key below represents a corresponding key in the osquery documentation.
For detailed information on osquery configuration options, check out the osquery configuration docs.
agent_options:
config:
options: ~
decorators: ~
yara: ~
overrides: ~
agent_options.config.options
In the options key, you can set your osqueryd options and feature flags.
Any command line only flags must be set using the command_line_flags
key for Orbit agents, or by modifying the osquery flags on your hosts if you're using plain osquery.
To see a full list of flags, broken down by the method you can use to set them (configuration options vs command line flags), you can run osqueryd --help
on a plain osquery agent. For Orbit agents, run sudo orbit osqueryd --help
. The options will be shown there in command line format as --key value
. In yaml
format, that would become key: value
.
agent_options:
config:
options:
distributed_interval: 3
distributed_tls_max_attempts: 3
logger_tls_endpoint: /api/osquery/log
logger_tls_period: 10
decorators: ~
agent_options.config.decorators
In the decorators key, you can specify queries to include additional information in your osquery results logs.
Use load
for details you want to update values when the configuration loads, always
to update every time a scheduled query is run, and interval
if you want to update on a schedule.
agent_options:
config:
options: ~
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"
agent_options.config.yara
You can use Fleet to configure the yara
and yara_events
osquery tables. Fore more information on YARA configuration and continuous monitoring using the yara_events
table, check out the YARA-based scanning with osquery section of the osquery documentation.
The following is an example Fleet configuration file with YARA configuration. The values are taken from an example config supplied in the above link to the osquery documentation.
---
apiVersion: v1
kind: config
spec:
agent_options:
config:
# ...
yara:
file_paths:
system_binaries:
- sig_group_1
tmp:
- sig_group_1
- sig_group_2
signatures:
sig_group_1:
- /Users/wxs/sigs/foo.sig
- /Users/wxs/sigs/bar.sig
sig_group_2:
- /Users/wxs/sigs/baz.sig
overrides: {}
agent_options.overrides
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.
IMPORTANT: If a given option is not specified in a platform override section, its default value will be enforced.
agent_options:
config:
options: ~
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_tls_endpoint: /api/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/%%
agent_options.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, check out the Automatic Table Construction section of the osquery documentation.
If you already know what your ATC configuration needs to look like, you can add it to an options config file:
apiVersion: v1
kind: config
spec:
agent_options:
config:
options:
# ...
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"
agent_options.command_line_flags
Requires Fleet v4.22.0 or later and Orbit v1.3.0 or later**
In the command_line_flags
key, you can update the osquery flags of your Orbit enrolled agents.
agent_options:
config:
overrides:
command_line_flags:
enable_file_events: true
Mobile device management (MDM) settings
MDM features are not ready for production and are currently in development. These features are disabled by default.
The mdm
section of the configuration YAML lets you control MDM settings in Fleet.
mdm.apple_bm_default_team
Applies only to Fleet Premium.
Set name of default team to use with Apple Business Manager.
- Default value: ""
- Config file format:
mdm: apple_bm_default_team: "Workstations"
mdm.macos_updates
Applies only to Fleet Premium.
The following options allow to configure the behavior of Nudge for macOS hosts that belong to no team and are enrolled into Fleet's MDM.
mdm.macos_updates.minimum_version
Hosts that belong to no team and are enrolled into Fleet's MDM will be nudged until their macOS is at or above this version.
Requires mdm.macos_updates.deadline
to be set.
- Default value: ""
- Config file format:
mdm: macos_updates: minimum_version: "12.1.1"
mdm.macos_updates.deadline
A deadline in the form YYYY-MM-DD
. The exact deadline time is at 04:00:00 (UTC-8).
Hosts that belong to no team and are enrolled into Fleet's MDM won't be able to dismiss the Nudge window once this deadline is past.
Requires mdm.macos_updates.minimum_version
to be set.
- Default value: ""
- Config file format:
mdm: macos_updates: deadline: "2022-01-01"
Advanced configuration
Note: More settings are included in the contributor documentation. It's possible, although not recommended, to configure these settings in the YAML configuration file.