Add a throwaway domain controller job to CI for the domain modules

Aperta
  • Qualcosa non va?
#124 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, powershell
Ambito
ci-cd, documentation, testing

Direzione di ricerca

Start in .github/workflows/ci.yml by adding a windows-dc job that promotes a runner with Install-ADDSForest and runs Pester domain-controller tests. Read docs/Conventions.md section 9 and docs/lab/README.md for runner expectations, and mirror the existing linux/windows job triggers. Done means the new job fails on promotion failure, a sample Domain Admins test passes, and firewall tests on other runners finish without losing connection.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: tests-ci platform: windows type: build

Read first

Read these before starting. If this issue and the spec disagree, the spec wins; say so in the pull request.

Summary

Several Windows modules change or read a domain, and CI cannot test them without one. Add a CI job that turns a fresh Windows Server runner into a single domain controller (the server that holds a Windows domain's accounts), so those modules' real-host tests run on every change instead of only by hand in the lab. Also give real-host module tests a rule for the runners, so a default-deny firewall or a rotated credential cannot cut a runner off from GitHub and leave the job hanging.

Depends on

  • Blocked by nothing.
  • Blocks #83 (Windows protocol and credential settings), #84 (domain read-only checks) and #103 (the remaining domain hardening).

Location & Context

  • Branch: the Roadmap names none for this issue. Use a name for the change, such as ci/domain-controller. No module ID.
  • .github/workflows/ci.yml: the changes, linux and windows jobs, and the new windows-dc job (new). Both existing test jobs already set LAB_REALSYSTEM=1, so each module's real-host tests under tests/ run on the disposable Ubuntu and Windows Server runners as soon as they are written.
  • docs/Conventions.md section 9 and docs/lab/README.md: the third runner that Conventions section 9 plans, a throwaway single domain controller, does not exist yet.
  • Existing real-host test pattern: tests/core/RealSystem.Tests.ps1.

Current Behavior

The domain modules cannot be tested on a real domain in CI: #84 (domain read-only checks), #82 (admin accounts, which on a domain controller are domain accounts), #83 (Windows protocol settings on a domain controller) and #103 (the remaining domain hardening). Their acceptance tests would only run in the lab, by hand, so a change can break them unnoticed until the next lab pass.

Real-host module tests on the existing runners also have a risk the core tests did not: a default-deny firewall (#78) or a rotated credential (#75) can cut the runner off from GitHub, so the job hangs instead of failing.

Plan

  1. Add a windows-dc job that promotes a fresh Windows Server runner to a single-domain forest (Install-ADDSForest with a throwaway domain name and password made at run time), then runs the Pester tests tagged for a domain controller with LAB_REALSYSTEM=1. Make the existing windows job skip those tagged tests, which need a domain.
  2. Run the new job under the same condition as the other test jobs: when the changes job finds a change outside the documentation paths.
  3. Give the real-host module tests a rule for the runners: keep the runner's own outbound connection to GitHub allowed, set a job timeout, and undo every change at the end of the test even when it fails.
  4. Record in docs/lab/README.md which module tests run on which runner, and keep the older-system tests in the lab.
  5. Write the tests below.

Acceptance tests

  • The new job fails if the promotion fails, rather than skipping the domain tests.
  • A sample domain test (a planted extra member of Domain Admins is listed) passes on the runner.
  • A firewall test on the Ubuntu and Windows runners finishes and reports, without losing the runner.

Done when

  • The new job passes in CI, and the existing linux and windows jobs still pass.
  • docs/lab/README.md lists which module tests run on which runner, and Conventions section 9 matches.
  • The runner rule for real-host tests is written where module authors will read it (Conventions section 9).

Out of scope

  • The domain modules and their tests: #83, #84, #103 and #82.
  • The firewall module and credential rotation, which must follow the runner rule: #78 and #75.
  • Tests that need older systems, several hosts or a SIEM: they stay in the lab.
Lingua principale
PowerShell
Stelle
0
Fork
0
Merge medio
2h 7m
PR unite (30g)
53

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnetdork/Labyrinth

Tutte le issue di dotnetdork/Labyrinth

Issue simili

Altre issue su DevOps

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.