- Virtual Networking
- Bastille CI/CD
- Template Maturity & Consolidation
- Container Monitoring
- Bastille API
Rough timeline and description below.
VNET (Virtual Networking) will allow fully virtualized network stacks. This would bring the total network options to three (loopback, LAN, VNET). The anticipated design would use a bridge device connected to containers via epair interfaces.
While we have many of the templates validated by automatic CI/CD, we are not validating updates to Bastille itself. This automated validation of Pull Requests should be a priority early in the year with a full test suite designed to validate all expected uses of Bastille sub-commands.
Put the 101 templates found in GitHub's BastilleBSD-Templates repository into GitLab CI/CD pipeline until fully covered. This is a great place for community contribution. Templates are easy to create and verify and we'd love to replicate as much of the FreeBSD ports tree as possible!
In addition, it would be nice to create a consolidated repository of curated templates similar in design to the FreeBSD ports tree. This would contain all templates in a single repository and mimick ports behavior where appropriate.
The ability to monitor processes, services, mounts, sockets, etc from the host. Auto-remediation would be simple enough to define. Notifications would probably require a plugin system for methods/endpoints.
Possible monitoring modules: ps, sockstat, pf, fstab
Possible notification modules: pagerduty, slack, splunk, ELK, etc.
I have thoughts about a lightweight API for Bastille that would accept (json?) payloads of Bastille commands. The API should be lightweight just as Bastille is.
The API is scheduled later in the roadmap because I want to have the other components stable before we implement an API on top of it. The addition of the API should match up with Bastille 1.0-stable.