You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
AWS - support sourcing credentials from a different profile #212
AWS shell plugin should allow for sourcing a certain profile's credentials from another profile.
Current behavior
Currently AWS shell plugin supports long lived credential authentication, MFA and Assume Role support with temporary credentials authentication.
Relevant log output
No response
op CLI version
No response
Reacted by Ricky Nguyen, Chase Dickinson, Joey Bolduc-Gilbert, Yusuke WADA, Mark Patricio, Barry Morrison, Chris Connor, Josh Smeaton, Caspar Fuller, Mikhail Lukianchenko and 7 more
I need to manage multiple environments using Terraform, so this feature is crucial. The final work will be executed through CI/CD; however, I'd like to frequently check the progress in the terminal while working.
I need to manage multiple environments using Terraform, so this feature is crucial. The final work will be executed through CI/CD; however, I'd like to frequently check the progress in the terminal while working.
Since #180, commands like aws s3 ls --profile dev or export AWS_PROFILE=dev; aws s3 ls are supported by the AWS shell plugin, and all the assumed profile information will be extracted from your already existing .aws/config file (or $AWS_CONFIG_FILE).
From my understanding you are requesting support for the following scenario:
If you specify source_profile = production-profile in the config file under profile dev then profile dev should use the same root credentials as production-profile.
This could be achieved today without the source_profile = production-profile directive inside the config file, by doing op plugin init aws and selecting the 1Password item that stores production-profile's root credentials. Then when you are assuming your dev profile with aws s3 ls --profile dev you will be using your production-profile root creds.
Can you help me better discover your use case, and in which scenarios the explained solution above would fall short?
@AndyTitu Thanks for your reply.I commented because the error message was directing me to this issue.
I removed the source_profile as per your message and the profile switch was successful. Thanks for teaching me how to do this.
However, the call from terraform failed and I would like to know if there is a proper place for this issue.
@AndyTitu Thanks for your reply.I commented because the error message was directing me to this issue. I removed the source_profile as per your message and the profile switch was successful. Thanks for teaching me how to do this.
However, the call from terraform failed and I would like to know if there is a proper place for this issue.
Here is the issue for supporting the terraform use case, for aws but in general for any other tool. #140
@jarshwah , @fillz-noh and everyone else involved in this issue: We have just released our new beta solution for the Terraform shell plugin. This allows AWS to work with Terraform out of the box, and also comes up with a general solution for authenticating terraform providers. Would be awesome if you could give it a try and let us know how/if this simplifies your workflows by a bunch.
I don't know if I'm missing something else but I've been trying the beta (2.19.0-beta.01) in combination with an EKS, having set up just the op cli command and the aws plugin.
However, it's impossible for interacting with EKS using the current solution, it still seems to be requiring the source_profile. The full error output is:
Partial credentials found in assume-role, missing: source_profile or credential_source
Am I missing something or is an additional fix going to be required?
However, it's impossible for interacting with EKS using the current solution, it still seems to be requiring the source_profile. The full error output is:
Partial credentials found in assume-role, missing: source_profile or credential_source
@jandeschuttere thanks for sharing your use case! The first thing that comes to mind when seeing that error is that the shell-plugin is not actually wrapping the tools you are using to manage EKS. Can you please share the exact command(s)/script that you are running?
This happens with any of the commands interacting via kubectl because it's trying to authenticate first, the authentication process is unable to complete successfully.
The alias is not able to override this behaviour. Perhaps a different config in the ~/.kube/config could be set up so that it can use the alias or introduce the wrapping logic the same way as that alias is doing but I was at least not able to easily do so.
Activity
fillz-noh commentedon Apr 26, 2023
I need to manage multiple environments using Terraform, so this feature is crucial. The final work will be executed through CI/CD; however, I'd like to frequently check the progress in the terminal while working.
AndyTitu commentedon Apr 26, 2023
Thank you to all who left feedback on this issue!
Since #180, commands like
aws s3 ls --profile devorexport AWS_PROFILE=dev; aws s3 lsare supported by the AWS shell plugin, and all the assumed profile information will be extracted from your already existing.aws/configfile (or$AWS_CONFIG_FILE).From my understanding you are requesting support for the following scenario:
If you specify
source_profile = production-profilein the config file under profiledevthen profiledevshould use the same root credentials asproduction-profile.This could be achieved today without the
source_profile = production-profiledirective inside the config file, by doingop plugin init awsand selecting the 1Password item that storesproduction-profile's root credentials. Then when you are assuming yourdevprofile withaws s3 ls --profile devyou will be using yourproduction-profileroot creds.Can you help me better discover your use case, and in which scenarios the explained solution above would fall short?
fillz-noh commentedon Apr 28, 2023
@AndyTitu Thanks for your reply.I commented because the error message was directing me to this issue.
I removed the
source_profileas per your message and the profile switch was successful. Thanks for teaching me how to do this.However, the call from terraform failed and I would like to know if there is a proper place for this issue.
AndyTitu commentedon May 1, 2023
@fillz-noh Sure, glad I could help!
Here is the issue for supporting the terraform use case, for aws but in general for any other tool.
#140
Also, I've just opened a PR about this: #256
jarshwah commentedon May 17, 2023
This works for the aws cli but breaks other tools like sops since it's no longer able to determine the root credentials/keys.
AndyTitu commentedon May 24, 2023
@jarshwah , @fillz-noh and everyone else involved in this issue: We have just released our new beta solution for the Terraform shell plugin. This allows AWS to work with Terraform out of the box, and also comes up with a general solution for authenticating terraform providers. Would be awesome if you could give it a try and let us know how/if this simplifies your workflows by a bunch.
jandeschuttere commentedon May 30, 2023
Hi
I don't know if I'm missing something else but I've been trying the beta (
2.19.0-beta.01) in combination with an EKS, having set up just the op cli command and the aws plugin.However, it's impossible for interacting with EKS using the current solution, it still seems to be requiring the
source_profile. The full error output is:Am I missing something or is an additional fix going to be required?
AndyTitu commentedon Jun 2, 2023
@jandeschuttere thanks for sharing your use case! The first thing that comes to mind when seeing that error is that the shell-plugin is not actually wrapping the tools you are using to manage EKS. Can you please share the exact command(s)/script that you are running?
jandeschuttere commentedon Jun 5, 2023
This happens with any of the commands interacting via
kubectlbecause it's trying to authenticate first, the authentication process is unable to complete successfully.When I looked closer into it it seems that the introduced shell-plugin is actually setting up an alias to wrap the 1pwd command, yet the kubectl config for EKS introduces an auth provider type "exec" (see https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration)
The alias is not able to override this behaviour. Perhaps a different config in the ~/.kube/config could be set up so that it can use the alias or introduce the wrapping logic the same way as that alias is doing but I was at least not able to easily do so.
tr0mpa commentedon Sep 25, 2023
@jandeschuttere Hey solved it by wrapping op command to
kubeconfiglike this: