<p>When running (on GCP):</p>

<pre class="lang-sh prettyprint-override"><code>$ helm upgrade \
  --values ./values.yaml \
  --install \
  --namespace "weaviate" \
  "weaviate" \
  weaviate.tgz
</code></pre>

<p>It returns;</p>

<pre class="lang-sh prettyprint-override"><code>UPGRADE FAILED
Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "ku
be-system"
Error: UPGRADE FAILED: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in t
he namespace "kube-system"
</code></pre>

<h2>UPDATE: based on solution</h2>

<pre class="lang-sh prettyprint-override"><code>$ vim rbac-config.yaml
</code></pre>

<p>Add to the file:</p>

<pre><code>apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system
</code></pre>

<p>Run:</p>

<pre class="lang-sh prettyprint-override"><code>$ kubectl create -f rbac-config.yaml
$ helm init --service-account tiller --upgrade
</code></pre>

<p><em>Note: based on Helm v2.</em></p>

Bob van Luijt
<p><em>tl;dr: Setup Helm with the appropriate authorization settings for your cluster, see <a href="https://v2.helm.sh/docs/using_helm/#role-based-access-control" rel="nofollow noreferrer">https://v2.helm.sh/docs/using_helm/#role-based-access-control</a></em></p>

<h2>Long Answer</h2>

<p>Your experience is not specific to the Weaviate Helm chart, rather it looks like Helm is not setup according to the cluster authorization settings. Other Helm commands should fail with the same or a similar error.</p>

<p>The following error </p>

<pre><code>Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "ku
be-system"
</code></pre>

<p>means that the default service account in the <code>kube-system</code> namespace is lacking permissions. I assume you have installed Helm/Tiller in the <code>kube-system</code> namespace as this is the default if no other arguments are specified on <code>helm init</code>. Since you haven't created a specific Service Account for Tiller to use it defaults to the <code>default</code> service account.</p>

<p>Since you are mentioning that you are running on GCP, I assume this means you are using GKE. GKE by default has <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">RBAC Authorization</a> enabled. In an RBAC setting no one has any rights by default, all rights need to be explicitly granted.</p>

<p>The helm docs list several options on how to make <a href="https://v2.helm.sh/docs/using_helm/#role-based-access-control" rel="nofollow noreferrer">Helm/Tiller work in an RBAC-enabled setting</a>. If the cluster has the sole purpose of running Weaviate you can choose the simplest option: <a href="https://v2.helm.sh/docs/using_helm/#example-service-account-with-cluster-admin-role" rel="nofollow noreferrer">Service Account with cluster-admin role</a>. The process described there essentially creates a dedicated service account for Tiller, and adds the required <code>ClusterRoleBinding</code> to the existing <code>cluster-admin</code> <code>ClusterRole</code>. Note that this effectively makes Helm/Tiller an admin of the entire cluster.</p>

<p>If you are running a multi-tenant cluster and/or want to limit Tillers permissions to a specific namespace, you need to choose one of the alternatives.</p>
