Update README.md

README.md

@@ -23,21 +23,47 @@ With Secure GitHub Self-Hosted Runner, it's now safe to run a self-hosted runner
 
 This project provides a solution by:
 
-1. Starting a rootless runner container on demand, without any host mounts.
-2. This container starts the GitHub Runner.
-3. The GitHub Runner can then use podman (podman-in-podman) to start yet another container for the job (if the job is configured to run in a container).
-4. After the job is executed, the container is deleted.
+1. Monitoring GitHub workflows and jobs using the GitHub API.
+2. When a job needs to be executed, the main program calls the appropriate executor.
+3. The executor's `prepare` stage sets up the environment, typically starting a GitHub Runner instance.
+4. Once the environment is ready, the main program calls the executor's `run` stage to execute the job.
+5. After the job is completed, the main program calls the executor's `cleanup` stage to destroy the environment.
 
-We use the GitHub API to monitor workflows and jobs, starting a container only when one is needed to execute a job.
+The main program performs two primary functions:
+- Monitors for jobs that need to be run.
+- Calls the executor's scripts (`prepare`, `run`, `cleanup`) with the appropriate environment variables gathered from the GitHub API.
 
 ## Key Features
 
 - Isolated Execution: Each job runs in a clean, isolated environment.
-- On-Demand Containers: Containers are created only when needed and destroyed after use.
+- On-Demand Environments: Execution environments are created only when needed and destroyed after use.
 - Rootless Containers: Enhanced security through rootless container execution.
-- Podman-in-Podman: Nested containerization when jobs are configured to run in containers.
+- Flexible Executors: Support for different execution environments.
 - Pre-Execution Filtering: Opportunity to examine and filter jobs before execution.
 
+## Executors
+
+Executors are responsible for preparing, running, and cleaning up the environment for each job. A key security feature of our executors is the use of rootless podman, ensuring that no part of the execution process has root access to the system.
+
+Currently, we support two types of executors:
+
+1. Podman-in-Podman: This executor uses nested containerization, running the GitHub Runner in a nested rootless podman container.
+2. Libvirtd-in-Podman: This executor runs the GitHub Runner in a freshly booted virtual machine using libvirtd/qemu from within a rootless podman container.
+
+Both executors leverage rootless podman, providing an additional layer of security by ensuring that the execution environment has no root access to the host system.
+
+Each executor consists of three main scripts:
+
+- `prepare.sh`: Sets up the execution environment, typically starting a GitHub Runner instance.
+- `run.sh`: Executes the job within the prepared environment.
+- `clean.sh`: Cleans up and destroys the environment after job completion.
+
+The main program calls these scripts as needed for each job execution, passing the appropriate environment variables.
+
+### Adding New Executors
+
+The system is designed to be extensible. New executors can be added as needed by creating the three required scripts (`prepare.sh`, `run.sh`, and `clean.sh`) and integrating them into the main program. This flexibility allows for adaptation to various execution requirements and environments. When adding new executors, it's recommended to maintain the principle of using rootless containers to ensure consistent security across all execution methods.
+
 ## Security Advantages
 
 Our process includes a pre-execution phase where we can examine workflow and job details, including the account requesting the job. This enables:
@@ -46,6 +72,8 @@ Our process includes a pre-execution phase where we can examine workflow and job
 - Filtering based on workflow or job information
 - Custom security rules as defined by the administrator
 
+Additionally, the use of rootless podman in our executors ensures that the execution environment has no root access to the host system, significantly enhancing overall security.
+
 ## Getting Started
 
 ```