Containerized server application failing to connect to MySQL databases

Question

I'm trying to connect my server code running as a Docker container in our Kubernetes cluster (hosted on Google Container Engine) to a Google Cloud SQL managed MySQL 5.7 instance. The issue I'm running into is that every connection is being rejected by the database server with Access denied for user 'USER'@'IP' (using password: YES). The database credentials (username, password, database name, and SSL certificates) are all correct and work when connecting via other MySQL clients or the same application running as a container on a local instance.

I've verified that all credentials are the same on the local and the server-hosted versions of the app and that the user I'm connecting with has the wildcard % host specified. Not really sure what to check next here, to be honest...

An edited version of the connection code is below:

let connectionCreds = {
    host: Config.SQL.HOST,
    user: Config.SQL.USER,
    password: Config.SQL.PASSWORD,
    database: Config.SQL.DATABASE,
    charset: 'utf8mb4',
};

if (Config.SQL.SSL_ENABLE) {
    connectionCreds['ssl'] = {
        key: fs.readFileSync(Config.SQL.SSL_CLIENT_KEY_PATH),
        cert: fs.readFileSync(Config.SQL.SSL_CLIENT_CERT_PATH),
        ca: fs.readFileSync(Config.SQL.SSL_SERVER_CA_PATH)
    }
}

this.connection = MySQL.createConnection(connectionCreds);

Additional information: the server application is built in Node using the mysql2 library to connect to the database. There are no special firewall rules in place that are causing network issues, and that's confirmed by the fact that the library IS connecting, but failing to authenticate.

Answer 1

After setting up Cloud SQL Proxy I managed to figure out what the actual error was: somewhere between the secret and the pod configuration an extra newline was being added to the database name, causing any connection attempt to fail. With the proxy set up this was made clear because there was an actual error message to that effect displayed.

(notably all of my logging around the credentials that I was using to validate that the credentials were accurate didn't explicitly display the newline and was disguised by the fact that the console display added line breaks to wrap the display, and it happened to line up exactly with where the database name ended)