Esan cwcow change - #10273
Draft
Takuro Sato (takuro-sato) wants to merge 7 commits into
Draft
Conversation
Assisted-by: GitHub-Copilot copilot-review Signed-off-by: Tingmao Wang <tingmaowang@microsoft.com> (cherry picked from commit 72c0de5)
Windows VN2 pods need CCE policies that match what actually lands in the container at runtime. The mount *sources* are still emitted by the (Linux) mounthost as sandbox:///tmp/atlas/emptydir/.+, but the *destination* paths are translated to Windows form by k8s/containerd/hcsshim (e.g. /var/run/secrets/... -> C:\var\run\secrets\..., /etc/hosts -> C:\Windows\System32\drivers\etc\hosts). Windows managed identity also exposes IDENTITY_ENDPOINT, which Linux does not. Branch VN2 mounts and injected env and mount rules based on platform (linux/amd64 vs windows/amd64): - Add Windows mount sets (C:\ destinations; empty user/privileged sets) and managedIdentityWindows env rules (adds IDENTITY_ENDPOINT). - IDENTITY_ENDPOINT is WCOW-only for now to avoid changing a bunch of LCOW tests. - config.py: platform-aware get_default_mounts_*_virtual_node() helpers. - container.py: pick Windows env rules (managed identity + restart only; OPENGCS/FABRIC stay Linux-specific) and Windows VN2 mounts by platform. - security_policy.py: route the VN2 privileged / workload-identity mount call sites through the platform-aware helpers. Assisted-by: GitHub Copilot:claude-opus-4.8 Signed-off-by: Tingmao Wang <tingmaowang@microsoft.com> (cherry picked from commit 42cecaf)
Signed-off-by: Tingmao Wang <tingmaowang@microsoft.com> (cherry picked from commit 32a06b7)
Signed-off-by: Tingmao Wang <tingmaowang@microsoft.com> (cherry picked from commit 773679c)
Support the log_provider enforcement point from hcsshim PR Azure#2763 (CWCOW: Logging enforcement) in the Windows policy producer. The Windows rego policy template now wires log_provider and emits allow_log_provider_dropping plus an allowed_log_providers list. There is no ARM property for log providers, so the allow-list is settable only through the --input JSON via the new allowedLogProviders and allowLogProviderDropping fields. allow_log_provider_dropping defaults to true, mirroring allow_environment_variable_dropping, so providers outside the allow-list are dropped rather than denied. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Takuro Sato <takurosato@microsoft.com>
|
Hi Takuro Sato (@takuro-sato), |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Thank you for your contribution Takuro Sato (@takuro-sato)! We will review the pull request and get back to you soon. |
Member
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
Bump api_version to 0.12.0 and framework_version to 0.5.0 to match the hcsshim CWCOW policy framework, and add the enforcement points introduced by PR Azure#2842. The Windows policy template now wires registry_changes, unmount_cims, host_network and load_transparency_trust_list, and emits the allow_host_network, allow_unencrypted_scratch, allow_capability_dropping and allow_registry_changes_dropping switches. The Linux policy template wires host_network and load_transparency_trust_list (newly active at api_version 0.12.0) and emits allow_host_network, which has no framework default. The fragment and sidecar templates are bumped to framework_version 0.5.0. These enforcement points have no ARM property, so they are exposed only through confcom-owned --input (-i) JSON fields, mirroring the log-provider fields: the top-level allowHostNetwork and allowRegistryChangesDropping bools, the per-container registryChanges object (passed through in the hcsshim add_values/delete_keys shape), and the top-level mappedDirectories list. mapped_directory_mount/unmount are wired only when mappedDirectories is supplied, since wiring them without backing data can only deny; an undeclared hot-add is denied by the framework either way. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Takuro Sato <takurosato@microsoft.com>
Elastic SAN volumes on Confidential ACI are bind-mounted into the workload container by the atlas mounthost from /tmp/atlas/esanVolume/<deployment>/<volume>, analogous to Azure File's /tmp/atlas/azureFileVolume/... . Register a matching "elasticSan" mount type so CCE policies accept the Elastic SAN volume mount. The type name matches the ARM/CCE volume property (Volume.ElasticSan -> "elasticSan") and the source mirrors the azureFile entry, both per Compute-ACI release/rel-20260429. Compute-ACI also places a Linux pod that mounts an Elastic SAN volume on the host network (iscsid needs the UVM init netns), so the generated policy for such a pod must allow the host_network enforcement point (added in Azure#2842). Detect the elasticSan mount type and force allow_host_network on for Linux policies, leaving the flag at its default False otherwise. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Takuro Sato <takurosato@microsoft.com>
Takuro Sato (takuro-sato)
force-pushed
the
esan-cwcow-change
branch
from
August 28, 2026 20:15
8a44a06 to
f5a1311
Compare
Collaborator
|
confcom |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 PR Validation — ️✔️ All clear
This checklist is used to make sure that common guidelines for a pull request are followed.
Related command
General Guidelines
azdev style <YOUR_EXT>locally? (pip install azdevrequired)python scripts/ci/test_index.py -qlocally? (pip install azdevrequired)For new extensions:
About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update
src/index.jsonautomatically.You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify
src/index.json.