4 ms·
Yeah, I'm assuming you're just calling kubectl directly underneath the hood. The way that aws-vault works is that you do something like: `aws-vault exec kubectl
by sepositus 2y ago
Yeah, I'm assuming you're just calling kubectl directly underneath the hood. The way that aws-vault works is that you do something like: `aws-vault exec kubectl ...` or you can just do `aws-vault exec` and drop into a subshell. In both cases, a set of short-lived AWS credentials are exposed via the AWS-defined environment variables to the process (or shell context). The kubeconfig is then configured to handle authentication via AWS (rather than the default certificate method).
So, if you just straight-up call `kubectl` within XPipe without having AWS credentials already available, then it would fail. So, I'm guessing this wouldn't work.
- spacepotato 2y ago[dead]
- crschnick 2y agoYeah, I think something like that will be properly supported once I get around to implementing an aws integration in the future
- mdaniel 2y agoI'm also an aws-vault user and wanted to draw your attention to the fact that kubectl supports exec based credential acquisition (in fact, that's how $(aws eks update-kubeconfig) emits them by default). Now, whether that fits your threat model is a different story, but it's for sure technically possible because I use that setup every day By default, it looks like this: exec: command: aws args: - --region - us-east-2 - eks - get-token - --cluster-name - my-cluster but for us it would look like this: exec: command: aws-vault args: - exec - --region - us-east-2 - my-vault-profile - -- - aws # likely not required, but I'm including it for "coding in a textarea" :-) - --region - us-east-2 - eks - get-token - --cluster-name - my-cluster