## Context
PR #259 introduced support for running Gitea as a uid different than 1000 (git) or 0 (root).
## Problem
In init_directory_structure.sh, there is a "chown 1000:1000" on /tmp/gitea.
This chown only works when running as root or when the target directory is already owned by uid 1000.
As a result, the init container "init-directories" fails on startup when running Gitea with a uid different from 0 or 1000.
Initially, I worked around it by implementing an "initPreScript". But it would make user's life easier if we can make it work out-of-the-box.
## Resolution
I'm taking model on the chown a few lines above that depends on the value of image.rootless. Since the chown only works on default (root) image and is useless on rootless image, there is no need to run it on rootless image.
Co-authored-by: Nicolas MASSE <[email protected]>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/266
Reviewed-by: luhahn <[email protected]>
Reviewed-by: justusbunsi <[email protected]>
Co-authored-by: nmasse-itix <[email protected]>
Co-committed-by: nmasse-itix <[email protected]>
With release 5.0.0 there are so many deprecations and breaking changes
that it is probably a good way to assist the users with values migration
before breaking their environments.
This adds another template file that doesn't render anything but ensures
the removal of dropped or deprecated settings from customized values
files.
For when it is necessary, this check can be disabled via new setting
`checkDeprecation`.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/269
Reviewed-by: luhahn <[email protected]>
Reviewed-by: wxiaoguang <[email protected]>
Co-authored-by: justusbunsi <[email protected]>
Co-committed-by: justusbunsi <[email protected]>
⚠️ Breaking
Moved the values to enable the dependencies into the dependencies itself, this way we don't need a seperate field in the values and it is more obvious how to enable for example postgresql.
Co-authored-by: Lucas Hahn <[email protected]>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/268
Reviewed-by: justusbunsi <[email protected]>
Reviewed-by: Andrew Thornton <[email protected]>
With the result of PR #239 it is much easier to provide additional values to the _app.ini_ configuration from different sources.
These changes adds an _additionalConfigSources_ field where the users can define such sources. This enables the users to choose
on their own whether to store values in _values.yaml_ or load them from Kuberetes Secrets or ConfigMaps.
- Fixes#243
- Fixes#174
- Fixes#260
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/240
Reviewed-by: luhahn <[email protected]>
Reviewed-by: wxiaoguang <[email protected]>
Co-authored-by: justusbunsi <[email protected]>
Co-committed-by: justusbunsi <[email protected]>
This change request includes two different things to improve OAuth source handling:
- Allow multiple OAuth source configuration (Fixes: #191)
- Support reading sensitive OAuth configuration data from Kubernetes secrets (Closes: #242)
⚠️ BREAKING ⚠️
---
Users need to migrate their `gitea.oauth` configuration.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/244
Reviewed-by: luhahn <[email protected]>
Reviewed-by: Andrew Thornton <[email protected]>
Co-authored-by: justusbunsi <[email protected]>
Co-committed-by: justusbunsi <[email protected]>
fixes#251
The rendering is a bit more programatic but the result is the same if you don't have an override. This makes the code a little easier at the end of the template, and slightly less easier to read at the beginning, which I think is a valid tradeoff.
Co-authored-by: Martyn Ranyard <[email protected]>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/252
Reviewed-by: justusbunsi <[email protected]>
Reviewed-by: luhahn <[email protected]>
Co-authored-by: iMartyn <[email protected]>
Co-committed-by: iMartyn <[email protected]>
Hello !
I'm using the new Helm chart (5.x) and I really like the new configuration mechanism. 👍
I would like to contribute the following enhancement.
## The problem I want to solve
I'm trying to deploy Gitea in a Kubernetes shared platform and I need to make sure each instance is running as a different user so that in case of container escape, the risk of data leak is minimized.
Additionally, on my platform (OpenShift), arbitrary users (such as uid 1000 for Gitea) are not allowed.
The current helm chart does not allow me to achieve this because:
- the container security context is configurable only for the main container. The security context of init containers cannot be specified.
- a fixed uid is hard coded
- a fixed fs group is hard coded
Also, the securityContext of a pod and the securityContext of a container do not accept the same options.
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core
## How I'm solving the problem
I split the `securityContext` (values.yaml) in two: `containerSecurityContext` and `podSecurityContext`. The containerSecurityContext applies to all containers (init and main) in order to be consistent with file permissions.
The behavior for existing deployments is unchanged:
- fsGroup 1000 is the default value for the podSecurityContext variable
- the "configure-gitea" init container uses the uid 1000 unless otherwise stated in the containerSecurityContext
- the main container is using the existing securityContext variable when defined in order not to break existing deployments and uses the new containerSecurityContext variable if not.
This approach is well tested: it is used consistently on bitnami's Helm charts.
## How I tested
I tested both root and rootless variants on a Kubernetes 1.22, as well as rootless variant on OpenShift 4.7.
**rootless variant on Kubernetes**:
```yaml
podSecurityContext:
fsGroup: 10001
containerSecurityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
add:
- SYS_CHROOT
privileged: false
runAsGroup: 10001
runAsNonRoot: true
runAsUser: 10001
extraVolumes:
- name: var-lib-gitea
emptyDir: {}
extraVolumeMounts:
- name: var-lib-gitea
readOnly: false
mountPath: "/var/lib/gitea"
```
**rootless variant on OpenShift**:
```yaml
podSecurityContext:
fsGroup: null
containerSecurityContext:
allowPrivilegeEscalation: false
privileged: false
runAsNonRoot: true
runAsUser: 1000790000
extraVolumes:
- name: var-lib-gitea
emptyDir: {}
extraVolumeMounts:
- name: var-lib-gitea
readOnly: false
mountPath: "/var/lib/gitea"
```
Let me know if something is unclear.
Co-authored-by: Nicolas MASSE <[email protected]>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/259
Reviewed-by: luhahn <[email protected]>
Reviewed-by: justusbunsi <[email protected]>
Co-authored-by: nmasse-itix <[email protected]>
Co-committed-by: nmasse-itix <[email protected]>
Hi,
I just add some minor changes to support specifying ingressClassName to support the newer specification in `networking.k8s.io/v1`. The annotation `kubernetes.io/ingress.class: nginx` only works with older API `networking.k8s.io/v1beta1`.
This is part of our move to support kubernetes 1.22.
Co-authored-by: Leong Wai Kit <[email protected]>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/217
Reviewed-by: luhahn <[email protected]>
Reviewed-by: techknowlogick <[email protected]>
Co-authored-by: wkit23 <[email protected]>
Co-committed-by: wkit23 <[email protected]>
justusbunsi
dek
cnfatal
takirala
techknowlogick
svenihoneyandSven Fischer
luhahnandLucas Hahn
a-zenandalex
nmasse-itixandNicolas MASSE
aleksey.sergeyandAleksey Sergey
iMartynandMartyn Ranyard
Markus PeschandMarkus Pesch
pat-sandpat-s
wkit23andLeong Wai Kit
Michael KrieseandLunny Xiao
skrieschandtechknowlogick