Restructured Documentation
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 8s
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 8s
This commit is contained in:
@@ -0,0 +1,48 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Record AWX credential examples for Linux and Windows targets. The examples retain their original domain context and must be reconciled with the authentication method used by the target environment.
|
||||
|
||||
!!! info "Recorded Credential Examples"
|
||||
These examples use the `MOONGATE.LOCAL` domain and record Kerberos limitations from that setup. The separate [AWX Kerberos implementation](<../../../workflows/Automation/AWX/AWX Kerberos Implementation.md>) describes a `BUNNY-LAB.IO` configuration. Confirm which environment applies before using either example.
|
||||
|
||||
## Windows-based Credentials
|
||||
### NTLM
|
||||
NTLM-based authentication is not exactly the most secure method of remotely running playbooks on Windows devices, but it is still encrypted using SSL certificates created by the device itself when provisioned correctly to enable WinRM functionality.
|
||||
|
||||
```text title="(NTLM) nicole.rappe@MOONGATE.LOCAL"
|
||||
Credential Type: Machine
|
||||
Username: nicole.rappe@MOONGATE.LOCAL
|
||||
Password: <Encrypted>
|
||||
Privilege Escalation Method: runas
|
||||
Privilege Escalation Username: nicole.rappe@MOONGATE.LOCAL
|
||||
```
|
||||
|
||||
### Kerberos
|
||||
Kerberos-based authentication is generally considered the most secure method of authentication with Windows devices, but can be trickier to set up since it requires additional setup inside of AWX in the cluster for it to function properly. The separately documented AWX Kerberos implementation describes a different environment.
|
||||
|
||||
```text title="(Kerberos WinRM) nicole.rappe"
|
||||
Credential Type: Kerberos WinRM
|
||||
Username: nicole.rappe
|
||||
Password: <Encrypted>
|
||||
Kerberos Realm (Domain): MOONGATE.LOCAL
|
||||
```
|
||||
|
||||
## Linux-based Credentials
|
||||
```text title="(LINUX) nicole"
|
||||
Credential Type: Machine
|
||||
Username: nicole
|
||||
Password: <Encrypted>
|
||||
Privilege Escalation Method: sudo
|
||||
Privilege Escalation Username: root
|
||||
```
|
||||
|
||||
!!! note "Note"
|
||||
`WinRM / Kerberos` based credentials do not currently work as-expected. That limitation belongs to this recorded example; consult the linked Kerberos workflow for the separate implementation.
|
||||
|
||||
## Related Documentation
|
||||
- [Related AWX Documentation](<index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- WinRM
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Record the input and injector definitions for the custom AWX Kerberos WinRM credential type.
|
||||
|
||||
```yaml title="Input Configuration"
|
||||
fields:
|
||||
- id: username
|
||||
type: string
|
||||
label: Username
|
||||
- id: password
|
||||
type: string
|
||||
label: Password
|
||||
secret: true
|
||||
- id: krb_realm
|
||||
type: string
|
||||
label: Kerberos Realm (Domain)
|
||||
required:
|
||||
- username
|
||||
- password
|
||||
- krb_realm
|
||||
```
|
||||
|
||||
```yaml title="Injector Configuration"
|
||||
extra_vars:
|
||||
ansible_user: '{{ username }}'
|
||||
ansible_password: '{{ password }}'
|
||||
ansible_winrm_transport: kerberos
|
||||
ansible_winrm_kerberos_realm: '{{ krb_realm }}'
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
- [Related AWX Documentation](<index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Explain how AWX inventories describe hosts, groups, and connection variables. Use the lab inventory for environment-specific host records.
|
||||
|
||||
Keep in mind the "Group Variables" section varies based on your environment. NTLM is considered insecure, but may be necessary when you are interacting with Windows servers that are not domain-joined. Otherwise you want to use Kerberos authentication. This is outlined more in the [AWX Kerberos Implementation](<../../../workflows/Automation/AWX/AWX Kerberos Implementation.md#job-template-and-inventory-examples>) documentation.
|
||||
|
||||
!!! note "Inventory Data Relationships"
|
||||
An inventory file consists of hosts, groups, and variables. A host belongs to a group, and a group can have variables configured for it. If you run a playbook / job template against a host, it will assign the variables associated to the group that host belongs to (if any) during runtime.
|
||||
|
||||
```ini title="https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/inventories/homelab.ini"
|
||||
# Networking
|
||||
pfsense-example ansible_host=192.168.3.1
|
||||
|
||||
# Servers
|
||||
example01 ansible_host=192.168.3.2
|
||||
example02 ansible_host=192.168.3.3
|
||||
example03 ansible_host=example03.domain.com # FQDN is required for Ansible in Windows Domain-Joined Kerberos environments.
|
||||
example04 ansible_host=example04.domain.com # FQDN is required for Ansible in Windows Domain-Joined Kerberos environments.
|
||||
|
||||
# Group Definitions
|
||||
[linuxServers]
|
||||
example01
|
||||
example02
|
||||
|
||||
[domainControllers]
|
||||
example03
|
||||
example04
|
||||
|
||||
[domainControllers:vars]
|
||||
ansible_connection=winrm
|
||||
ansible_winrm_kerberos_delegation=false
|
||||
ansible_port=5986
|
||||
ansible_winrm_transport=ntlm
|
||||
ansible_winrm_server_cert_validation=ignore
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
- [Related AWX Documentation](<index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Record the fields and variables used by the example AWX job template that deploys a Hyper-V guest.
|
||||
|
||||
```text title="Deploy Hyper-V VM"
|
||||
Name: Deploy Hyper-V VM
|
||||
Inventory: (NTLM) MOON-HOST-01
|
||||
Playbook: playbooks/Windows/Hyper-V/Deploy-VM.yml
|
||||
Credentials: (NTLM) nicole.rappe@MOONGATE.local
|
||||
Execution Environment: AWX EE (latest)
|
||||
Project: Ansible Playbooks (Gitea)
|
||||
|
||||
Variables:
|
||||
---
|
||||
random_number: "{{ lookup('password', '/dev/null chars=digits length=4') }}"
|
||||
random_letters: "{{ lookup('password', '/dev/null chars=ascii_uppercase length=4') }}"
|
||||
vm_name: "NEXUS-TEST-{{ random_number }}{{ random_letters }}"
|
||||
vm_memory: "8589934592" #Measured in Bytes (e.g. 8GB)
|
||||
vm_storage: "68719476736" #Measured in Bytes (e.g. 64GB)
|
||||
iso_path: "C:\\ubuntu-22.04-live-server-amd64.iso"
|
||||
vm_folder: "C:\\Virtual Machines\\{{ vm_name_fact }}"
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
- [Related AWX Documentation](<index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This is an indexed list of Ansible Playbooks / Workflows that I have developed to deploy and manage various aspects of my lab environment. The list is not dynamically updated, so it may sometimes be out-of-date.
|
||||
|
||||
!!! warning "DOCUMENT UNDER CONSTRUCTION"
|
||||
This document is a "scaffold" document. It is missing significant portions of several sections and should not be read with any scrutiny until it is more feature-complete down-the-road. Come back later and I should have added more to this document hopefully by then.
|
||||
|
||||
## Linux Playbooks
|
||||
### Deployments
|
||||
Deployment playbooks are meant to be playbooks (or a series of playbooks forming a "Workflow Job Template") that deploy a server or piece of software.
|
||||
|
||||
- Authentik
|
||||
- [1-Authentik-Bootstrapper.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Authentik/1-Authentik-Bootstrapper.yml)
|
||||
- [2-Deploy-Cluster.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Authentik/2-Deploy-Cluster.yml)
|
||||
- [3-Deploy-Authentik.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Authentik/3-Deploy-Authentik.yml)
|
||||
- [Check_Cluster_Nodes.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Authentik/Check_Cluster_Nodes.yml)
|
||||
- [Check_Cluster_Pods.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Authentik/Check_Cluster_Pods.yml)
|
||||
- Immich
|
||||
- [Full_Deployment.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Immich/Full_Deployment.yml)
|
||||
- Keycloak
|
||||
- [Deploy-Keycloak.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Keycloak/Deploy-Keycloak.yml)
|
||||
- Portainer
|
||||
- [Deploy-Portainer.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/Portainer/Deploy-Portainer.yml)
|
||||
- PrivacyIDEA
|
||||
- [privacyIDEA.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Deployments/privacyIDEA.yml)
|
||||
- Rancher RKE2 Kubernetes Cluster
|
||||
- PLACEHOLDER (not documented)
|
||||
- PLACEHOLDER (not documented)
|
||||
- PLACEHOLDER (not documented)
|
||||
- PLACEHOLDER (not documented)
|
||||
- PLACEHOLDER (not documented)
|
||||
|
||||
### Kerberos
|
||||
This playbook is designed to be chain-loaded before any playbooks that involve interacting with Active Directory Domain-Joined Windows Devices. It establishes a connection with Active Directory using domain credentials, sets up a keytab file (among other things), and makes it so the execution environment that the subsequent jobs are running in are able to run against windows devices. This ensures the connection is encrypted the entire time the playbooks are running instead of using lower-security authentication methods like NTLM, which don't even always work in most circumstances. You can find more information in the [Kerberos Authentication](<../../../workflows/Automation/AWX/AWX Kerberos Implementation.md#kerberos-implementation>) section of the AWX documentation. `It does require additional setup prior to running the playbook.`
|
||||
|
||||
- [Establish_Kerberos_Connection.yml](https://git.bunny-lab.io/GitOps/awx.bunny-lab.io/src/branch/main/playbooks/Linux/Establish_Kerberos_Connection.yml)
|
||||
|
||||
!!! warning "Ansible w/ Kerberos is **not** for beginners"
|
||||
I advise against jumping into the deep-end with setting up Kerberos authentication for your playbooks until you have made yourself more comfortable with how Kubernetes works, or at the very least, you need to read the linked documentation above very closely to ensure nothing goes wrong during the setup.
|
||||
|
||||
### Security
|
||||
Security playbooks do things like secure devices with additional auditing functionality, login notifications, enforcing SSH certificate-based authentication, things of that sort.
|
||||
|
||||
- Install SSH Public Key Authentication
|
||||
- PLACEHOLDER (not documented)
|
||||
- SSH Login Notifications
|
||||
- PLACEHOLDER (not documented)
|
||||
|
||||
## Windows Playbooks
|
||||
### Deployments
|
||||
Deployment playbooks are meant to be playbooks (or a series of playbooks forming a "Workflow Job Template") that deploy a server or piece of software.
|
||||
- Hyper-V - Deploy GuestVM
|
||||
- PLACEHOLDER (not documented)
|
||||
- Query Active Directory Domain Computers
|
||||
- PLACEHOLDER (not documented)
|
||||
- Install BGInfo
|
||||
- PLACEHOLDER (not documented)
|
||||
|
||||
## Related Documentation
|
||||
- [Related AWX Documentation](<index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
tags:
|
||||
- AWX
|
||||
- Gitea
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Understand how an AWX project supplies playbooks and inventory files from source control. Maintain the Gitea connection settings in the connection workflow so the project reference does not become a second configuration source.
|
||||
|
||||
## Project Relationships
|
||||
A project identifies the repository and source-control credential. An inventory source can consume an inventory file from that project, and a job template selects a playbook from the project.
|
||||
|
||||
## Configure the Connection
|
||||
[Connect AWX to Gitea](<../../../workflows/Automation/AWX/Connect AWX to Gitea.md>) contains the source URL, credential fields, inventory source, and overwrite behavior.
|
||||
|
||||
## Continue to Job Execution
|
||||
[The AWX guide](<index.md>) connects inventory structure, credential examples, and job-template configuration.
|
||||
|
||||
## Related Documentation
|
||||
- [Related AWX Documentation](<index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
tags:
|
||||
- AWX
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
# AWX
|
||||
## Purpose
|
||||
Follow AWX from its Kubernetes deployment through source control, inventory, credentials, and job execution. Check the environment context on older Minikube and credential examples before combining them with the operator deployment.
|
||||
|
||||
## Includes
|
||||
- Controller deployment and upgrades
|
||||
- Projects, inventories, credentials, and templates
|
||||
- Gitea and Windows authentication integration
|
||||
|
||||
## Build the Controller
|
||||
- [Rancher RKE2](<../../../deployments/Containers/Kubernetes/Rancher RKE2.md>) — Prepare the cluster required by the AWX Operator procedure.
|
||||
- [AWX Operator](<../../../deployments/automation/AWX/AWX Operator.md>) — Deploy the controller into the documented cluster.
|
||||
- [Minikube Example](<../../../deployments/automation/AWX/AWX in Minikube.md>) — Consult the separate deployment approach and its recorded assumptions.
|
||||
|
||||
## Connect the Automation Objects
|
||||
A project supplies repository content. An inventory identifies targets and variables. Credentials provide authentication, and a job template combines these objects with a playbook.
|
||||
|
||||
- [Connect AWX to Gitea](<../../../workflows/Automation/AWX/Connect AWX to Gitea.md>) — Create the source credential, project, and inventory source together.
|
||||
- [Projects and Source Control](<Projects and Source Control.md>) — Understand the project role without maintaining a second copy of its connection settings.
|
||||
- [Inventory Structure](<Inventory Structure and Variables.md>) — Understand host groups and variables before changing the lab inventory.
|
||||
- [Credential Examples](<Credential Configuration Examples.md>) — Review the recorded environment and authentication limitations.
|
||||
- [Job Templates](<Job Template Configuration.md>) — Connect the project, inventory, playbook, and credentials.
|
||||
- [Lab Inventory](<../../Lab Map/Homelab Server Inventory.md>) — Locate the recorded hosts and inventory groups.
|
||||
|
||||
## Run Against Windows Targets
|
||||
- [Prepare Windows Targets](<../../../workflows/Identity and Certificates/Windows/Enable WinRM over HTTPS.md>) — Configure the remote-management endpoint used by the automation examples.
|
||||
- [Configure AWX Kerberos](<../../../workflows/Automation/AWX/AWX Kerberos Implementation.md>) — Follow the execution-environment and FQDN requirements recorded for this implementation.
|
||||
- [Custom WinRM Credential](<Custom Kerberos WinRM Credential.md>) — Find the credential input and injector definitions.
|
||||
- [Playbook Catalog](<Playbook Catalog.md>) — Find existing repository playbooks and the catalog completeness notes.
|
||||
Reference in New Issue
Block a user