Azure-storage-azcopy: azcopy login/logout fails

[matthai]

Which version of the AzCopy was used?

10.1.2

Note: The version is visible when running AzCopy without any argument

Which platform are you using? (ex: Windows, Mac, Linux)

Ubuntu 16.04

What command did you run?

$ azcopy login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code xxxxxxx to authenticate.
INFO: Login succeeded.

$ azcopy logout
Error: failed to perform logout command, no cached token found for current user
Usage:
  azcopy logout [flags]

Flags:
  -h, --help   help for logout

Global Flags:
      --output-type string   format of the command's output, the choices include: text, json. (default "text")


failed to perform logout command, no cached token found for current user 

Note: Please remove the SAS to avoid exposing your credentials. If you cannot remember the exact command, please retrieve it from the beginning of the log file.

What problem was encountered?

See above: interactive AD login seems to succeed. But if I try to logout immediately, the logout fails. All other commands (e.g., azcopy copy) also fail, indicating that the login did not actually succeed.

On my other (Ubuntu 18.04, not sure if that's relevant) machine, this all just works.

Both machines are on my desk.

How can we reproduce the problem in the simplest way?

Please see above. The problem is that the problem is only reproducible on one of my machines, so I'm not sure you will be able to repro.

Have you found a mitigation/solution?

Yes, I could use a SAS token instead.

[JohnRusk]

I suspect the login has also failed.

To check, can you login, then do
keyctl show

You should see an AzCopy key (with a distinctive AzCopy-related name) in the session key ring. I suspect you will see that on your other Ubuntu, but not on the failing one.

If so, it sounds similar to an issue we saw on SUSE 12. There, the issue seem to be that the session key ring was not propagated/shared in the expected way. I.e. not according to (our interpretation of) the keyctl documentation. The workaround there was simply to switch to a named session keyring, instead of the default. To do that, run
keyctl session workaroundSession
then use AzCopy as normal. (the session name can be whatever you like, I just called it "workaroundSession" in this example).

I'd suggest you try that, and let us know if it works for you.

[matthai]

Perfect! That worked.

[JohnRusk]

Related to #515

[flavioeb-ciandt]

That did not work for me. I tried many ways.

I'm trying to run it in shell script in jenkins (ubuntu 16.04) and it aways throw the message "no SAS token or OAuth token is present and the resource is not public".

The most weird is that when I do a ssh to the machine and run the commands, it works. Therefore, only fails in jenkins pipeline.

Any ideas?

[JohnRusk]

I don't have any other ideas at this stage, sorry. (Other than use SAS auth instead. Until we can find a better solution and implement it in AzCopy.)

[laurasilvanavi]

@flavioeb-ciandt maybe worthy to check your seccomp profile: https://docs.docker.com/engine/security/seccomp/#significant-syscalls-blocked-by-the-default-profile ? At least that was the issue when I ran in my jenkins pipeline.

@JohnRusk may I ask, are there any plans to enable using service principal with azcopy without keyctl, I mean that there would not be a need to allow containers manipulating kernel keyring?

[JohnRusk]

Yes, there are plans for that. We have not yet finalized the timing or the exact design.

[cdudevops]

Issue still visible.
I have azcopy version 10.4.3
I'm using service principal login in a shell script running under crontab to upload files to azure storage.
If i run the script is working but under crontab fails with:
"failed to perform copy command due to error: no SAS token or OAuth token is present and the resource is not public"
I'm moving back to using SAS token as this solution worked but i wanted to use a solution more suitable for scripting.

[cdudevops]

For debian system adding this at beginning of the script makes the script work:
/bin/keyctl new_session

[jmcshane]

I have a centos 7.7 box experiencing the same issue. I'm going to attempt the workaroundSession and report back any results.

[flavioeb-ciandt]

For me it really did not work using the principal. I really needed to use a SAS auth 😞

[jmcshane]

I got it working with the oauth token:

keyctl new_session
sleep 1
azcopy login --identity --identity-resource-id ${identity_id}
keyctl show #user oauth token displayed
azcopy cp '${blob_endpoint}/artifact.tar' '/opt/artifact.tar'

[zezha-msft]

To avoid using a keyring, please refer to this wiki: https://github.com/Azure/azure-storage-azcopy/wiki/Improved-login-support-for-AzCopy-commands-(with-in-memory-secret-store)

[BzSpi]

@zezha-msft Thanks. This should be in the CLI help page azcopy login -h.