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.

I'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

Yeah, I think something like that will be properly supported once I get around to implementing an aws integration in the future