### Release Post candidate Auto DevOps want to bring outstanding ease-of-use and security best practices out of the box to its users. Until now Auto DevOps in Kubernetes environments required Helm v2 to be installed on the cluster, and this involved a security risk given Tiller's root access rights. With the introduction of Helm v3, Tiller is no longer a requirement. The current GitLab version finally supports Helm v3. You can upgrade your Helm installation in the case of a GitLab Managed Cluster following our documentation. Note that Helm 2 support is expected to end around November 2020. ### Problem to solve Auto DevOps currently makes use of Helm 2. [Helm 2 support](https://helm.sh/blog/2019-10-22-helm-2150-released/) will end in 12 months (around Nov 13, 2020) Also, Tiller will be removed as part of [Helm V3.0.0](https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1) to provide a way to simply fetch information from the Kubernetes API server, render the Charts client-side, and store a record of the installation in Kubernetes. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal Migrate Auto DevOps to use Helm 3 1. Migrate to Tillerless :white_check_mark: 1. ~~Update Chart.yaml to be Helm 3 compatible (apiVersion: v2) - see https://gitlab.com/gitlab-org/charts/auto-deploy-app/issues/44~~: Edit: this would be a breaking change for Helm 2 users, so we need to keep it as-is for now. 1. Remove local tiller and use Helm 3 binary 1. Migrate and cleanup Helm v2 configuration and releases to Helm v3 in-place. * Helm 3 requires conversion to a new format https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/ 1. Cleanup Tiller deployment ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references ## Out of scope * https://gitlab.com/gitlab-org/gitlab/-/issues/120021