## Summary
Previously, `CODER_PPROF_ADDRESS` and `CODER_PROMETHEUS_ADDRESS` were
hardcoded in the Helm chart template to `0.0.0.0:6060` and
`0.0.0.0:2112` respectively. These values could not be overridden via
`coder.env` values because the hardcoded values were set first in the
template, and Kubernetes uses the first occurrence of duplicate env
vars.
This was a security concern because binding to `0.0.0.0` exposes these
endpoints to any pod in the cluster:
- **pprof** can expose sensitive runtime information (goroutine stacks,
heap profiles, CPU profiles that may contain memory contents)
- **Prometheus metrics** may contain sensitive operational data
## Changes
1. **`helm/coder/templates/_coder.tpl`**: Added logic to check if the
user has set `CODER_PPROF_ADDRESS` or `CODER_PROMETHEUS_ADDRESS` in
`coder.env` before applying the default values. If the user provides a
value, the hardcoded default is skipped.
2. **`helm/coder/values.yaml`**: Updated documentation to:
- Remove these vars from the "cannot be overridden" list
- Add them to a new "can be overridden" section with security
recommendations
3. **Tests**: Added test cases for both override scenarios with
corresponding golden files.
## Usage
Users can now restrict pprof and prometheus to localhost only:
```yaml
coder:
env:
- name: CODER_PPROF_ADDRESS
value: "127.0.0.1:6060"
- name: CODER_PROMETHEUS_ADDRESS
value: "127.0.0.1:2112"
```
## Local Testing
To verify the fix locally:
```bash
# Update helm dependencies
cd helm/coder && helm dependency update
# Test default behavior (should show 0.0.0.0)
helm template coder . -f tests/testdata/default_values.yaml --namespace default | grep -A1 'CODER_PPROF_ADDRESS\|CODER_PROMETHEUS_ADDRESS'
# Test pprof override (should show 127.0.0.1:6060)
helm template coder . -f tests/testdata/pprof_address_override.yaml --namespace default | grep -A1 'CODER_PPROF_ADDRESS'
# Test prometheus override (should show 127.0.0.1:2112)
helm template coder . -f tests/testdata/prometheus_address_override.yaml --namespace default | grep -A1 'CODER_PROMETHEUS_ADDRESS'
# Run Go tests
cd tests && go test . -v
```
Fixes#21713
---------
Co-authored-by: blink-so[bot] <211532188+blink-so[bot]@users.noreply.github.com>
Co-authored-by: uzair-coder07 <uzair@coder.com>
Liveness checks are currently causing pods to be killed during
long-running migrations.
They are generally not advisable for our workloads; if a pod becomes
unresponsive we _need_ to know about it (due to a deadlock, etc) and not
paper over the issue by killing the pod.
I've also made all probe settings configurable.
---------
Signed-off-by: Danny Kopping <danny@coder.com>
This is a feature to create Role & RoleBinding entries on a per
namespace basis to support deploying workspaces in separate namespace to
where Coder is deployed. The idea behind this is to avoid the creation
of custom RBAC entries or the use of ClusterRoles (in order to maintain
priciple of least privilege).
> If you have used AI to produce some or all of this PR, please ensure
you have read our [AI Contribution
guidelines](https://coder.com/docs/about/contributing/AI_CONTRIBUTING)
before submitting.
This is a blink assisted PR.
Example `helm template` without
`coder.serviceAccount.workspaceNamespaces` enabled (existing behaviour
as of current release) is below. Outcome = 1 x SA, 1 x Role, 1 x
RoleBinding, all in the coder (`.Release.Namespace`) namespace.
```
➜ coder git:(feat/helm_namespace_rbac_improvements) ✗ helm template -n coder coder . --set coder.image.tag=v2.25.1
---
...
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: coder-workspace-perms
namespace: coder
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: "coder"
namespace: coder
subjects:
- kind: ServiceAccount
name: "coder"
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: coder-workspace-perms
---
```
Example `helm template` *with*
`coder.serviceAccount.workspaceNamespaces` enabled is below. Outcome = 1
x SA, 1 x Role, 1 x RoleBinding, all in the coder (`.Release.Namespace`)
namespace PLUS a Role and RoleBinding in the `dev-ws` namespace with
each of the RoleBindings referencing the coder SA in the coder
(`.Release.Namespace`) namespace:
```
➜ coder git:(feat/helm_namespace_rbac_improvements) ✗ helm template -n coder coder . --set coder.image.tag=v2.25.1 --set-json 'coder.serviceAccount.workspaceNamespaces=[{"name":"dev-ws","workspacePerms":true,"enableDeployments":true,"extraRules":[]}]'
---
...
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: coder-workspace-perms
namespace: coder
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: coder-workspace-perms
namespace: dev-ws
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: "coder"
namespace: coder
subjects:
- kind: ServiceAccount
name: "coder"
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: coder-workspace-perms
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: "coder"
namespace: dev-ws
subjects:
- kind: ServiceAccount
name: "coder"
namespace: coder
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: coder-workspace-perms
---
```
Makes `initialDelaySeconds` configurable for both `readinessProbe` and
`livenessProbe` in the Helm chart.
**Changes:**
- Added `coder.readinessProbe.initialDelaySeconds` and
`coder.livenessProbe.initialDelaySeconds` to `values.yaml`
- Updated `_coder.tpl` template to use these configurable values
- Defaults to 0 seconds to maintain existing behavior
**Testing:**
- Verified template rendering with default values (0)
- Verified template rendering with custom values (30, 60)
- Both probes correctly use the configured `initialDelaySeconds`
---------
Co-authored-by: blink-so[bot] <211532188+blink-so[bot]@users.noreply.github.com>
Co-authored-by: kylecarbs <7122116+kylecarbs@users.noreply.github.com>
Added namespace to all resources in the helm chart and added tests to ensure that coder can be deployed in non-default namespaces, as specified via the namespace flag in the helm command.
Ways to verify this:
- current state:
```bash
$ helm template my-coder coder -n coder --version 2.19.0 --repo https://helm.coder.com/v2 | yq '.metadata.namespace'
null
---
null
---
null
---
null
---
null
```
- fixed state when checking out this PR:
```bash
$ helm template my-coder ./helm/coder -n coder --set coder.image.tag=latest | yq '.metadata.namespace'
coder
---
coder
---
coder
---
coder
---
coder
```
Change-Id: Ib66d4be9bcc4984dfe15709362e1fe0dcd3e847f
Signed-off-by: Thomas Kosiewski <tk@coder.com>
## Short description:
This pull request introduces support for optionally specify `nodePort`
values when using `LoadBalancer` service type in the Coder Helm chart.
This enhancement addresses a limitation where `httpNodePort` and
`httpsNodePort` values were previously ignored for `LoadBalancer`
services. This PR should expand the service customization options
without disrupting existing configurations.
## Why this is Useful
In some enterprise environments, applications may be required to use
specific ports for compliance with organizational policies or cloud
infrastructure requirements. For instance:
- Reserved port blocks are allocated for specific applications for
security and clarity.
- Ensuring predictable port assignments helps in debugging and
management scenarios.
Since LoadBalancer in Kubernetes operates on top of nodePort, this
feature is useful for enabling enterprises to adhere to such policies if
they whish.
## What Was Changed
- Updated helm/coder/templates/service.yaml:
- Allowed nodePort specification for both NodePort and LoadBalancer
service types.
- Updated helm/coder/templates/values.yaml:
- Updated inline comments to reflect the changes for nodeport values use
cases.
### Regarding backward compatibility:
If nodePort is not specified, Kubernetes dynamically assigns a port,
maintaining the current behavior.
### Testing Performed
- Validated through Helm dry-run: nodePort values are rendered correctly
in the resulting Kubernetes YAML.
- Deployed the updated chart in an enterprise Kubernetes cluster.
- Tested coder environment with LoadBalancer service and specified
nodePort values for both HTTP and HTTPS.
## Additional Notes
- This PR expands the nodeport functionality introduced in PR #8993 to
the Loadbalancer service.
- If merged, an update to the documentation to include examples of
LoadBalancer with nodePort values may be useful.
- I've read the contributing guidelines and code of conduct. This is my
first PR for the Coder project, and I hope it meets the community
standards. Any advice, feedback, or help is greatly appreciated!
This PR removes the prometheus-http port entirely from the coder service specification (originally added in #10448). It also removes the Helm value coder.service.prometheusNodePort.
Rationale: some cloud providers will helpfully expose all ports on a LoadBalancer service for you. The net effect of this is that setting CODER_PROMETHEUS_ENABLE will end up exposing port 2112 on your coderd service to the internet, which is likely undesired behaviour.
* add support for NodePort service type in Helm chart
* fix nodeport values
* formatting & make update-golden-files
* update-golden-files
---------
Co-authored-by: Eric <ericpaulsen@coder.com>
