Skip to main content

Linux Ansible Policy

Updated over a week ago

The Linux Ansible Policy lets you run Ansible playbooks on Linux devices through Swifteam device management. It’s designed for both company-owned and BYOD Linux endpoints, so you can standardize configuration, deployments, and orchestration without requiring manual SSH sessions to each host.

Overview

  • Policy name: Linux Ansible Policy

  • Purpose: Manage and execute Ansible-based automation on Linux devices

  • Supported OS: Linux

  • Supported ownership types:

    • Company-owned devices

    • BYOD devices

Use this policy when you want to:

  • Apply consistent configurations across Linux machines

  • Run repeatable deployment or maintenance tasks

  • Manage per-environment variables and secrets (including encrypted vars via Ansible Vault)

  • Target either local execution on the device or remote hosts over SSH

Policy Fields

1. Playbook

  • Field name: playbook

  • Type: String

  • Display name: Playbook

  • Description:
    An Ansible playbook defines the configuration, deployment, or orchestration steps Ansible will execute. It describes:

    • Which hosts or inventory groups to target

    • What tasks to run

    • What variables or variable files to use

Typical usage:

  • Provide the contents of your Ansible playbook (YAML) or the portion required by the policy implementation.

  • Ensure that any vars_files, hosts, and roles referenced here align with the Inventories and Variable Files sections of this policy.

2. Inventories

  • Field name: inventoryGroups

  • Type: Array of dictionaries

  • Display name: Inventories

  • Description:
    Ansible uses an inventory to know which hosts it should manage. This field defines:

    • Groups of hosts

    • The actual hosts inside each group

    • The remote user Ansible should use when connecting

Each Inventory Group entry contains:

2.1 Group Name

  • Field name: name

  • Type: String

  • Display name: Name

  • Description:
    A logical identifier for a group of hosts (e.g., webservers, db_servers, staging).
    This is the group name you will reference in your Playbook under hosts:.

2.2 Inventories (Hosts within the Group)

  • Field name: inventories

  • Type: Array of dictionaries

  • Display name: Inventories

  • Description:
    A collection of individual host entries belonging to this group.

Each Inventory entry includes:

2.2.1 Alias

  • Field name: alias

  • Type: String

  • Display name: Alias

  • Description:
    A friendly nickname for the host, used inside playbooks instead of raw IP/FQDN (e.g., web-01, db-primary).

2.2.2 Host

  • Field name: host

  • Type: String

  • Display name: Host

  • Description:
    The actual network address of the device:

    • IPv4/IPv6 (e.g., 10.0.0.15, 2001:db8::1)

    • FQDN (e.g., web01.example.com)

2.2.3 User

  • Field name: user

  • Type: String

  • Display name: User

  • Description:
    The remote username Ansible uses when connecting via SSH to this host (e.g., ubuntu, ec2-user, root, deploy).

3. Variable Files

  • Field name: variableFiles

  • Type: Array of dictionaries

  • Display name: Variable Files

  • Description:
    Variable files are typically YAML files that store a collection of variables for your playbook. They allow you to:

    • Separate configuration data from playbook logic

    • Store environment-specific or secret values

    • Optionally encrypt sensitive content with Ansible Vault

Each Variable File entry includes:

3.1 File Name

  • Field name: fileName

  • Type: String

  • Display name: File Name

  • Description:
    The name of the variable file (e.g., vars.yml, database_config.yml).
    This must match the reference in your playbook under vars_files:.

    Example in a playbook:

    vars_files: - database_config.yml

3.2 Encrypted

  • Field name: encrypted

  • Type: Boolean

  • Display name: Encrypted

  • Default: false

  • Description:
    Indicates whether this variable file should be encrypted using Ansible Vault.

  • If encrypted = true:

    • The policy will display and require Vault Configuration.

    • The MDM agent will treat the file as a Vault-encrypted file.

  • If encrypted = false:

    • The Vault Configuration section is hidden and not required.

    • Variables are stored as plain text (within Swifteam’s secure storage context).

3.3 Vault Configuration

  • Field name: vaultConfig

  • Type: Dictionary

  • Display name: Vault Configuration

  • Visible when: encrypted = true

  • Description:
    Contains the Ansible Vault details required to encrypt/decrypt the variable file.

Vault Configuration fields:

3.3.1 Label

  • Field name: label

  • Type: String

  • Display name: Label

  • Description:
    The Vault ID or label (e.g., it_admin, prod_vault).
    This corresponds to the --vault-id flag and lets Ansible select the correct password for specific encrypted content.

3.3.2 Vault Password

  • Field name: vaultPassword

  • Type: String

  • Display name: Vault Password

  • Description:
    The plain-text secret used by Ansible Vault for this variable file.
    The MDM agent will:

    • Temporarily write this secret to a protected file

    • Use it during encryption/decryption

    • Handle it securely during execution

Note: While the policy accepts a plain-text password, it is stored and processed by the agent in a controlled, protected manner intended for secure runtime use.

3.4 Variables

  • Field name: variables

  • Type: Array of dictionaries

  • Display name: Variables

  • Description:
    A list of key–value pairs defined in this variable file. These are referenced in your playbook by their keys.

Each Variable entry includes:

3.4.1 Key

  • Field name: key

  • Type: String

  • Display name: Key

  • Description:
    The variable name (e.g., ansible_become_password, http_port, db_user).
    This is what you’ll reference in the playbook or templates.

3.4.2 Value

  • Field name: value

  • Type: String

  • Display name: Value

  • Description:
    The value assigned to the variable.

    • If the parent variable file has encrypted = true, the agent will handle encryption using the specified Vault configuration.

    • From the user’s perspective, you enter it in plain text; the system takes care of Vault handling.

4. Extra Variables

  • Field name: extraVars

  • Type: String

  • Display name: Extra Variables

  • Description:
    A set of high-priority variables passed at runtime, typically equivalent to Ansible’s --extra-vars. These can:

    • Override default values defined in playbooks or variable files

    • Provide environment-specific parameters (e.g., env=staging, nfs_server_ip=10.0.0.20)

Typical usage:

  • Supply a JSON/YAML-formatted map of variables (exact format depends on UI/implementation).

  • Use this for values that change frequently or that you don’t want to bake into variable files.

5. Local

  • Field name: local

  • Type: Boolean

  • Display name: Local

  • Description:
    Determines whether the playbook runs on the local device itself instead of remote hosts over SSH.

  • If local = true:

    • Ansible is executed against the local system (e.g., using localhost).

    • SSH-based host definitions may be ignored, depending on implementation.

  • If local = false:

    • Ansible uses the Inventories configuration to reach remote hosts via SSH.

Typical Use Cases

Here are some patterns where the Linux Ansible Policy fits well:

  1. Local configuration on a managed Linux device

    • local = true

    • playbook installs packages, configures services, applies hardening

    • No remote hosts required; everything runs on the device itself.

  2. Managing remote infrastructure from a managed “control node”

    • local = false

    • inventoryGroups defines multiple hosts and SSH users

    • variableFiles holds environment vars, possibly encrypted with Vault

    • extraVars tweaks behavior per environment (e.g., staging vs. prod)

  3. Securely injecting secrets

    • variableFiles[*].encrypted = true

    • vaultConfig set with label and password

    • Sensitive variables (passwords, API keys) defined under variables and consumed in your roles/tasks.

Related Articles
Linux Password Policy
Linux-specific MDM policies available in Swif
Linux Google Login Policy
Linux VPN Policy
Linux VPN Policy (RADIUS) on Linux
Did this answer your question?