Nikolaos Moraitis
Nikolaos Moraitis
@irbekrm Thanks for the response. Yea, I change my deployments to use the `v1.11.0` version. Same problem.
Worth to mention here that the `_acme-challenge` was actually created in my AWS Route53. So I don't think that there is an issue with the permissions. I used the policies...
@irbekrm Based on `dig` and `nslookup` commands, my DNS is correctly propagated. The problem is clearly in `cert-manager`. Do you have any insights on what to check? My AWS credentials...
The only workaround is to expose the address via the `VAULT_ADDR` environment variable. However, this BUG still stands.
@stevendpclark I tried all combinations. This is still not working
@stevendpclark I am using `Vault v1.7.2 (db0e4245d5119b5929e611ea4d9bf66e47f3f208)` The command is `vault policy write read-only my-policy.hcl --address=http://localhost:8200` I tried - `vault --address=http://localhost:8200 policy write read-only my-policy.hcl` - `vault policy --address=http://localhost:8200 write...
I still get the errors. Perhaps I am using a problematic release. Let me try to replicate the issue with the latest version.
@raskchanky It's not a bug. It's just how vault cli works... It seems that the global flags need to be in a specific place. /shrug
@timqian friendly reminder.
> Info: we use this change on our cert-manager prow cluster https://prow.infra.cert-manager.io/ (see https://github.com/cert-manager/testing/tree/0b5dfa456f691e849bb0b3c40f3e00bd8d607127/images/prow-controller-manager-spot). It works very well, this change has removed a lot of flaky failures due to spot...