fnox exec vs fnox lease vs fnox get

[aytekinar]

Hi,

I have the following configuration:

[providers.aws-user]
prefix  = "user/XYZ/"
profile = "fnox"
region  = "eu-north-1"
type    = "aws-sm"

[providers.aws-shared]
prefix  = "dev/"
profile = "fnox"
region  = "eu-north-1"
type    = "aws-sm"

[leases.bedrock]
create_command = "./generate-bedrock-token.py"
duration       = "12h"
type           = "command"

[leases.github]
app_id          = "<app-id>"
installation_id = "<installation-id>"
type            = "github-app"

[leases.github.permissions]
contents      = "read"
pull_requests = "write"

[secrets]
AWS_REGION                   = { default = "us-east-1", description = "AWS Bedrock region to use." }
FNOX_GITHUB_APP_PRIVATE_KEY  = { description = "Private key for GitHub App authentication.", provider = "aws-shared", value = "github-app-private-key" }

In my (shell) environment, I already have the following set-up: AWS_PROFILE=fnox.

When I run fnox get FNOX_GITHUB_APP_PRIVATE_KEY, I get the secret. However, when I run fnox exec -- echo 'Hello World', somehow fnox asks me to sign in via aws sso login. Similarly, fnox lease does not work, either, mostly because the FNOX_GITHUB_APP_PRIVATE_KEY is not available to the github lease. I have tested this in a custom command lease, as well, and I cannot get it.

I can switch to using a command lease, instead, and I can run fnox get FNOX_GITHUB_APP_PRIVATE_KEY to get the key to be able to create short-lived tokens.

I am not sure, though, if this is the correct behavior. Is this a bug or just an intended feature of fnox?

[jdx]

Thanks for the detailed report! Let me walk through what's happening with each command based on your config.

fnox get vs fnox exec

The key difference is the scope of secret resolution:

• fnox get FNOX_GITHUB_APP_PRIVATE_KEY resolves only that single secret from the aws-shared provider. Since your shell has AWS_PROFILE=fnox and the provider config also has profile = "fnox", auth works.

• fnox exec resolves all secrets in the profile via resolve_secrets_batch(), then processes all leases. If you have any other secrets in your config (beyond what's shown in the snippet) that reference a provider whose auth has expired, the batch resolution would trigger the SSO login prompt — even if FNOX_GITHUB_APP_PRIVATE_KEY itself would resolve fine.

Could you share your full [secrets] section? If there are additional secrets referencing aws-user or another provider with an expired SSO session, that would explain why fnox exec prompts for aws sso login while fnox get for a single working secret does not.

Secrets availability to leases

Both fnox exec and fnox lease create resolve all profile secrets and inject them as environment variables (via set_secrets_as_env()) before creating leases. So FNOX_GITHUB_APP_PRIVATE_KEY should be available to the github lease backend — the GitHub App backend reads it via std::env::var("FNOX_GITHUB_APP_PRIVATE_KEY") at lease creation time.

If FNOX_GITHUB_APP_PRIVATE_KEY is not available to the lease, it likely means the secret resolution failed silently (the default if_missing is "warn", which logs a warning but returns None instead of erroring). This would happen if the AWS SM provider auth fails — which circles back to the SSO issue.

Suggested troubleshooting

1. Run with RUST_LOG=debug to see which provider/secret triggers the SSO prompt:

   RUST_LOG=debug fnox exec -- echo 'Hello World'

2. Try setting if_missing = "error" on FNOX_GITHUB_APP_PRIVATE_KEY to get a hard failure instead of a silent skip:

   FNOX_GITHUB_APP_PRIVATE_KEY = { ..., if_missing = "error" }

3. Ensure your SSO session is active before running fnox exec:

   aws sso login --profile fnox

If the SSO session is valid and fnox exec still prompts, the issue is likely another secret/provider in your config triggering auth. Sharing the full config (redacted) would help narrow it down.

This comment was generated by Claude Code.

[aytekinar]

Debugging the command via RUST_LOG=debug actually helped!

The root cause is that we needed to have the BatchGetSecretValue policy, on top of the ListSecrets permission, as in the following:

[
  {
    "Sid": "AllowListAll",
    "Effect": "Allow",
    "Action": "secretsmanager:ListSecrets",
    "Resource": "*"
  },
  {
    "Sid": "AllowBatchReadSecrets",
    "Effect": "Allow",
    "Action": "secretsmanager:BatchGetSecretValue",
    "Resource": "*"
  }
]

for fnox exec to work properly. However, BatchGetSecretValue permission is not documented. This is a missing documentation issue rather than an implementation bug/issue.