Cis Docker 7.5
DevOps & Securitycis-docker-7.5Cis Docker 7.5 is an Agent Skill for devops & security published in the CyberStrikeus/CyberStrike repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.
Ensure that swarm manager is run in auto-lock mode
How to use this skill
Bring this guide into your coding agent with a prompt tailored to the tool you use.
- Open your project in Codex.
- Copy and paste the prompt below.
- Review files and risks before approving any action.
Inspect the Agent Skill at https://github.com/CyberStrikeus/CyberStrike/blob/HEAD/.cyberstrike/skill/CIS_benchmarks/Server_Software/Docker/CIS_Docker_Benchmark_v1.8.0/cis-docker-7.5/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/cis-docker-7-5, but wait for my approval before writing files or running scripts.
Copying this prompt does not install or run the skill. Review third-party files before use.
7.5 Ensure that swarm manager is run in auto-lock mode (Manual)
Profile Applicability
- Level 1 - Docker Swarm
Description
You should review whether you wish to run Docker swarm manager in auto-lock mode.
Rationale
When Docker restarts, both the TLS key used to encrypt communication among swarm nodes, and the key used to encrypt and decrypt Raft logs on disk, are loaded into each manager node's memory. You could protect the mutual TLS encryption key and the key used to encrypt and decrypt Raft logs at rest. This protection could be enabled by initializing the swarm with the --autolock flag.
With --autolock enabled, when Docker restarts, you must unlock the swarm first, using a key encryption key generated by Docker when the swarm was initialized.
This has benefits in a high security environment, however these should be balanced against the support issues caused by the swarm not starting automatically if, for example the host were to experience an outage.
Impact
A swarm in auto-lock mode will not recover from a restart without manual intervention from an administrator to enter the unlock key. This may not always be desirable, and should be reviewed at a policy level.
Audit Procedure
You should run the command below
docker info --format 'Swarm Autolock: {{ .Swarm.Cluster.Spec.EncryptionConfig.AutoLockManagers }}'
If the result is true, auto-lock mode is enable.
You could also run the command below. If a key value is returned, it means that the swarm was initialized with the --autolock flag. If the output is no unlock key is set, it means that swarm was NOT initialized with the --autolock flag. This should be reviewed in line with the organization's IT Security policy.
docker swarm unlock-key
Remediation
If you are initializing a swarm, use the command below.
docker swarm init --autolock
If you want to set --autolock on an existing swarm manager node, use the following command.
docker swarm update --autolock
Default Value
By default, the swarm manager does not run in auto-lock mode.
References
CIS Controls
| Controls Version | Control | IG 1 | IG 2 | IG 3 |
|---|---|---|---|---|
| v8 | 3.11 Encrypt Sensitive Data at RestEncrypt sensitive data at rest on servers, applications, and databases containing sensitive data. Storage-layer encryption, also known as server-side encryption, meets the minimum requirement of this Safeguard. Additional encryption methods may include application-layer encryption, also known as client-side encryption, where access to the data storage device(s) does not permit access to the plain-text data. | ● | ● | |
| v7 | 14.8 Encrypt Sensitive Information at RestEncrypt all sensitive information at rest using a tool that requires a secondary authentication mechanism not integrated into the operating system, in order to access the information. | ● |