Is a session id portable between "systems"

sbv1976

Hello, I am automating orchestration of some containers and one of them needs temporary access to 1Password for access to secrets.

Is it possible to pass a session id generated on a host to op running in a container? I figure this is safer than passing 1password auth info directly and also provides a better user experience.

My efforts to do this have been thus far unsuccessful.

Thanks,
Steven

---

1Password Version: CLI 0.4
Extension Version: Not Provided
OS Version: OSX 10.3.3 (host) and ubuntu core 16 (container)
Sync Type: Not Provided

rickfillion

Technically yes. You would need to pass both the session token and the session file to make it work.

Rick

sbv1976

Hi @rickfillion,

Thanks for the response. I believe I am meeting these requirements. However, when I was using 0.4 on the host and 0.3 on the container, I was getting "not implemented on linux" and now that I have updated the container to use the matching 0.4 version, the message improves to

[LOG] 2018/04/23 14:32:27 (ERROR) You are not currently signed in. Please run op signin --help for instructions

For the command op get account.

I have verified that OP_SESSSION_x environment variable is visible and matching the host in the container and I have mounted my entire ~/.op directory where I believe it is expected. Perhaps I don't understand what the "session file" is.

Where is that?

Is there a verbose/diagnostic output mode for op that can help me determine if everything is as intended.

Thanks Again,
Steven

rickfillion

@sbv1976 : you'll need to copy over the tmp dir's com.agilebits.op.* (exact location of the tmp dir will vary based on systems, but it's typically $TMPDIR) as well as that's where the session file lives.

Rick

rickfillion

Note that what you need to copy is the com.agilebits.op dir that's for your specific user (the last part is the uid of your user) and needs to be named accordingly on the other system.

What you're trying to do is technically possible, but it's not a recommended thing to do.

Rick

sbv1976

OK, that helps.

Is there any particular reason why this is not recommended? Is it due to the sensitivity of the shared information? I figure the session data is less sensitive than auth credentials. Also, fetching secrets on the container should be more secure than fetching them on the host and passing them along since they would have to go through the container environment or the host filesystem to make the transition.

Is it that these things are implementation details and subject to change without notice?

I wonder if I am using the wrong tool for this. I have heard that something like Hashicorp vault is more targeted to my workflow, but I don't really understand the comparative benefits.

Thanks,
Steven

rickfillion

Assuming that I'm understanding what you're trying to accomplish, it's a good goal: have a way of representing a session/credentials that isn't the textual representation. The reason that I say that it's not recommended is simply because there is no official support in op to do this. We've "solved" this problem in our SCIM bridge which is based on op and I hope that one day we'll be able to bring official support for it to op. The SCIM bridge solution is really nice because what you end up sharing with the other instance isn't the textual credentials (which has the problems you're trying to solve), nor is it the session key which has another set of problems like the fact that it will expire ~30 minutes after the server last hears from it. What's shared is data that's somewhere between those two such that new sessions can be created if needed.

If you try to roll your own solution you're going to be hitting some hurdles:

• The name of the dir for the session file can be different on the different systems
• op is very picky about the permissions of that dir so creating it manually can be tedious
• The session needs to be used relatively quickly otherwise the server will invalidate it (30 minutes after the server last hears from it)

We aren't really interested in solving those specific problems. I want to solve the bigger problem like we did for the SCIM bridge, but it might take us a while before we get around to bringing that solution back to op.

Whether you're using hashicorp vault or not, in order to do the authentication you'll need something that represents a secret available to you in memory somewhere.

Rick

sbv1976

You lost me at SCIM ;)

So, I think I can deal with the limitations. I will plan on using things as-is if I can get them to work and keep an eye out for an improvement.

Thanks for all the help and commentary.

Steven

AGAlumB

Likewise, thanks for sharing your use case! Perhaps we'll be able to add some additional options in the future. :)