DebOps

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

All commits are pushed to the main repositories of the project at https://github.com/debops after review by one of the maintainers (refer to Organizational Structure).

Repository on GitHub, which uses git. git is distributed.

The DebOps project uses Semantic Versioning v2.0.0 to tag each release, as mentioned in the Changelog.

Signed git tags are used to make releases.

The DebOps project keeps track of the changes using a Changelog, any changes between releases that users might need to apply in their environment are described using Upgrade notes.

Any known vulnerabilities will be mentioned in the Changelog as the primary source of such information in the DebOps project. So far, there were no CVE assignments related to DebOps.

GitHub issues are currently preferred to the affected repository of the project. If in doubt, report against one of the following issue trackers:

• https://github.com/debops/debops-playbooks/issues
• https://github.com/debops/debops-tools/issues

The issue tracker of GitHub is currently used.

The project is quite active and reported issues get proper attention.

The project is quite active and enhancement requests get proper attention. The DebOps Developers try to incorporate enhancement but due to the size of the project, not all enhancements can be implemented in a timely manner because of the lack of DebOps Developers.

DebOps Security Policy

DebOps Security Policy

Travis CI and GitLab CI are used to perform continuous integration services used to maintain DebOps. The project includes an extensive test suite, with Travis-CI builds as well as GitLab CI builds available for public review.

This project uses the configuration management engine Ansible as the core part of the project which is considered to be a common tool.

The project mainly targets Debian GNU/Linux using Ansible.

Travis CI and GitLab CI are used to perform continuous integration services used to maintain DebOps. The project includes an extensive test suite, with Travis-CI builds as well as GitLab CI builds available for public review.

The DebOps test suite can be invoked using the make test command with included Makefile. Specific parts of the test can also be executed by selecting them from a list of available tests, accessible by the make help command. The same tests are performed on each pull requests via Travis CI.

DebOps test suite checks the syntax of the included YAML files, Python and Bash scripts, Dockerfile, project documentation as well as validates the Ansible role and playbook syntax using ansible-playbook and ansible-lint tools provided by the Ansible project.

Travis CI and GitLab CI are used to perform continuous integration services used to maintain DebOps. The project includes an extensive test suite, with Travis-CI builds as well as GitLab CI builds available for public review.

Pull Requests to the DebOps repository on GitHub are checked using Travis CI for any syntax issues in the code and documentation. The tests have to pass correctly before merging, any changes are reviewed before being merged to the master branch.

List of merged pull requests can be reviewed publicly. Each pull request contains information about tests done on Travis-CI and their result.

The project's test suite uses ansible-lint, yamllint, shellcheck and pycodestyle commands to check the validity of the included codebase.

Any warnings found by the linter tests are reported as errors, and need to be addressed before changes to the project can be merged.

Any warnings found by the linter tests are reported as errors, and need to be addressed before changes to the project can be merged.

Maciej Delmanowski (project founder, Project Leader) and Robin `ypid` Schneider (DebOps Developer joined in February 2015) both claim to know how to securely operate IT systems by experience.

The threat model of the project is to protect managed systems against an adversary gaining access to the system. Furthermore, if access can be gained to one of the systems, that system must not be able to compromise the Ansible controller which stores all configuration management state. It does not include the system administrator (user of the project) in the threat model (e. g. does not do extensive input validation). The system administrator is trusted in that he/she can compromise the security of the whole system.

Security by default is a goal of the project but the highest security must be sometimes explicitly enabled because enabling it by default is expected to limit functionality (example: sshd__paranoid, refer to ypid-ansible-inventory which provides presets for this).

Having said that, this criteria is currently not fully met, especially "keep the design as simple and small as practical" (ref: problem with redundancy).

Maciej Delmanowski (project founder, Project Leader) and Robin `ypid` Schneider (DebOps Developer joined in February 2015) both claim to know common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them.

Having said that, Robin `ypid` Schneider is currently not confident that this criteria is fully met yet.

Default cryptographic protocols and algorithms that the project uses include:

• Protocols: TLS/HTTPS, DH, SSH
• Algorithms: RSA, DH

Cryptography algorithms are not implemented by the project but instead, public implementations like OpenSSL, GnuTLS, OpenSSH and GnuPG are used.

The main implementations include OpenSSL, GnuTLS, OpenSSH and GnuPG which are all FLOSS projects.

Cryptographic mechanisms used in the project define required key lengths using variables which can be changed if needed to improve security. The default lengths of keys created by the project are based on current known best practices, for example those described on the BetterCrypto.org or Cipherli.st websites.

Applies to debops.nginx and other roles working with TLS and (E)DH.

The project relies on OpenSSL, GnuTLS and other software implementing cryptography protocols and algorithms to use cryptographically secure (P)RNG and the Linux kernel and the hardware to provide sufficient entropy. Example role: debops.pki

We are working on improving that even further. Example: Enhance system-wide known hosts support for SSH

The DebOps Developers are not aware of any static code analysis tool for Ansible configuration management code.

See above.

See above.

See above.