[crschnick]

Now I don't fully know the details of your setup, but in general XPipe just works on top of your kubectl installation. So it will only work if you could manually connect to your clusters via kubectl in a terminal. But you can always just try it out and see what happens the community version because I can't say that for sure.

[sepositus]

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.

[mdaniel]

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

[crschnick]

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