Ideas on where to store client id and secret when Application is created on server startup

[makeevolution]

I am using django-oauth-toolkit for authorization of my Django app, and for development, each dev deploys their server on Kubernetes with a MySQL database also deployed on the side as a StatefulSet. Many times me (or other devs who develop the application) have to remove their database and reinstall their k8s deployment. Usually (in a non k8s deployment and what is there in the quickstart guide), you would deploy your app, register the new client application through the UI provided by the django-oauth-toolkit, and then you get a one time generated client secret that you have to copy immediately otherwise it will be gone and you have to recreate the client. But this is inconvenient as on every new fresh install we have to keep doing this, and update the client_secret in the apps that use the authorization server with the new value.

So I found a way to auto-register an OAuth2 client application as follows on post-migrate (this is a snippet, something like this)

from oauth2_provider.models import Application
@receiver(post_migrate)
def initialize_client_applications():
    Application.objects.create(
    client_type=Application.CLIENT_CONFIDENTIAL,
    authorization_grant_type=Application.GRANT_CLIENT_CREDENTIALS,
    name="some_client_name",
    client_id='myComplexClientIdString",
    client_secret='myComplexClientSecretString",
    user=User.objects.get(name="someuser")
    )

But, as you can see, the client_secret is hard coded and therefore quite insecure. How can I do this using code on startup, but having the client_secret saved somewhere in a more secure way?

I have seen this answer https://stackoverflow.com/a/70189221/15072862 and I thought I could just make a random string for this client_secret (e.g. using make_password() function of Django), and the devs can ssh to the server and access this value through python manage.py shell (still inconvenient but at least we can make a shell script to do this), but the database is actually hashing whatever I put in, so accessing that variable doesn't help.