Devspace defaults to uploading credentials to cluster

[LISTERINE]

What happened?
Running devspace build will, by default and without prompting, upload users credentials to the remote cluster.

What did you expect to happen instead?
At a minimum, a prompt requesting permission to propagate user secrets to remote servers.

How can we reproduce the bug? (as minimally and precisely as possible)

devspace build
info Using namespace 'xxxxxxx'
info Using kube context 'xxxxxxx'
Ensuring image pull secret for registry: xxxxxxx
Created image pull secret xxxxxxx

My devspace.yaml:

version: ...
...

Local Environment:

• DevSpace Version: 6.3.2
• Operating System: mac
• ARCH of the OS: AMD64
  Kubernetes Cluster:
• Cloud Provider: google
• Kubernetes Version: v1.25.11-gke.1700

Anything else we need to know?

Any organization that uses SSO likely uses local login credentials for services like artifactory, etc... The result being that unless the team using devspace reads about this default behavior, their corporate credentials are now sitting unencrypted in a shared environment without their knowledge.
I can see from the documentation here https://www.devspace.sh/docs/5.x/configuration/pullSecrets/basics that this was a conscious decision. I understand that this was probably to make use of the tool smoother, but IMO is definitely not being handled correctly.
This absolutely should not be the default behavior, and if it is, the user should be prompted before devspace copies credentials to a remote server. Adding a note to the prompt that tells the user how to make the prompt go away for next time (maybe some kind of config) would allow them to quickly transition to that smooth workflow without making security assumptions on their behalf.

[lizardruss]

@LISTERINE Hello! I've submitted a PR so that DevSpace will only create the pull secrets for in cluster builds. Let us know if this satisfies the issue!

[LISTERINE]

I'm not equipped to test it or familiar with the codebase, but at face value the logic seems sound to me. Thanks for addressing this!