Docs scanner fixes#24998
Conversation
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟡 NEEDS ATTENTION
This PR restructures ECI protection categories and updates policy precedence descriptions. The table conversion in configure-admin-console.md is a clear improvement. However, three factual accuracy questions in the changed lines need author confirmation before merging.
|
|
||
| - Containers created with `docker run` and `docker create` | ||
| - Containers using the `docker-container` build driver | ||
| - Kubernetes with the Kind provisioner |
There was a problem hiding this comment.
[HIGH] Version constraint silently dropped: Kubernetes/Kind ECI support moved to "Always protected"
The previous text stated: Kubernetes: Protected in Docker Desktop 4.38+ when using the kind provisioner (under the "Version dependent" section). The new text moves Kubernetes with the Kind provisioner to "Always protected" with no version qualifier.
If Kind provisioner ECI support is now available in all supported Docker Desktop versions, this change is correct. However, if the 4.38+ requirement still applies to some users, removing it without explanation could mislead users on older Docker Desktop versions into thinking their Kind-based Kubernetes workloads are always protected when they may not be.
Please confirm this change is intentional and that Kind support is now universal across all supported Docker Desktop releases.
There was a problem hiding this comment.
change is intentional
There was a problem hiding this comment.
Thanks for confirming! I'll resolve this thread.
|
|
||
| - Docker Build: Protected in Docker Desktop 4.30+ (except WSL 2) | ||
| - Kubernetes: Protected in Docker Desktop 4.38+ when using the kind provisioner | ||
| - Docker Build: Protected in Docker Desktop for Mac, Linux, and Windows with Hyper-V backend |
There was a problem hiding this comment.
[HIGH] Docker Build ECI: version floor (4.30+) dropped from description
The previous text read: Docker Build: Protected in Docker Desktop 4.30+ (except WSL 2). The new text reads: Docker Build: Protected in Docker Desktop for Mac, Linux, and Windows with Hyper-V backend.
The platform list (Mac, Linux, and Windows with Hyper-V backend) correctly conveys the same exclusion as the old "except WSL 2" wording — these are semantically equivalent. However, the version floor 4.30+ has been removed entirely.
Users running Docker Desktop versions older than 4.30 would see the new text and incorrectly assume Docker Build is protected on their platform, when it may not be. If Docker Desktop 4.30 is now the minimum supported version and this constraint no longer needs documenting, please add a brief note confirming this intentional removal.
There was a problem hiding this comment.
change is intentional
There was a problem hiding this comment.
Thanks for confirming! Since the version floor removal is intentional, this resolves my concern. The platform-specific information alone is sufficient for users to understand Docker Build protection scope.
| 1. Organization default policy: Applied when no user-specific policy exists | ||
| 1. Local `admin-settings.json` file: Lowest priority, overridden by Admin Console policies | ||
| 1. [Configuration profiles](/manuals/enterprise/security/enforce-sign-in/methods.md#configuration-profiles-method-mac-only): Super-set of Docker Admin Console policies. | ||
| 1. [Configuration profiles](/manuals/enterprise/security/enforce-sign-in/methods.md#configuration-profiles-method-mac-only) when used to control proxy settings |
There was a problem hiding this comment.
[MEDIUM] Configuration profiles description narrowed — verify factual accuracy
The previous text described configuration profiles as: Super-set of Docker Admin Console policies.
The new text scopes this to: when used to control proxy settings
These have very different meanings. The old text implied configuration profiles override all Admin Console policies (making them the highest-priority mechanism). The new text limits this to proxy settings only.
Notably, the new narrower scope is more logically consistent with its position as item 4 (lowest priority) in the precedence list — a true "super-set" of all policies would typically rank first, not last. If the old text was an overstatement and configuration profiles only override proxy-related settings, the new text is a useful correction.
Please confirm: do configuration profiles only affect proxy settings, or do they also override other Admin Console policies? If the scope is broader than proxy settings, the new text may be too narrow and could cause administrators to miss relevant behavior.
There was a problem hiding this comment.
the new text is more accurate
There was a problem hiding this comment.
Thanks for confirming! I'll resolve this thread since the narrower scope is the correct representation. Good catch on improving the accuracy — the previous wording would have been misleading for administrators trying to understand the actual behavior of configuration profiles.
3 participants
Description
Closes #24957
Closes #24969
Supersedes and closes #24972
Related issues or tickets
Reviews