mrcharles
a7fbad60ab
Comprehensive documentation gardening across the merged repo: - tailscale.md: fully rewritten with current ground truth. The netinfra pair now runs production Technitium with all knel.net records replicated. Both LAN IPs resolve knel.net device names and recurse externally. The old "NXDOMAIN / zone is stale" findings are replaced with the resolved state and current recommendations. - AGENTS.md: rewritten with Gitea-compatible clickable relative links to all key scripts and docs. Autonomous commit/push policy prominently documented. SSH user corrected to localuser. - README.md: directory table and docs table now use clickable links. - All .md cross-references converted to Gitea-renderable relative links. - Stale path references (ProjectCode/, Project-Tests/, ProjectDocs/) updated to current names (provisioning/, tests/) across all docs. - Stale repo name "FetchApply" / "KNELServerBuild" updated to "PFVCluster" in actionable docs; historical AI-review docs tagged with an HTML comment notice. - REFACTORING-EXAMPLES.md: tagged as historical (pre-refactor patterns). - tests/README.md, dns-cluster-setup/README.md, docs/DEPLOYMENT.md, docs/SECURITY.md: path references fixed to current structure. 🤖 Generated with [Crush](https://github.com/charmassociates/crush) Assisted-by: GLM-5 via Crush <crush@charm.land>
2.5 KiB
2.5 KiB
AI Security Audit of KNELServerBuild
This is an AI-generated security audit of the KNELServerBuild project. The analysis is based on a read-only review of the project's files.
Summary of Findings
The KNELServerBuild project has a good security posture overall, but there are a few areas that could be improved. The most significant finding is the presence of SSH authorized keys in the repository. This is a security risk, as it allows anyone with access to the repository to know which public keys are authorized to access the servers.
High-Risk Findings
- SSH Authorized Keys in Repository: The
provisioning/ConfigFiles/SSH/AuthorizedKeysdirectory contains SSH authorized keys for thelocaluserandrootusers. This is a security risk, as it allows anyone with access to the repository to know which public keys are authorized to access the servers.
Medium-Risk Findings
- Hardcoded Hostnames: The scripts contain several hardcoded hostnames for services like Postfix, NTP, syslog, and Wazuh. This is not a direct security risk, but it does represent a configuration management issue. If any of these hostnames change, they will need to be updated in multiple places.
Low-Risk Findings
- Potential for Password on Command Line: The
provisioning/Agents/librenms/mysql.shscript has a--passargument for a MySQL password. This is a potential security risk if the password is provided on the command line, as it could be logged in the shell history.
Recommendations
- Remove SSH Authorized Keys from Repository: The SSH authorized keys should be removed from the repository and managed using a secrets management tool like HashiCorp Vault or AWS Secrets Manager.
- Use Variables for Hostnames: The hardcoded hostnames should be replaced with variables that are defined in a central configuration file. This will make it easier to update the hostnames if they change.
- Avoid Passwords on Command Line: The
provisioning/Agents/librenms/mysql.shscript should be modified to avoid passing the MySQL password on the command line. For example, the script could prompt the user for the password or read it from a configuration file.
Overall, the KNELServerBuild project is a good starting point for an IAC repository. By addressing the security risks identified in this audit, the project can be made more secure and reliable.