implement helm --as | helm --as-group

[hickeyma]

Feature:
Ability to install a chart for a different persona to the user calling the Helm CLI or Helm library.

Use Case:
A user logs into a portal that provides the ability to install charts. The user is assigned to a team, which grants the user access to specific resources on the system: namespaces, repositories, and charts within the repository. The user is also assigned a role on the specific team which controls what actions the user may perform, such as a viewer or an editor.

On the UI, there is a catalog of charts to which the user has been given access. The user selects one of the charts, updates the configuration values, and clicks install. The request is sent to a backend processor for installing the chart. The backend retrieves the user identify from an access token the user was assigned when logging into the portal, and the backend maps the teams to which the user is assigned to a set of groups for the user.

The backend service has been given the right to perform user impersonation, and includes the user identity and groups in impersonation headers that are sent to Kubernetes. Kubernetes validates the backend service and since it is able to impersonate users, accepts the user identity and user groups passed in the impersonation headers.

The key is the user does not use the helm library directly but is used instead by the backend service on behalf of the user.

[hickeyma]

@adamreese As we discussed.

[adamreese]

We can create kubernetes api objects as a user, but I am not sure how a chart would map to a specific user. Can you add your use case. Thanks!

[hickeyma]

@adamreese I added a use case to the description. Let me know if you need more details.

[bacongobbler]

If I'm understanding this correctly, you're asking to support the --as and --as-group flags similar to kubectl. Those flags are how kubectl interacts with the user impersonation API. Is this right, or is there something else here?

A solid use case example would be helpful here.

[hickeyma]

@bacongobbler More details provided in description as requested. Let me know if anymore details needed.

[sbose78]

I'm looking for something similar as well. Here's what my use case looks like:

1. UI talks to a backend service with user context ( token in header ).
2. The backend service uses the helm cli with user impersonation to talk to the API server do a "helm install".

[bacongobbler]

closing as inactive.

[sdickhoven]

user impersonation is basically "sudo" for kubernetes. no need for everybody to always run around with full admin permissions if they just view things most of the time.

in our clusters nobody has permission to change anything by default. you must always impersonate an admin user in order to make changes... just like sudo.

so if i need to install a helm chart, i must have some way of impersonating the correct admin user.

here's how i use kubectl:

$ kubectl --as cluster-admin <create/delete/modify cluster resources>
$ kubectl --as my-namespace-admin <create/delete/modify my-namespace resources>

it forces people to think about what they're about to do and allows them to limit the scope of what can possibly get destroyed if they make a mistake.

would it not be straight-forward to add an --as option to helm?

[sdickhoven]

here's the kubes rbac that goes along with this:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: view
  namespace: app-team1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: app-team1@mycompany.com
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin
  namespace: app-team1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: app-team1-admin
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: app-team1-admin-impersonate
rules:
- apiGroups: [""]
  resources: ["users"]
  verbs: ["impersonate"]
  resourceNames: ["app-team1-admin"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: app-team1-admin-impersonate
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: app-team1-admin-impersonate
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: app-team1@mycompany.com

[crookedstorm]

This was exactly what I was looking for (an --as and --as-group option in helm3 to work with our RBAC policies). I'm sad to see the only two issues related closed.

[bacongobbler]

issues can be reopened if there's activity. Just saying. ;)

Re-opening due to resurging interest. @crookedstorm please feel free to work on a patch to implement this if you need this for your RBAC policies. Have a look at #7230 for ideas.

[bacongobbler]

FYI this can be worked around by setting the proper fields in your ~/.kube/config file. We just don't have a CLI flag available to pass this flag to kubectl's clients on-the-fly.

[stealthybox]

Here is an example of how to create a proper impersonated user in your ~/.kube/config:

users:
- name: myuser-as-admin
  user:
    # Normal credentials here, could be client certs, exec, whatever
    username: myuser
    password: password123

    # Impersonation information below
    as: admin
    as-groups:
      - system:masters
    as-user-extra:
      reason:
        - helm

( derived from istio/istio#22365 (comment) )

List of user facing groups:
https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles

[stealthybox]

@bacongobbler I'm looking at supporting this properly in helm for use with fluxcd/helm-controller's multi-tenancy model for gitops-toolkit.

[stealthybox]

Didn't end up needing any special code in helm-controller, because we can control the client restmapper settings via code, but I was able to get this working with the helm cli.