Which remote access methods are supported in Gravity community edition?

Using the community edition of Gravity (6.x + ), how can I setup a remote set of users who access the cluster via Kubectl? I’d like users tied to serviceaccounts and using tokens or certs but i’m open to alternative ways. I haven’t been successful in this yet.

[EDIT] I’ve now been successful adding a @teleadmin user along with teleport (tsh) on a remote port to create an admin user. There is also another role called “admin” which is allowed by gravity community edition but it’s not clear the different between “admin” and “@teleadmin”.

I’m interested in using non-teleport methods of access, namely tying serviceaccounts to remote users. Is this supported?


Hey @mmellin,

admin role is the default teleport role which is created due to gravity embedding teleport. As you’ve done, you should use @teleadmin role in gravity as that has privileged permissions for gravity clusters.

Is there anyway around Gravity to leverage standard RBAC practices whereby a remote API caller is tied to permissions based on a service account? How does one access the API server remotely without Teleport?

1 Like

Hi Matt!

Apologies about delayed response.

Like Abdu mentioned, you should be using the @teleadmin role for your Gravity super-admin users. The admin role is a built-in Teleport role and is an artifact of the fact that Teleport is built into Gravity. We should probably get rid of it in the context of Gravity eventually.

In order to be able to use kubectl with a Gravity cluster, you can tsh login into it using authentication gateway address (shown in gravity status output) as a --proxy flag. When you login, tsh configures your local kubeconfig with proper credentials for the Kubernetes API server proxy. Then, if your Gravity role definition specifies kubernetes_groups, it will be encoded into certificate obtained by tsh and kubectl will assume the group’s membership when talking to the API server. On the cluster side you’ll need ServiceAccount/Role/Binding to be configured appropriately to assign permissions based on the group membership.

Let me know if you have any questions.


Thanks @r0mant and @abdu