Authentication through kubernetes config

[argoproj-labs]

Authentication through kubernetes config

[rodrigobaron]

I've added an example of authentication in PR #5 using kubenetes configuration file.

[Trollgeir]

Our use case is mainly to be able to create code that runs fine both locally and in the cloud.

At our company we use argo quite extensively, but we've yet to adopt any SDKs as they've either been discontinued or make things more convoluted than just working with yml-files.

We adopted a subset of code from couler (the one I linked) and just use it to parse yml-files and submit workflows. This is quite handy because the code works both locally and in the cloud (in-cluster config), without any additional configuration.

In essence, this makes it trivial for workflows/services to start new workflows within their own namespace.

[Trollgeir]

It might! I might suggest adding a try/except in the example for the in-cluster config as well @rodrigobaron - although I see that the PR has been merged now. 👍

One of my main concerns have been answered, but I sadly do not currently have time to test hera extensively yet. Feel free to close the issue :)

[flaviuvadan]

In couler it's possible to authenticate based on kubernetes or cloud config.

Could this be a possible feature for hera as well if we do not supply a token?

Thank you for submitting the issue, @Trollgeir! I'd love to know more about your use case if you can share.

It should be possible to run Hera with the host set to localhost:2746 after running kubectl port-forward service/argo-server 2746:2746 (or deployment) to submit workflows. I see that Couler uses the Workflow CRD to create one directly in a namespace. Hera aims to interact with the Argo server to delegate this type of work, rather than create K8S objects by itself. It is possible to make Hera do this work but for now it's not the aim - the aim is to interact with the Argo server for now. Again, would love to know more about your use case to make sure we're discussing building the right thing!

[flaviuvadan]

Our use case is mainly to be able to create code that runs fine both locally and in the cloud.

At our company we use argo quite extensively, but we've yet to adopt any SDKs as they've either been discontinued or make things more convoluted than just working with yml-files.

We felt the same way at @dynotx, which is why we released Hera. I'd be excited to know if Hera covers some of the pain points your company noticed with usage of existing SDKs.

We adopted a subset of code from couler (the one I linked) and just use it to parse yml-files and submit workflows. This is quite handy because the code works both locally and in the cloud (in-cluster config), without any additional configuration.

In essence, this makes it trivial for workflows/services to start new workflows within their own namespace.

Ah, I see! Does @rodrigobaron's PR help with this, perhaps? Wondering if that submission type will help you get going on using Hera vs. waiting until this specific auth method is implemented and released 🙂