Deploy Coder Mounting Scratch Area

[callumforrester]

Test deploying coder on a beamline kubernetes cluster, mounting its blueapi scratch area and editing plans. Currently unsure if we can use coder's provided helm chart or if we will have to roll our own.

Acceptance Criteria

• Coder is deployed on the beamline
• Optional: It is accessible via a DNS name
• Can you edit plans with it
• After reloading blueapi the edits become available
• The ease of setting it up and UX quality is documented

[stan-dot]

I recall doing some testing and then asking @DiamondJoseph to take a look - there was something about the chart at odds with how we use k8s

[DiamondJoseph]

It was something in the service account/ingress/rbac configuration sphere. But their Helm chart defers to a subchart (which is packaged with the chart...) that does all of the actual logic which makes it a nuisance to try and look in artifacthub. https://artifacthub.io/packages/helm/coder-v2/coder

[stan-dot]

potentially relevant https://diamondlightsource.slack.com/archives/C03P6QB9589/p1662645670430099?thread_ts=1657290153.448169&cid=C03P6QB9589

[DiamondJoseph]

I'm not sure, but I don't think so from reading the thread- seems to be about configuring OIDC for services within kubernetes that are being forwarded to from configured IP addresses that are externally facing. Our external web -> k8s services infrastructure has moved a lot in the last couple of years.

It was one of the standard kubernetes resource definitions that wasn't configurable. I can try and run it up some time next week when I have time and see what Kyverno complains about?

[callumforrester]

We may also have to roll our own chart anyway to make sure all the plugins etc. we want go in

[stan-dot]

note: for the editor we might want to scan the uploaded code for vulnerabilities https://codeql.github.com/

[callumforrester]

I have been experimenting with this, it's not hard to throw up an instance of the coder code server on Kubernetes and include out choice of plugins, issues encountered so far:

• We can only install open source plugins (similar to vscodium)
• Apparently there is a way to do OIDC integration but I haven't figured it out yet
• The docs recommend a plugin for multi-user collaboration on the same working tree, but it has since gone closed source so we can't install it
• The code server is meant to be one instance per user, if we deployed the full coder suite it could spin up instances as-and-when, but it requires terraform and various other infrastructure that we don't have. The alternative is to roll our own small process that spins up instances...
• Because of the above, the identity of the user who edits a file may be lost (this is the main blocker currently because of security concerns).

[stan-dot]

why is 'only open source plugins' as an issue not a limitation? are there specific plugins that we miss?

wouldn't the authentication middleware just secure the entire URL? then we would not need to integrated OIDC inside the server

[stan-dot]

@gilesknap suggested using self deployed nano.

One other option would be https://onedev.io/ , which boasts ldap support. not sure about the plugins.

here is a k8s deployment guide https://docs.onedev.io/installation-guide/deploy-into-k8s

[stan-dot]

what it does do is helm install onedev onedev/onedev -n onedev --create-namespace its own namespace

which is problematic from the rbac perspective, @DiamondJoseph