33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
# 2026-04-26 — NamespaceManager rewrite, step 2
|
|
|
|
## Цель шага
|
|
|
|
Убрать еще один прямой проход по `FissionResourceNS` и закрыть конкретный баг в
|
|
`pkg/utils/serviceaccount.go`.
|
|
|
|
## Проблема
|
|
|
|
`runSACheck()` сейчас:
|
|
|
|
1. итерируется по `sa.nsResolver.FissionResourceNS` напрямую;
|
|
2. переиспользует переменную `ns` внутри внутреннего цикла по permissions.
|
|
|
|
Из-за этого код выглядит безобидно, но фактически смешивает два разных namespace path:
|
|
|
|
- fetcher path через `GetFunctionNS()`;
|
|
- builder path через `GetBuilderNS()`.
|
|
|
|
Если `FunctionNamespace` и `BuilderNamespace` различаются, builder SA может начать
|
|
резолвиться уже не от исходного namespace, а от результата предыдущего шага цикла.
|
|
|
|
## Что меняем
|
|
|
|
1. Берем base namespaces через thread-safe `Snapshot()`.
|
|
2. Для каждого permission вычисляем `targetNS` из исходного `baseNS`, а не из мутированной переменной.
|
|
3. Добавляем unit test на routing function/builder namespace.
|
|
|
|
## Что НЕ меняем на этом шаге
|
|
|
|
- не трогаем глобальные `fetcherCheck` / `builderCheck` структуры;
|
|
- не меняем `LocalSubjectAccessReview` path;
|
|
- не делаем большой refactor всего SA provisioning. |