If I “run” the gateway with default settings, it will print the Access key and Secret key to the terminal:
...
2020-02-05T19:13:44.734Z INFO Endpoint: 127.0.0.1:7777
2020-02-05T19:13:44.734Z INFO Access key: insecure-dev-access-key
2020-02-05T19:13:44.734Z INFO Secret key: insecure-dev-secret-key
But that depends on the log.level in the config file at INFO. For production purposes, that level should probably be higher such as WARN.
How do I obtain this Access key and Secret key then? Or in general, after the “run” has been run for some hours/days/months?
Am I supposed to parse the minio config.json or is there a more user-friendly way?
I think the expectation for running a production gateway is that you actually set the access key and the secret key in your gateway configuration. gateway run --help suggests you can specify --minio.access-key and --minio.secret-key. instead of letting the gateway choose them for you, you can choose them yourself (at random or otherwise), and then your other tools can use whatever method you picked that way.
Also of note, though not what you asked - when you say you run it with default settings, are you using a release build or are you using a build from source? It turns out, the default settings are different depending on your choice! Make sure to use a build from a specific release tag, or specify --defaults=release somewhere. Our release process adds version information when we tag releases that also changes the default settings behavior.
Bunch of info here I couldn’t easily glean from the documentation. Thanks @jtolio!
Some comments:
specifying those keys as arguments to the command is not ideal when running the gateway as a daemon. For a daemon, the logical invocation is gateway run --config-dir /etc/storj or something like that, and the gateway takes all the data it needs from the config files found in that directory. If I have to put the keys into the invocation itself, I have to create an extra config file and parse that in my systemd.service file etc – that’s complicated and counter-intuitive if a config dir parameter exists.
also, a secret key specified as argument might end up in ps output, which is not good from a security perspective.
so I would suggest to define a new file, say gateway-keys.yaml or such, whose location is in the (default or overridden) config-dir and from where the keys are taken. (Alternatively add to the config.yaml file itself.) And have gateway setup ask for initial values as well, and know how to print them when asked.
Oh, I’m so sorry, I left out a super important detail that I think addresses all your points (sans setup asking for these values directly) - everything in --help can also be specified in the config file. --minio.access-key looks like this in the config file if you run gateway setup:
# Minio Access Key to use
minio.access-key: "<key>"
# Minio Secret Key to use
minio.secret-key: "<key>"
That’s the config.yaml file? Because the config.json in the minio subdirectory also has credential.accessKey etc. (Those are overridden if values are given in the yaml file?)
Can I suggest that the generated config.yaml contain those minio.xxx-key, commented-out (or better, with the auto-generated values) like it does all the other values. NVM they are there.
The Self-hosted S3-compatible Gateway will print keys on start to the stderr or log file, if you change it with --log.output option in the gateway run command or as an option log.output in it’s config.yaml file.
Regarding keys, you can also grep your config.yaml like this: