Our Kubernetes API server is only reachable from the internal network, which complicates things. Also, setting up Kubernetes RBAC to allow Travis CI to do a kubectl set-image isn’t trivial either.

The best alternative would be to have Travis CI SSH into a box with kubectl. In any case it’s bit more complicated than the setup with Keel we currently have.

> Also, setting up Kubernetes RBAC to allow Travis CI to do a kubectl set-image isn’t trivial either.

Wouldn't setting up Keel on a Kubernetes cluster be the same effort (permissions, RBAC etc.)?

Keel has permissions to update all deployments in our cluster. Because it runs within the cluster instead of outside (like Travis CI), and the only interaction with Keel is through webhooks, there is no need for finegrained RBAC.

The webhooks only tell Keel that a new image is available, they cannot modify other parts of the Kubernetes deployment directly.

On that note, Gitkube supports RBAC as the Remote objects are namespaced. This means two things:

1) Remotes are isolated - have different authorizations for say dev and staging remotes

2) Deployments are isolated - A Remote can only deploy apps in its own namespace.

We are doing the exact same thing with Drone CI, however RBAC on the cluster is needed.

RBAC isn't too complicated though:

- get on specific app namespaces

- get, list, watch, patch, update on deployments