Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Policy selection is nondeterministic when several policies allow one image; add container_names routing and deny on ambiguity

Đã đóng
  • Có gì không ổn?
#85 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Một pull request liên quan đã được merge.

  • #90 của @abienkowski — đã merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
18/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
docker, go, rust, typescript
Lĩnh vực
api, security

Hướng nghiên cứu

Start from GetByImage, which returns the first matching policy while iterating a map, and from the POST /containers/create handler that uses its result. Adding container_names routing and load-time ambiguity checks touches all three implementations and the Quint model. Pull request #90 is already open against this issue, so check it before starting. Done means the same image and name always select one policy, and ambiguous matches return 403.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Priority: P1 Type: Bug

Describe the bug

When more than one loaded policy allows the same image, the policy applied to a create is effectively random. GetByImage returns the first policy whose prefixes match while iterating a map: Go map and Rust HashMap iteration order is randomized, so the choice can change from one request to the next; TypeScript's Map keeps load order, so the first-loaded policy always wins. The selected policy decides the forced container_config.user, the volume whitelist and the flag rules, so a container can be created with another service's settings.

This is a normal layout, not an edge case: services built from one image need different policies. Lodestar's beacon node and validator client both run chainsafe/lodestar with different users and data directories, so in a one-trust-domain deployment (README "Trust model") validator creates intermittently get the beacon policy — forced to the beacon user and refused their own data directory.

Affected implementation(s)

  • Go
  • Rust
  • TypeScript
  • All

To Reproduce

  1. Two policies in one --config-dir: 
    # a.yaml
service_name: svc-a
allowed_image_prefixes: [alpine]
container_config: { user: "1111:1111" }
# b.yaml
service_name: svc-b
allowed_image_prefixes: [alpine]
container_config: { user: "2222:2222" }
  2. Through the proxy, docker create alpine:3.20 true six times, restart the proxy, repeat (three runs).
  3. Forced users observed (Go v0.3.11): 
    run 1: 1111 1111 1111 1111 1111 1111
run 2: 1111 2222 1111 1111 1111 1111
run 3: 1111 1111 1111 1111 1111 1111

Expected behavior

Policy selection is deterministic, and services that share an image can be told apart.

Proposed:

  1. Optional container_names in a policy (e.g. container_names: [beacon]). On POST /containers/create, select the policy whose image prefixes match and whose container_names contains the request's ?name=. A policy without container_names matches any name, as today.
  2. Exactly one match, otherwise deny. Zero matches → 403 as today; more than one → 403 with an ambiguity error naming the matching policies. Validate at load time too: two policies that could both match the same image and name should fail startup.

The name is chosen by the caller, so this is routing, not access control — consistent with the trust model, where every caller of a socket already holds the union of its policies.

Environment

  • OS: Ubuntu 22.04.5
  • Docker version: Engine 29.9.0 (API 1.56)
  • Implementation version/commit: v0.3.11 (3130b0a), Go binary

Additional context

Needed by ChainSafe/lodestar-infrastructure's deployment of this proxy (beacon and validator from one image). The Quint model would need the container name as an input to state "the applied policy is the unique match for (image, name)".

Ngôn ngữ chính
Rust
Star
2
Fork
0
Merge trung bình
12 giờ 11 phút
Pull request đã merge (30 ngày)
30

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ChainSafe/docker-socket-policy

Tất cả issue của ChainSafe/docker-socket-policy

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.