Inviscid/SSW590-DevOps
2
0 Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

chore: organize into folders

Browse Source
This commit is contained in:
rand committed 2026-09-26 02:06:30 -04:00
1 parent ca41ea3567
commit f0b352791c
14 files changed
+24 -24
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

chapters/devopsDocumentGuide.tex
+142
View File
@@ -0,0 +1,142 @@
\chapter{Document Authoring Guide}
\ChapterLabel{DocumentGuide}
\index{LaTeX}
\index{document conventions}
\index{Appendix!Document Authoring Guide}
\section{How to Use This Appendix}
Use this appendix to maintain the template's file conventions, build process,
and review rules. Update it when the document structure or toolchain changes.
\section{Template Provenance}
This template was developed by \textbf{Darian Muresan, Ph.D.}, in conjunction
with \textbf{OpenAI Codex} and \textbf{Anthropic Claude Code}. Keep this
attribution distinct from the assignment-specific instructor metadata.
\section{File Naming and Responsibilities}
Every chapter file shall use the \texttt{devops} prefix, a PascalCase chapter
name, and the \texttt{.tex} suffix. Each such file shall contain one complete
chapter, beginning with \texttt{\string\chapter\{...\}}, and all of its
sections and subsections. Do not split one chapter into section-level
\texttt{.tex} files. For example, all of Chapter~2 is contained in
\path{chapters/devopsExampleAssignment.tex}. Do not add requirements or
architecture-design chapters; this template records a DevOps learning activity
and its operational evidence.
\section{Synonyms and Controlled Terms}
\index{synonyms}
Use one preferred term for each important concept. If an assignment uses
equivalent terms, record them here before release. For example, state whether
``continuous delivery'' refers to \gls{cd} generally or specifically excludes
automatic production deployment. Add important terms to
\texttt{backmatter/glossary.tex} and index them where used.
\section{Building the PDF}
The template requires a LaTeX distribution with \texttt{pdflatex},
\texttt{bibtex}, \texttt{makeglossaries}, and \texttt{makeindex}.
Install the tools using the platform instructions below, then run one of the
following platform builds.
\subsection{macOS and Linux Build}
\begin{verbatim}
make -f makefileMacLinux pdf
\end{verbatim}
\subsection{Windows PowerShell Build}
\begin{verbatim}
.\makefilePowerShell.ps1 -Action pdf
\end{verbatim}
The completed build regenerates references, bibliography, glossary, and index.
Review the log and visually inspect affected PDF pages. Do not edit generated
auxiliary files or the PDF directly.
\section{Install LaTeX Tools on macOS}
\index{macOS}
\index{MacTeX}
\subsection{Recommended Installation}
Install the current full \href{https://www.tug.org/mactex/}{MacTeX}
distribution. It includes TeX Live, \texttt{pdflatex}, \texttt{bibtex},
\texttt{latexmk}, \texttt{makeglossaries}, \texttt{makeindex}, and useful
applications such as TeXShop and TeX Live Utility. The full distribution is the
least troublesome choice for this template because it includes the packages
used by the glossary, table, listing, color, and hyperlink features.
Either download the signed installer from the MacTeX web site and complete the
macOS installation dialog, or, if Homebrew is already installed, run:
\begin{verbatim}
brew install --cask mactex
\end{verbatim}
Close and reopen Terminal after installation. If the TeX commands are not
found, add the MacTeX binary directory to the current shell session:
\begin{verbatim}
export PATH="/Library/TeX/texbin:$PATH"
\end{verbatim}
Do not place this command in a shell profile until it has been verified on the
local computer.
\subsection{Verification and Compilation}
From the template directory, verify the tools:
\begin{verbatim}
command -v pdflatex bibtex latexmk makeglossaries makeindex
\end{verbatim}
Each command should print a path. Then create the PDF:
\begin{verbatim}
make -f makefileMacLinux pdf
\end{verbatim}
To remove generated intermediate files while keeping the PDF, run:
\begin{verbatim}
make -f makefileMacLinux clean
\end{verbatim}
\section{Install LaTeX Tools on Windows}
\index{Windows}
\index{MiKTeX}
\subsection{Recommended Installation}
Install the current Basic MiKTeX distribution using the official
\href{https://miktex.org/howto/install-miktex}{MiKTeX Windows installation
guide}. During installation, choose a per-user installation when appropriate
and set missing-package installation to \emph{Ask me first} or \emph{Yes}.
The latter is convenient for a student machine with Internet access; the former
makes each package installation explicit.
Open MiKTeX Console after installation, apply available updates, and install
the \texttt{latexmk} package if the verification command below cannot find it.
On an organization-managed computer, obtain approval before installing software
or changing execution policy.
\subsection{Verification and Compilation}
Open a new PowerShell window in the template directory and verify:
\begin{verbatim}
Get-Command pdflatex,bibtex,latexmk,makeglossaries,makeindex
\end{verbatim}
Each command should display a command record. Build the PDF with:
\begin{verbatim}
.\makefilePowerShell.ps1 -Action pdf
\end{verbatim}
If PowerShell blocks the script under a managed execution policy, ask the
system administrator for the approved procedure. Do not bypass institutional
security policy. To remove intermediate build files, run:
\begin{verbatim}
.\makefilePowerShell.ps1 -Action clean
\end{verbatim}
\section{Common Build Problems}
\begin{tabularx}{\linewidth}{L{3.0cm}Y}
\toprule \textbf{Symptom} & \textbf{Resolution}\\ \midrule
Command not found & Close and reopen the terminal. On macOS, verify the TeX
binary path; on Windows, verify MiKTeX completed installation and is on the user PATH.\\
Missing LaTeX package & Use MiKTeX Console or its approved on-the-fly package
installation prompt on Windows. On macOS, install the full MacTeX distribution
or use TeX Live Utility to add the missing package.\\
References or glossary incomplete & Run the supplied platform build instead of
a single \texttt{pdflatex} command; it runs BibTeX, the glossary tool, and the
index tool in the required order.\\
Script is blocked & Follow the institution's approved PowerShell policy or run
the documented build commands with an approved administrator.\\ \bottomrule
\end{tabularx}
\section{Authoring and Review Rules}
Replace bracketed placeholders with assignment facts. Keep operational examples
safe, bounded, and free of credentials. Link activities to evidence, retain
history, and state unknowns or instructor decisions explicitly. Rebuild after
structural, cross-reference, table, glossary, or index changes.
chapters/devopsExampleAssignment.tex
+126
View File
@@ -0,0 +1,126 @@
\chapter{Example Assignment}
\ChapterLabel{ExampleAssignment}
\index{activity brief}
\index{workflow}
\index{automation}
\index{infrastructure as code}
\index{evidence}
\index{observability}
\index{rollback}
\index{retrospective}
\index{continuous improvement}
\index{submission}
\index{cleanup}
\section{Activity Brief}
\subsection{Scenario}
Describe the operational scenario and why it matters. Use a bounded,
non-production system. \textit{Example: A team must deploy a small service
reliably to a remote Linux host and recover from a failed release.}
\subsection{Activities}
Assign stable IDs to each assessed activity. Add rows as needed.
\begin{tabularx}{\linewidth}{L{2.1cm}L{3.1cm}Y}
\caption{Activity Register\label{Table:ActivityRegister}}\\
\toprule \textbf{ID} & \textbf{Activity} & \textbf{Completion criterion}\\ \midrule
\ActivityID{ACT-01} & \textit{[Prepare environment]} & \textit{[repeatable environment baseline is present]}\\
\ActivityID{ACT-02} & \textit{[Automate workflow]} & \textit{[workflow runs from documented inputs]}\\
\ActivityID{ACT-03} & \textit{[Observe and recover]} & \textit{[evidence shows monitoring and recovery]}\\ \bottomrule
\end{tabularx}
\subsection{Success Criteria}
State observable outcomes, not implementation prescriptions. Include security,
cost, cleanup, and reproducibility criteria where applicable.
\subsection{Assessment Rubric}
\begin{tabularx}{\linewidth}{L{3.2cm}L{2.0cm}Y}
\toprule \textbf{Criterion} & \textbf{Weight} & \textbf{Evidence expected}\\ \midrule
Reproducible workflow & \textit{[points]} & \textit{[automation and clean-run proof]}\\
Operational quality & \textit{[points]} & \textit{[observability, rollback, security]}\\
Evidence and explanation & \textit{[points]} & \textit{[commands, outputs, rationale]}\\
Reflection & \textit{[points]} & \textit{[failure analysis and improvement]}\\ \bottomrule
\end{tabularx}
\section{Workflow and Implementation}
\subsection{Environment Baseline}
Specify the authorized environment, prerequisites, access model, versioned
inputs, and teardown procedure. Record commands in a repository script or
infrastructure-as-code definition; do not rely on a sequence of undocumented
console clicks.
\subsection{Procedure}
For each activity, state the goal, input, command or automation entry point,
expected result, and rollback or cleanup action. Link the corresponding
activity identifier and evidence identifier.
\begin{lstlisting}[language=bash,caption={Replace with a safe, repeatable workflow entry point.}]
# ./scripts/provision.sh --environment sandbox
# ./scripts/deploy.sh --version <tag>
# ./scripts/destroy.sh --environment sandbox
\end{lstlisting}
\subsection{Operational Controls}
Describe least-privilege access, secret handling, logging, monitoring, change
control, budget guardrails, backup or rollback, and resource cleanup. A secret
shall be referenced by its approved storage location, never pasted into this
document or committed to the repository.
\subsection{Failure Exercise}
Define one safe failure or degradation scenario. State the trigger, expected
signal, diagnosis path, recovery action, and evidence required. Never direct
students to disrupt shared or production infrastructure.
\section{Evidence Register}
\subsection{How to Use This Section}
Evidence demonstrates an actual execution; an expected result is not evidence.
Use sanitized command output, logs, screenshots, links to versioned files, or
recorded metrics. Redact secrets and personal information.
\begin{tabularx}{\linewidth}{L{1.7cm}L{2.2cm}L{2.6cm}Y}
\caption{Evidence Register\label{Table:EvidenceRegister}}\\
\toprule \textbf{ID} & \textbf{Activity} & \textbf{Evidence type} & \textbf{Location and interpretation}\\ \midrule
\EvidenceID{EVD-01} & \ActivityRef{ACT-01} & \textit{[log / script / image]} & \textit{[repository path or sanitized URL; what it demonstrates]}\\
\EvidenceID{EVD-02} & \ActivityRef{ACT-02} & \textit{[pipeline output]} & \textit{[location; result and relevant timestamp]}\\
\EvidenceID{EVD-03} & \ActivityRef{ACT-03} & \textit{[monitoring / recovery output]} & \textit{[location; failure signal and recovery result]}\\ \bottomrule
\end{tabularx}
\subsection{Evidence Quality Checks}
Evidence should identify the executed version, environment, time, command or
automation entry point, outcome, and any deviation from the expected result.
State failures plainly; they are valuable inputs to the retrospective.
\section{Retrospective}
\subsection{Outcome}
Summarize what happened, including completed work, gaps, and unexpected
behavior. Distinguish facts from interpretation.
\subsection{Flow and Feedback}
Identify queues, handoffs, manual steps, slow feedback, and sources of rework.
Explain which changes improved delivery flow or made failures visible sooner.
This emphasis on flow, feedback, and continual learning is consistent with the
DevOps framing introduced in \cite{PhoenixProject}.
\subsection{Improvement Experiments}
Propose one or more small, testable improvements. State the hypothesis, change,
measurement, expected result, and risk. Do not represent a proposal as an
approved production change.
\subsection{Team Contributions}
For team assignments, concisely identify each member's meaningful contribution
and any collaboration constraints.
\section{Submission and Cleanup}
\subsection{Submission Checklist}
\begin{itemize}
\item Versioned automation, configuration, and runbook are committed.
\item Evidence links resolve and contain no secrets or personal data.
\item The retrospective is complete and distinguishes results from proposals.
\item Remote resources have been destroyed or explicitly transferred as directed.
\item The repository identifies the final commit or release tag.
\end{itemize}
\subsection{Academic Integrity and Responsible Use}
Follow the course policy for collaboration and AI assistance. Cite external
code, tutorials, and AI-generated material as required by the instructor.
Students remain responsible for understanding, testing, and explaining all
submitted work.
chapters/devopsHosts.tex
+83
View File
@@ -0,0 +1,83 @@
\chapter{Hosts}
\ChapterLabel{Hosts}
\index{hosts}
\index{hosts!inventory}
\index{hosts!naming convention}
\index{development environment}
\index{Amazon EC2}
\section{Purpose}
This chapter names the hosts that will make up the development environment for
\CourseNumber\ and records the role, platform, and ownership of each. It is an
inventory of intent: no machine listed here has been provisioned, and the chapter therefore
presents no execution \gls{evidence}. It is expected to grow as later
assignments add services to the environment.
\section{Naming Convention}
\index{hosts!naming}
Each \gls{host} that is provisioned for this course is named
\texttt{ssw590-\textit{role}-\textit{nn}}, where \textit{role} identifies the
function the machine serves and \textit{nn} is a two-digit ordinal within that
role. Naming by role rather than by instance identifier keeps the name stable
if the underlying machine is replaced, and keeps the inventory readable when
more than one host serves the same purpose. Hosts that already exist
independently of this course retain their existing names.
\section{Host Inventory}
\index{hosts!table}
The \textbf{Status} column distinguishes machines already in use from those that
will be configured in a later assignment. A host is marked \emph{In service}
only once it exists and is reachable.
\begin{tabularx}{\linewidth}{L{3.0cm}YL{3.3cm}L{2.0cm}}
\caption{Planned Host Inventory\label{Table:HostInventory}}\\
\toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule
\endfirsthead
\multicolumn{4}{l}{\small\itshape Planned Host Inventory (continued)}\\
\toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule
\endhead \bottomrule \endlastfoot
\texttt{ssw590-dev-01} & Primary Linux host for the course. Target for service configuration, deployment exercises, and command-line work. & Ubuntu Server LTS on Amazon EC2 & Planned\\
\texttt{ssw590-build-01} & Build and integration host, kept separate from the deployment target so that a failed build cannot disturb a running service. To be provisioned only if a later assignment requires it. & Ubuntu Server LTS on Amazon EC2 & Conditional\\
\end{tabularx}
\section{Access and Ownership}
\index{hosts!access model}
\index{least privilege}
All hosts listed above are owned and administered by the author. The following
rules govern access to the Linux hosts once they are provisioned.
\begin{itemize}[leftmargin=*]
\item Interactive access is by \gls{ssh} public key only.
Password authentication is disabled in the server configuration.
The local account password recorded in \ChapterRef{Passwords} authenticates \texttt{sudo} only.
\item Inbound \gls{ssh} is restricted by source address to the workstation
listed above rather than opened to the public Internet.
\item Day-to-day work is performed by an unprivileged account. Administrative
rights are granted per command rather than by general membership in the
\texttt{sudo} group.
\item Should a teammate require access after teams are formalized, that person
receives a separate named account rather than a shared login, so that
access can be revoked individually and actions remain attributable.
\end{itemize}
\section{Cost and Cleanup}
\index{hosts!cost}
\index{hosts!teardown}
The Linux hosts are expected to run on the smallest instance size that supports
the coursework, under whatever free-tier or credit allowance the account
provides, with a billing alarm configured before the first instance is
launched. Compute is billed per instance-hour, and attached storage whether or
not the instance is running, so each additional host adds cost independently of
how heavily it is used: provisioning \texttt{ssw590-build-01} alongside
\texttt{ssw590-dev-01} would approximately double the compute cost of the
environment. It is therefore left unprovisioned until an assignment requires
builds to be isolated from the deployment target, and would be stopped between
uses rather than run continuously; only \texttt{ssw590-dev-01} needs to remain
available at all times.
Each planned host is disposable. Teardown consists of terminating the instance,
deleting the attached storage volume, and releasing any static address reserved
for it; a static address left reserved after the instance is gone continues to
be billed. Because the \gls{ami} and the configuration steps are recorded, a
terminated host can be rebuilt rather than preserved, which is why teardown is
treated as routine rather than exceptional.
chapters/devopsIntroduction.tex
+69
View File
@@ -0,0 +1,69 @@
\chapter{Introduction}
\ChapterLabel{Introduction}
\index{introduction}
\index{DevOps}
\index{scope}
\index{deliverables}
\section{Purpose}
This document records the configuration of the development environment used for
\CourseNumber\ and the working practices followed to produce it. For
Assignment~\AssignmentNumber\ it covers three subjects: the \gls{kanban} that
plans and tracks the assignment work, the hosts the environment will comprise,
and the passwords that will govern accounts on those hosts.
It is a working record rather than a one-time report. Each subsequent
assignment extends it, and the document history records what changed and when,
so that the state of the environment at any point in the term can be recovered
from this document alone.
\section{Scope and Constraints}
\index{scope!constraints}
The following constraints apply to this revision.
\begin{itemize}[leftmargin=*]
\item The environment is \emph{specified} here, not provisioned. The hosts
chapter names the machines to be configured and their intended roles; it
does not claim that any host exists, and it therefore presents no
execution \gls{evidence}.
\item No credential, access token, private key, or account secret appears in
this document. Password rules are documented by derivation hint only, as
described in \ChapterRef{Passwords}.
\item This is an individual submission. Teams have not yet been formalized, so
the board described in \ChapterRef{KanbanSetup} is operated by a single
person and every card is assigned to the author.
\item The document is authored in \LaTeX\ and compiled with pdf\LaTeX\ on
Overleaf. The board is hosted in GitHub Projects. The planned environment
targets Amazon EC2.
\end{itemize}
\section{Deliverables and Due Date}
\begin{tabularx}{\linewidth}{L{3.2cm}Y}
\toprule \textbf{Item} & \textbf{Expectation}\\ \midrule
Due date & \DueDate\\
Instructor & \Instructor\\
Board & GitHub Projects, \texttt{SSW 590} (private; captured as figures in \ChapterRef{KanbanSetup})\\
Required deliverables & Compiled document; Kanban Setup, Passwords, and Hosts chapters; updated document history\\
Team policy & Individual submission pending team formalization\\ \bottomrule
\end{tabularx}
\section{Document Organization}
\index{document organization}
\ChapterRef{KanbanSetup} describes the tool selected for the board, the steps
taken to configure it, the policy governing each column, and the inventory of
cards. \ChapterRef{Hosts} names the hosts to be configured and
their roles. \ChapterRef{Passwords} defines the account and password rules for those hosts. \ChapterRef{AIPromptLog} records AI assistance used in preparing
this document.
This document is derived from the \CourseNumber\ assignment template credited on
the Template Attribution page. The template's instructional example chapter and
its template-maintenance appendices have been removed, since they describe how
to author the template rather than the environment this document records.
\section{Tools and AI Assistance}
\index{AI assistance}
AI assistance was used in preparing this document for drafting, review, and
troubleshooting. It was not used to generate results, command output, or
evidence of work that was not performed. Material assistance is recorded in
\ChapterRef{AIPromptLog} with the task, the inputs supplied, the output used,
and the corrections applied by the author.
chapters/devopsKanbanSetup.tex
+95
View File
@@ -0,0 +1,95 @@
\chapter{Kanban Setup}
\ChapterLabel{KanbanSetup}
\index{Kanban}
\index{Kanban!board configuration}
\index{Kanban!column policy}
\index{work in progress}
\index{GitHub Projects}
\index{flow}
\section{Purpose}
This chapter records how the Kanban board for this assignment was selected,
configured, and used. The board makes the work of producing this document
visible, bounds the amount of work in progress, and provides a single place
where the state of each deliverable can be checked. It covers the tasks of this
assignment only; a board for the semester project will be established separately
once teams are formalized.
\section{Tool Selection}
\index{Kanban!tool selection}
The board was created with \textbf{GitHub Projects}. GitHub was selected as the
platform of choice for familiarity and simplicity; the board and versioned document
live in the same account, and draft items can be created without opening a repository issue.
\section{Board Configuration}
\index{Kanban!setup steps}
The board was configured in the following order.
\begin{enumerate}[leftmargin=*]
\item Created a new project from the account-level Projects page and selected
the board layout, which provisions a \texttt{Status} field with the
columns \texttt{Todo}, \texttt{In progress}, and \texttt{Done}.
\item Replaced the default column descriptions with the explicit entry and exit
criteria recorded in Table~\ref{Table:ColumnPolicy}, so that the meaning
of each column is explicit.
\item Set a \gls{wip} limit of two items on the \texttt{In progress}
column.
\item Added one card per deliverable of this assignment, as listed in
Table~\ref{Table:CardInventory}, entering each as a draft item.
\item Assigned every card to its owner so that the board
is the record of who holds each task.
\item Moved cards across columns as the work was actually performed, rather than
reconstructing the board before submission.
\end{enumerate}
\section{Column Policy}
\index{Kanban!definition of done}
Each column states the condition a card must satisfy to enter it. The
\texttt{Done} condition is written so that it can be checked against the
compiled document rather than judged by opinion.
\begin{tabularx}{\linewidth}{L{2.6cm}Y}
\caption{Kanban Column Policy\label{Table:ColumnPolicy}}\\
\toprule \textbf{Column} & \textbf{Entry and exit criteria}\\ \midrule
\texttt{Todo} & Ready to be worked on.\\
\texttt{In progress} & Actively being worked on by its assignee. 2 in-progress cards max.\\
\texttt{Done} & Chapter compiles and is referenced in document history.\\
\bottomrule
\end{tabularx}
\section{Card Inventory}
\index{Kanban!card inventory}
The board carries one card per assignment deliverable. Identifiers follow the
activity convention used elsewhere in this document so that cards and document
content can be cross-referenced.
\begin{tabularx}{\linewidth}{L{1.8cm}L{4.4cm}L{2.2cm}Y}
\caption{Kanban Card Inventory\label{Table:CardInventory}}\\
\toprule \textbf{ID} & \textbf{Card} & \textbf{Column} & \textbf{Completion criterion}\\ \midrule
\endfirsthead
\multicolumn{4}{l}{\small\itshape Kanban Card Inventory (continued)}\\
\toprule \textbf{ID} & \textbf{Card} & \textbf{Column} & \textbf{Completion criterion}\\ \midrule
\endhead \bottomrule \endlastfoot
\ActivityID{ACT-01} & Compile Overleaf template & \texttt{Done} & The unmodified template builds in Overleaf with no unresolved references and a populated glossary and index.\\
\ActivityID{ACT-02} & Create Kanban Setup chapter & \texttt{In progress} & This chapter compiles into the document and describes the board's configuration and use.\\
\ActivityID{ACT-03} & Define Hosts chapter; define hosts & \texttt{Todo} & The chapter compiles and contains the planned host table.\\
\ActivityID{ACT-04} & Create Passwords chapter; create password rule & \texttt{Todo} & The chapter compiles and contains the user, server, and rule table with password hints.\\
\ActivityID{ACT-05} & Log document history and AI usage & \texttt{Todo} & The newest version entry is recorded at the top of the history table and links to the changed chapters, with any AI assistance logged.\\
\end{tabularx}
\section{Work-in-Progress Policy}
\index{work in progress!limit}
The \texttt{In progress} column is limited to two cards. The limit is paired
with a rule that a blocked card returns to \texttt{Todo} with its blocker
recorded. The limit was chosen deliberately to avoid uncontrolled parallel work,
especially because this assignment is sequential in places.
\section{Evidence}
\index{evidence!Kanban board}
\begin{figure}[htbp]
\centering
\includegraphics[width=\linewidth]{figures/kanbanboard.png}
\caption{Kanban board after the assignment cards were added, showing the
work-in-progress limit on the \texttt{In progress} column.}
\label{Figure:KanbanBoard}
\end{figure}
chapters/devopsPasswords.tex
+70
View File
@@ -0,0 +1,70 @@
\chapter{Passwords}
\ChapterLabel{Passwords}
\index{passwords}
\index{passwords!policy}
\index{passwords!derivation rule}
\index{credentials}
\index{least privilege}
\section{Purpose}
This chapter records the accounts that will exist in the development
environment described in \ChapterRef{Hosts} and the rule governing the password
for each. No password appears here. Where a password is derived by rule, the
register records the hint needed to reconstruct it rather than its value; where
a password is machine-generated, the register records where it is stored rather
than what it is.
\section{Password Classes}
\index{passwords!classes}
Accounts fall into two classes, distinguished by whether the secret has to be
recalled from memory.
\begin{itemize}[leftmargin=*]
\item \textbf{Generated.} The secret is produced at random by a password
manager, is unique to the account, and is never typed from memory. This
class is preferred, and every account that can use it does.
\item \textbf{Derived.} The secret is constructed in the register.
This class is reserved for the small number of secrets that must
be entered when the password manager is not available.
\end{itemize}
Keeping the derived class as small as possible is deliberate. A derivation rule
is a concession to human memory, not a security improvement, so it is applied
only where a generated secret cannot be retrieved.
\section{Account and Rule Register}
\index{passwords!register}
\begin{tabularx}{\linewidth}{L{2.4cm}L{2.9cm}L{1.9cm}Y}
\caption{Account, Server, and Password Rule Register\label{Table:PasswordRegister}}\\
\toprule \textbf{User} & \textbf{Server or service} & \textbf{Class} & \textbf{Rule and hint}\\ \midrule
\endfirsthead
\multicolumn{4}{l}{\small\itshape Account, Server, and Password Rule Register (continued)}\\
\toprule \textbf{User} & \textbf{Server or service} & \textbf{Class} & \textbf{Rule and hint}\\ \midrule
\endhead \bottomrule \endlastfoot
\texttt{root} & \texttt{ssw590-dev-01} & None & No password. Administrative access is obtained through \texttt{sudo} by a named account, so that privileged actions are attributable.\\
\texttt{payton} & \texttt{ssw590-dev-01}, \texttt{ssw590-build-01} & Derived & Used only to authenticate \texttt{sudo}; \gls{ssh} password authentication is disabled, so this secret never crosses the network.
\textit{Psst... sudo is a name, no?}\\
\texttt{ssw-app} & \texttt{ssw590-dev-01} & Generated & Unprivileged service account for course applications. Secret held in a file readable only by that account, excluded from the repository, and rotated per deployment.\\
Master & Password manager vault & Derived & A memorized password that isn't stored in its own vault.
\textit{Surely it's secure, no lie?}\\
Root user & AWS account & Generated & Reserved for account recovery and billing; \gls{mfa} enforced, not used for routine work.\\
\texttt{payton-admin} & AWS console, \gls{iam} & Generated & Day-to-day console account. \gls{mfa} enforced. Programmatic access uses short-lived credentials rather than a stored key pair.\\
\end{tabularx}
\section{Handling and Storage}
\index{passwords!handling}
\index{secrets}
The following rules apply to every entry above.
\begin{itemize}[leftmargin=*]
\item No password, private key, access token, or recovery code is recorded anywhere non-secure.
A secret is referred to by the location that holds it.
\item \gls{mfa} is enabled on every account that supports it.
\item A generated password is rotated by replacement. Any password is
rotated immediately if it is disclosed, and knowing one password
does not provide insight into other passwords.
\item Service credentials on a \gls{host} are supplied through a file or
environment variable owned by the service account, with access restricted
to that account, rather than being embedded in application source.
\end{itemize}