Helm chart needs to support oidc by default

ℹ️ Support
,
1

You folks are really dropping the ball by not having oidc configuration in the helm chart by default. This needs to be pointed out and gain attention.

Please take note and do your best not to instruct me to submit a pull request, or tell me my use case is rare. Think about what I’m saying, do you want people to easily be able to adopt your application and use it or do you want them to go somewhere else?

I’ve been watching this project for a few years and have installed it several times. Each time I have to jump through a ton of hoops to achieve a clean ‘gitops’ deployment.

Implementing a gitops strategy via kubernetes is becoming the norm. Everything that can be deployed via a container can be implemented in a gitops fashion. The idea is to put the configuration of an application (infrastructure as code) into a git repo, and then ‘continuously deliver’ that application using gitops via an application such as argocd, flux, or carvel… whenever a change is made to git, the change gets reflected in the live deployment, history can be tracked via changes in the git repo.

When secrets are involved those are stored in a vault somewhere and pulled at runtime, this helps to avoid saving anything into git which is secret. Configuring oidc as part of the helm chart values file means that when the application is first deployed everyone with an account can immediately login and use the application.

Gitops breaks down when there are steps you have to perform after installation, where you log in as an administrator and install things & configure things. That’s not infrastructure as code, unless you want to include “after the fact configuration” via ansible, terraform, or similar.

Every app I have deployed in my home lab follows gitops, except nextcloud, I was able to make it work in the past by basically hacking into things and creating an enormous script to run after installation, but this is the wrong approach. Nextcloud is the outlier, preferring its own vm with docker, and its own little world to run in. Nextcloud demands a “pet” installation, and can’t live in a world of “pets vs cattle”.

Until this is implemented, many will look for the oidc configuration, put a little effort into seeing if they can hack together a solution, and then they will abandon your project and look elsewhere. I want to use nextcloud right now, I’m ready to install it again. I can look up my old hacked together solution on this forum and implement it again but it’s just so ugly. It’s been years.

I’m not asking you to switch to a database such as cockroachdb, or similar, so the app can scale, I’m not asking nextcloud to be able to work with multiple replicas of nextcloud in order to scale, I’m only asking for OIDC. Let’s make it so nextcloud can be configured via the helm chart, rather than just installed, and then require a manual configuration after the fact. Let plugins be specified in the helm chart, etc… or, for now, let’s just get oidc in there.

No reply is necessary.

Respectfully,

  • lknite.
2

hi @lknite welcome to the forum :handshake:

I appreciate your proposal and I support OIDC integration idea but there is no one size fits all approach especially with NC. it supports many different installation methods from bare-metal to containers and I bet OIDC is not widely used (in a private/SOHO world of this forum).

I would really appreciate user_oidc would become a core app. but don’t forget there are other options like sociallogin or oidc_login-app… and even if you would choose one of them to become a default the admin still has to provide the config like IdP address, config, secrets… I hardly see an easy config only OIDC integration… I don’t see any problem to script installing specific apps and providing a config…

your approach is going the way “Nextcloud is just another app in my universe” but this forum is other way round “Nextcloud is the middle of the world and your universe has to adopt/adjust to Nextcloud”.

If your demand is strong and you are willing to provide a pull request on GH it could improve OIDC support or not… but complaining here without any own contribution expecting others to to the job result in nothing - zero result at the end

1 Like
3

I’m not sure who you’re directing this to.

I can only assume you’re referring to the community built Helm chart for the community micro-services image (there are other images and charts): GitHub - nextcloud/helm: A community maintained helm chart for deploying Nextcloud on Kubernetes.

Let’s make it so nextcloud can be configured via the helm chart, rather than just installed, and then require a manual configuration after the fact.

You’re right that there is no generic abstraction just for one of the various OIDC apps. However…

You can already push any configuration directive desired, run any occ command (and therefore easily install any app), and certainly pull in secrets… without any manual intervention (and readily maintained via git).

And you can use whatever OIDC app you prefer.

Have you looked at the later replies to your original Issue?

or, for now, let’s just get oidc in there

Which OIDC app? There are multiple OIDC apps.

The main thing missing probably is additional documentation to make it clear what’s possible. It’s a community project, so just depends on who jumps in.

4

I believe if I implemented everything needed in a pull request it would simply be rejected, and be a complete waste of my time. There needs to be some agreement when it comes to security that nextcloud has decided on a solution, such as oidc, which allows an application to integrate with an IAM solution which can use any provider behind the scene such as ldap, gmail, etc. Right now there are only two real choices SAML and OIDC, and between those OIDC Is currently the most popular. Not choosing OIDC and telling me that I’m just complaining, when you aren’t up to speed on OIDC isn’t helping. Don’t attack me, everything I said in my post is correct. I only posted because I’m informed on this topic, and because I care. - I literally said not to tell me to submit a pull request or tell me my use case is rare. Maybe you are just trolling. My use case is not rare. OIDC usage is not rare, it is literally the most popular IAM related protocol. I understand you are saying most home users wouldn’t be using OIDC, but I would argue, those using a helm chart are… and everyone should be. Home users aren’t using Windows Domain Controllers as much as they used to. What do you think they are using?

5

Who do you mean by “you folks”? The community? The company? I can only say that the Nextcloud community is not a homogeneous group, but an extremely diverse one, and the Helm Chart is just one of many community projects and not an official product of Nextcloud GmbH.

But you could at least post a feature request to the appropriate repo, couldn’t you? Otherwise, you’re just throwing around buzzwords like managers at business meetings, but while managers usually at least provide budgets to get things done, you don’t seem to want to provide anything other than big speeches.

Any hard numbers and statistics to back this up? I’d say 90% of home users, small clubs, schools, SMBs etc using Nextcloud don’t actually follow a GitOps / Kubernetes strategy.

Yeah, that would certainly be cool for those who want to use it. But you shouldn’t say ‘let’s do it’ when you actually mean ‘others should do it’.

I know what I’m using. I use a manual installation in an Ubunu VM, no SSO, no external Identirty provider and user management.

1 Like
6

Maybe provide some documentation on how to use the helm chart options to configure user_oidc and I could follow your documentation to make some changes to the helm chart & add it in as a default option.

Yes, I saw the replies to my 2 year old post and how everyone else was having to hack together similar solutions to try and what should be basic security working. There’s really only a couple options, a local database of users if you want to do credentials on your own, and OIDC. Can keep ldap support around if you want to be generous. Most modern applications provide a local admin user (& optionally other local users) by default and OIDC, anything beyond that would be additional configuration outside the norm (not part of the helm chart).

Its directed at the people who approve the pull requests. Those who could say “we support local accounts and OIDC by default (since oidc lets you use any IAM), and some additional methods through 3rd party plugins”. This direction has been lacking.

7

Well, then I don’t understand why you don’t try to revive the discussion in the discussion tab of the relevant repo, possibly with a new topic.

Before you do that, though, you might want to adjust your attitude a bit, and not try to tell everyone that K8s and OIDC is the only true way everyone should do things, and that other use cases should be second class citizens because no one should use them anymore.

In general, don’t just make demands, make concrete suggestions about what to change, how to implement it, and if no one in the project supports your suggestions, maybe there are good reasons for it that you didn’t think of, or maybe they just don’t want to do it, which would be perfectly legitimate as well.

If the latter is the case, you can always fork it and start your own project. It’s all open source and the possibilities are endless, except in this context they might be somewhat limited by the relevant plugins/apps and Nextcloud itself, but that could be changed as well. However, as always, someone has to do the work and in this specific case it’s mainly done by volunteers.

In short, if it is really important to you that the things you want are implemented, then you should be more proactive in contributing, rather than wasting time throwing around buzzwords and complaints in the forums :wink:

1 Like
8

Then this isn’t a community Helm matter. There is no shipped (installed by default) OIDC app in Nextcloud Server. So there is not in the underlying image either, let alone the Helm chart.

There are, however, at least three commonly used OIDC add-on apps (one of which is hosted in the project and two of which are third-party ones). This is why today the installation and configuration of these is handled just like any other non-default app: everyone has their own preference for various reasons.

A discussion could certainly be had about including user_oidc or one of the others by default in Nextcloud Server, but that’s not the case today.

Until that happens there can’t be additional support added in the underlying community micro-services Docker base image (nor the Helm chart that is layered on top of it).

You should probably start at either: