beacon-biosignals / julia_pod

k8s native julia development
MIT License
10 stars 3 forks source link

Remove use of K8s secret to store GitHub PAT #60

Closed omus closed 1 year ago

omus commented 1 year ago

The julia_pod feature to allow easy interactive adding of private packages uses a K8s secret to store the user's GitHub PAT. The K8s secret could be read by anyone with access to the namespace which has the potential to leak the GitHub PAT to malicious actors. This PR removes this feature but preserves the ability to use private Julia packages during the image build.

Supersedes: #56

kleinschmidt commented 1 year ago

And here I was naively thinking that using kubernetes secrets would help. Out of curiosity, how was that vulnerable?

They can be read by anyone with access to the kubernetes namespace, which in general includes more people than the person who created the PAT

kolia commented 1 year ago

Hmm ok, kubernetes docs say there is no finer control on who can see secrets, they are all open to anyone with access to the namespace.

We could consider using PATs from a special bot-like github account that only has minimal github access privileges, but supporting the addition of private packages at runtime is non-essential / just a nice-to-have, so unless there are other benefits to do that, dropping support seems like the way to go. Kubernetes docs also list some alternatives to secrets, which all look like a pain to set up.

kolia commented 1 year ago

Using github's fine-grained PATs may also fix this, someone with namespace access would be impersonating whoever owns the PAT, but their permissions could be made minimal enough that they can't do damage. Not sure how you'd enforce that people are using fine-grained PATs with the right minimal permissions though.

Anyway, I'll stop looking at alternatives, being lazy and just dropping support is 👍 .

omus commented 1 year ago

Using github's fine-grained PATs may also fix this, someone with namespace access would be impersonating whoever owns the PAT, but their permissions could be made minimal enough that they can't do damage. Not sure how you'd enforce that people are using fine-grained PATs with the right minimal permissions though.

At best we would have to make this feature opt-in and add lots of documentation making the potential downsides clear. At this point it's best to fix the vulnerability and we can add such functionality in later.