MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description gitlab-org/gitlab#474994+ is introducing support for accessing image_pull_secrets on the Kubernetes cluster to allow workspaces access to private container registries. Secrets data is sensitive and we would like to reduce the scope of secrets the remote-development module can observe. As part of the referenced issue, we [apply filters](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/1811#note_2155954824) to restrict informer access to secrets that match how an image_pull_secret looks. To further reduce the scope, we have the following ideas: ### Listen in only on namespaces supplied as part of the agent-config This entails fetching all the namespaces specified under the `image_pull_secrets` section in the configs for all returned workspaces we want the agent to reconcile and listen in only on those namespaces. This approach means we would need to restart the informer whenever there is a diff in the set of namespaces we previously had and a new set received from Rails. This approach also introduces the need for a prerequisite fetch by the agent to retrieve a starting set of valid namespaces to listen in on remote-development module initialization. ## Acceptance Criteria TODO: update criteria with specifics when we get consensus regarding the idea(s) above. - [ ] Reduce the scope of secret access in the remote-development module <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://handbook.gitlab.com/handbook/engineering/development/dev/create/remote-development/#-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->