Repository navigation
Update granular permissions docs - #3510
liam-mackie wants to merge 2 commits into
Conversation
|
Pull request environment is available at https://stoctodocspr3510.z22.web.core.windows.net/. You can view the ephemeral environment status in Octopus Deploy. This environment will be automatically deprovisioned when the pull request is closed, or after 7 days of inactivity. |
| ### Best practices | ||
|
|
||
| - **Keep default script pod permissions minimal.** Deployments with no matching `WorkloadServiceAccount` fall back to these permissions. See [installing on a cluster with existing agents](#installing-on-a-cluster-with-existing-agents). | ||
| - **Grant only the access each deployment needs.** Prefer namespaced permissions and specific resources and verbs over `"*"`. Remember that omitted scope fields match any value, and permissions from all matching definitions are combined. | ||
| - **Review and verify changes.** Keep permission definitions in version control, limit who can edit them, and [check the permissions assigned to a deployment](#validating-assigned-permissions). |
There was a problem hiding this comment.
This section is a bit more AI coded than the rest and doesn't really fit under the "Who should use this feature" heading.
I feel like the value of these points is pretty low, it's just repeating what should be common practises for the target audience of this feature. I'd say only the first point is relevant, and that is already stated further down.
So I'd say scrap it, or at least put it under a level 2 heading if you want to keep it.
| This list **replaces automatic discovery** and bypasses the regex and Deployment label requirement. Include every agent or worker namespace you want to manage. Set `TARGET_NAMESPACES` back to `""` to restore discovery. | ||
|
|
||
| Apply either example to the **permissions controller's Helm release**, not the agent or worker release. See the [chart values](https://github.com/OctopusDeploy/octopus-permissions-controller/blob/main/dist/chart/values.yaml) for more settings. | ||
|
|
There was a problem hiding this comment.
This section is a little bit wordy for what it's goal is, what do you think of structuring it something like the below? Just thinking it pushes people towards the method we want them to use, while also giving all the options. Sorry for the formatting
Default behaviour
By default, the controller finds Deployments labeled app.kubernetes.io/name: octopus-agent, then filters their namespaces with ^octopus-(agent|worker)-.*. This matches names starting with octopus-agent- or octopus-worker-, such as octopus-agent-prod, but not my-octopus-agent-prod or octopus-agent.
This will match any Kubernetes agent or worker installed with default namespace settings.
Provide a list of target namespaces (recommended)
For security, it's recommended to simply provide a fixed list of namespaces that you would like the permission controller to create service accounts (and so, control the agents/workers) in. Use a comma-separated string with no spaces:
manager:
envOverrides:
TARGET_NAMESPACES: "team-deploy-agent,shared-build-worker"This list replaces automatic discovery and bypasses the regex and Deployment label requirement. Include every agent or worker namespace you want to manage. Set TARGET_NAMESPACES back to "" to restore discovery.
Target namespaces with regex
The regex controlling this can be overriden to suit your naming convention by using the TARGET_NAMESPACE_REGEX environment variable. It uses Go regex syntax. As an example, if you wanted to match on platform-agent-* or platform-worker-* namespaces, you could use this example values file:
manager:
envOverrides:
TARGET_NAMESPACES: ""
TARGET_NAMESPACE_REGEX: '^platform-(agent|worker)-.+$'There was a problem hiding this comment.
Agreed - I'll update the PR with it now 😄
3 participants
This PR adds documentation around the target namespaces for the permissions controller, as well as explicit recommendations to use the target namespaces.