I kept digging and I knew this was coming…

https://novadiscovery.github.io/novops/config/aws.html

There is absolutely never a reason to have an AWS secret key and access key in an environment file. You should always use the role attached to the EC2 instance, Lambda, Fargate instance etc.

Even when developing locally you should be using temporary credentials or if that’s not possible use your credentials that are configured when you use “aws configure” at least then your credentials are in your home directory and not in your repository directory.

No you don’t need to specify credentials when instantiating a client using the various SDKs.

This entire project is recommending bad practices by having anything sensitive ever in a file that you’re committing to source control or that’s in your repository even with .gitognore.

> https://novadiscovery.github.io/novops/config/aws.html

> There is absolutely never a reason to have an AWS secret key and access key in an environment file. You should always use the role attached to the EC2 instance, Lambda, Fargate instance etc.

I disagree. There are plenty of reasons for which you'll want to generate temporary credentials in a local _secure_ file - for instance that's how AWS official doc recommends using temporary creds [1], how Hashicorp Vault CLI stores token under ~/.vault-token by default [2] and how Docker login generates creds under ~/.docker/config.json [3]. As long as these files have proper permissions...

However not writing anything to disk is a good idea: we may implement a workflow such as `export $(novops load -e dev -o -)` to write output directly to stdout and export it as-is.

> when developing locally you should be using temporary credentials

Good, we agree then. That's exactly what Novops does with AWS Roles: generating temporary AWS credentials, whether using STS directly or through Hashicorp Vault AWS Secret Engine.

> at least then your credentials are in your home directory and not in your repository directory.

There won't be any creds in Git repo, that's exactly what we want to avoid. What made you think that? Every sensitive data is stored under $XDG_RUNTIME_DIR [4], a special directory only accessible to current user and cleaned-up on logout / shutdown. It's widely used for similar use cases (Podman does it for instance) and safer than having secrets in $HOME directory. There's a piece of doc on that subject [5]

Novops may create a symlink in Git repo pointing to file in $XDG_RUNTIME_DIR, so even if it's commited by mistake nothing bad would happen. Only `.novops.yml` is to be commited in Git. It instructs Novops how credentials / secrets should be generated or retrieved. It does not contain any sensitive data.

For example, to impersonate IAM Role, `novops.yml` would contain IAM Role name which is not sensitive information, e.g.:

  assume_role:

     role_arn: arn:aws:iam::12345678910:role/my_dev_role

I'm not sure to understand this remark, though I interpret it as "One needs to provide additional credentials (such as AWS creds) for Novops to work". (please clarify if I misunderstood this point)

Novops does not need additional credentials to work, it will try to use existing "standard" credentials available when possible. Great efforts were made to be as transparent as possible for user and if you see room for improvements I'll gladly hear it. For instance, Novops will try to use AWS credentials under ~/.aws/config|credentials as would any AWS SDK or CLI.

> This entire project is recommending [...] having anything sensitive ever in a file that you’re committing to source control

Absolutely not. As said above, any sensitive content is stored temporarily under $XDG_RUNTIME_DIR. Only `.novops.yml` is commited to Git and it does not contain any sensitive data.

I hope I made things clearer about design and intended usage. I'm genuinely curious to understand what made you think any secret were to be commited to Git so that doc and usage recommandations can be improved to avoid further confusion.

[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...

[2] https://developer.hashicorp.com/vault/docs/commands/token-he...

[3] https://docs.docker.com/engine/reference/commandline/login/#...

[4] https://specifications.freedesktop.org/basedir-spec/basedir-...

[5] https://novadiscovery.github.io/novops/advanced/security.htm...

From what you described here, I am more comfortable with the implementation.