Currently, if you are in a given identity (like Home) and create a new record in a private folder, that record will be created as part of that identity. Thus when the record is created it will show in the list of records as expected. If you then edit that record and move it to a shared folder and save the record, the record will lose the assigned identity and will no longer appear to be in your list of records. In order to see the record you must switch to the All identity. (And to see it again in your other identity like Home you must add the record to that identity.) This is bad because the behavior appears to a user to be that moving a record from a private to a shared folder deletes the record! That is because after you move the record to a shared folder the record appears to disappear due to no longer being part of the identity you are currently using. (And even worse, a non-shared copy of the record appears in the Deleted records since technically moving a record from a private folder to a shared folder deletes the private record and makes a new one in the shared folder.) The only way to avoid this is to switch to the All identity before you move any record from a private folder to a shared folder, then after moving the record assign any desired identity to the record. LastPass support insists that this is correct and expected behavior and that only a new feature request with enough support can get it fixed/changed. Please add your support. (Note that this has been tested on a Teams account, if anyone can confirm this on other types of accounts that will help technical support and the developers when they implement this fix/suggested new feature.)
... View more
Use case: As a developer, I want my CI/CD pipeline to access a secret stored in LastPass, so that I can store and manage secrets in a single place. Context: We use LastPass Enterprise to manage passwords for our organization. We chose to store secrets there for the general usability and central control and visibility across all roles in the company. Most of the entries we store are individual logins and fit nicely into the supported LastPass workflows. However, we'd like to be able to issue tokens with limited scopes for use by machines or bot users as well. We have some entries (think things one might use in CI/CD pipelines and tokens for other services) which are primarily used by automated processes, but which humans occasionally need to access to rotate them, provide them to a new service which must re-use an existing token, or in a "break glass" manual override scenario. We can use other products (like Vault) to support this use case, but it would be ideal to be able to centralize all of our long-term secrets within one system which is familiar for all of our users. To that end, we'd like to be able to generate a token for use by the LastPass CLI. This token could ideally be very granularly scoped (providing read-only access to a single entry, for example). The token would then be stored in the CI/CD's secret storage and the "real" secret would be retrieved during the pipeline run. (An alternative would be to support similarly granular access, but using a third-party identity provider. For example, the way AWS supports authentication based on GitHub identities. However, not all of the services we'd like to use would currently support this method). Hopefully others will also find value in this use case and we can continue to use LastPass for all types of secrets.
... View more