5 ms·

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 manuall

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 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 ago
  Yeah, I think something like that will be properly supported once I get around to implementing an aws integration in the future
- mdaniel 2y ago
  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

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 ago
Yeah, I think something like that will be properly supported once I get around to implementing an aws integration in the future
mdaniel 2y ago
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