This message was deleted.

Or alternatively a way to completely disable "local" auth when I have SSO enabled?

Hi Michal, I don't think you can disable local login completely. Regarding deleting admin user, I will need to test, maybe you can do it via API call, never ran into this request before. I will be able to test this in Mon

I was reading through the code and it looked like the API endpoint for deleting users does not allow deletion of the default admin, but would be happy to be wrong! We were encountering an odd situation where pods restarted during startup (our own fault) but it resulted in the default admin getting created when we didn't expect it. I think essentially it started up enough to no longer be a new cluster when it restarted, but didn't make it to the point where the admin got deleted. Would be happy to open an issue for this but it'd be great to be able to guarantee deletion of that user, even if it's not an install.

IMO, being able to at least rename the

admin

user would be nice. 🤔

So from the security and compliance perspectives, it is a good idea to have a local admin user as a fall back user in case of any issues with SSO, including network access to SSO, or a simple SSO malfunction. Think of a situation when you need to troubleshoot a production app, and it is running in Protect mode, and all of sudden you get an issue where you cannot login with your SSO. In this case you are not compromising on accessing through SSO vs local, your customer facing app is malfunctioning, you need to get it up and running, and you cannot execute your troubleshooting, bcz NV blocks you from using any unknown commands. You need a way to access it quick, and that is where local admin user will be extremely useful. Although you have local admin user enabled - you can steps to enhance its security by creating a complex password profile, setting up expiration/failed login attempts/etc. More importantly - you can track logins as admin through your logs.

Yeah I think that's totally fair. I think we found a different workaround for the time being, using our service mesh to block the local auth paths. That way it's also something we can remove in the worst case if we encounter any issues with our SSO and need to troubleshoot with NeuVector.