Во-первых, прокси-сервер Cloud SQL и фабрика сокетов Cloud SQL JDB C - это две разные реализации одного и того же. Socket Factory используется изнутри вашего приложения, а прокси - это внешний процесс. Нет причин использовать и то, и другое одновременно.
Во-вторых, способ защиты вашего приложения во многом зависит от того, как вы планируете распространять и запускать его. Если это веб-приложение, вы, вероятно, создадите «учетную запись службы», которая представляет привилегии, которые вы хотите, чтобы ваше приложение было, а затем ограничиваете доступ к внешнему интерфейсу приложения, используя все, что работает (брандмауэр, oauth и т. Д. c ).
Если ваше приложение является чем-то локально распространяемым на платформе пользователя, то это немного сложнее и гораздо труднее защитить. Проблема в том, что любой, у кого есть доступ к вашему приложению, потенциально может получить доступ к вашей базе данных или другим ресурсам. Поскольку вы не можете использовать gcloud, вы можете либо повторно реализовать свой собственный уровень аутентификации (например, gcloud auth application-default login), который имеет логин пользователя и сгенерировал временный файл учетных данных, который можно использовать для подключения.
В качестве альтернативы вы включаете учетные данные в само приложение. Вы можете встроить их напрямую, но если они будут скомпрометированы, вам придется распространять приложение. Потенциально безопаснее было бы распространять файлы учетных данных отдельно и создавать разные файлы для каждого пользователя. Таким образом, если одна из них будет взломана, вам нужно будет только повернуть взломанную учетную запись.
Насколько мне известно, невозможно использовать KMS для хранения учетной записи службы, так как вам все равно потребуется какой-то способ аутентификации с помощью самого KMS.