Credentials can't be read because of ownership issue

[sebastian-correa]

Question

Hey! Thanks for the Cloud SQL Auth Proxy; I've used it quite a lot in it's standalone form!

I'm trying to add a service to our compose.yml config using the 2-alpine image. We want to authenticate using a Service Account JSON file which we want to mount to the container when spinning up the service. However, I get this error:

Attaching to sql-proxy
sql-proxy  | 2024/02/24 00:01:31 Authorizing with the credentials file at "/sa.json"
sql-proxy  | 2024/02/24 00:01:31 The proxy has encountered a terminal error: unable to start: error initializing dialer: Config error: open /sa.json: permission denied (connection name = "n/a")
sql-proxy exited with code 1

My SA JSON file is owned by me and a group that I share with other team mates who might want to use the file, though making it work for my user is the first (and most urgent) step.

I saw #1124 which is related, but the fix there doesn't work for me as I can't change the permissions over my credentials file in my environment. There's also this SO question where they set up things almost the same as me.

Code

proxy:
    image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2-alpine
    container_name: sql-proxy
    platform: linux/amd64
    command: [
      "--port", "12345",
      "--credentials-file", "/sa.json",
      "project:zone:instance-name"
    ]
    ports:
      - 12345:12345
    volumes:
      - type: bind
        source: ./sa.json
        target: /sa.json

Additional Details

This works on my local machine but doesn't on a shared server (Ubuntu 20.04.6 LTS) where I don't have much permissions (though I own the file).

[sebastian-correa]

The file I was mounting had permissions 770. I changed them to 774 and the proxy started working (tried in tags 2-buster, 2-alpine and 2 which uses distroless I think).

If this is expected behavior, then this issue can be closed. Otherwise, please let me know how this should be handled :).

---

Edit: this is unrelated to the issue, but for anyone with problems like me, I was missing an --address 0.0.0.0 in my command so that the proxy doesn't only listen to connections originating from within the container.

[enocom]

Yes, expected behavior, but a little tricky to handle.

You've found the issue I'd point you to (#1124) and by changing permissions to 774 you're letting "other" read the file, which is why this works.

You might also try changing the group of the file and give group read access. This is probably more secure.

Is your shared server a GCE instance?

[sebastian-correa]

You might also try changing the group of the file and give group read access.

Changing the current group to what other group? The group already has Read Write and Execute access over the file.

Is your shared server a GCE instance?

Nope, it's an on-prem Ubuntu computer. We consider the box "secure", so it's not too much of an issue to have "anyone" with read access to this file, but it's undesirable if there's a better way :).

I'm interested in your response in the case where I'd answered "yes", though, as it might come in handy in the near future.

[enocom]

The short answer is if you're running on a GCE instance, the standard Google Cloud auth library will source Application Default Credentials from the GCE metadata server. So you won't have to provide a key file at all (assuming you're running the GCE instance as an IAM principal that has the cloudsql.client role).

[enocom]

Changing the current group to what other group? The group already has Read Write and Execute access over the file.

If you do this, you can avoid making the file readable by other (e.g., 440, write and execute shouldn't be necessary):

chgrp 65532 key.json && chmod g+r key.jso

[sebastian-correa]

Changing the current group to what other group? The group already has Read Write and Execute access over the file.

If you do this, you can avoid making the file readable by other (e.g., 440, write and execute shouldn't be necessary):

chgrp 65532 key.json && chmod g+r key.jso

The issue with that command is that the file's permissions are already handled by a specific group (to which I belong) and I can't change that :S.

You can mark the issue as resolved since I'm fine with my permissions as they are and I can't use your solution (which is a bit more ideal). However, I'd welcome it if some thought could be given to mounting credentials to the container regardless of the file's ownership in the host system. I understand it's tough (impossible?) because the process is run by an unprivileged user.

At least, I think adding your suggestion (and/or mine) to the README could be useful. I can open a PR if it's something you'd welcome :).

[enocom]

Yes, updating the docs would very much appreciated. Right now, we don't have a great spot to put this other than the README.

How about adding a section under https://github.com/GoogleCloudPlatform/cloud-sql-proxy?tab=readme-ov-file#container-images and call it "Working with Docker and the Proxy"? Some kind of section about Docker usage generally below the container images seems best.

[sebastian-correa]

Hey, thanks for your patience! I'll tackle this at some point this week.

I think adding a section in that part of the readme seems like the best course of action. I'll draft a PR and we'll go from there.