Add support of App ID and User ID management

[ggonchar]

Currently I feel a lack of functionality in App ID and User ID authentication method in order to use it. What can be improved:

• Add possibility to list User IDs
• Add possibility to list User IDs assigned to particular App ID
• Add possibility to view if User ID has active tokens
• Add possibility to remove User ID (e.g. in case if it was compromised)
• Add possibility to list existent App IDs
• Add possibility to remove App ID

[ProbablyRusty]

Also, I frequently pair multiple App IDs with a single User ID, ie:

vault write auth/app-id/map/user-id/foo value=bar,baz,xyz,abc

It would be great to be able to easily add, list, and remove User ID pairings without manually maintaining this comma separated value list and firing the vault write against the user-id path for every edit.

[ProbablyRusty]

Closed, "on the roadmap", or closed, "not under consideration at this time"?

[vishalnayak]

@consultantRR

Some of the Vault issues were closed by mistake from a syncing software. We apologize for the confusion caused. We have reopened the issues that were closed and are investigating the problem that caused this. We are very sorry for the inconvenience.

[kunickiaj]

Out of curiosity, is the use case that you have multiple services (app-ids) running on the same host?

[ProbablyRusty]

@kunickiaj Yes, this (multiple services (app-ids) running on the same host) is exactly the use case I am addressing in my comment above.

Currently, pairing multiple app-ids with one user-id is possible in Vault, but as I note above, this is currently a bit cumbersome to maintain. (See: #486.)

To take it one step further:

In an ideal world, it would additionally be possible to not only pair multiple app-ids to each user-id, but also to pair multiple user-ids to each app-id. This would make it possible, for example, for one app-id to have different policies based on the environment in which it is running.

Consider this use case:

3 multi-service hosts (dev, test, prod)
each host has its own user-id

2 services running on each host (service-a, service-b)
each service has its own app-id

(1) When, for example, service-a and service-b are both launched on dev each of the two services has a different Vault policy from the other.

(2) When, for example, service-a is launched on both dev and prod, the dev instance of this service has a different Vault policy than the prod instance of this service.

Case (1) is already possible today, although it would be very nice for the pairings to be easier to maintain, as per my earlier comment. Case (2) is not possible today without the services using different app-ids in each environment.

[kunickiaj]

Yeah, I understand what you're saying. But given that app-id is typically deployed by your config management, I could also argue that since config management usually has its own variables for deploying to dev, test, prod it would be responsible for deploying the appropriate app-id for that environment (which is then tied to the appropriate policy).

user-id just represents a particular piece of hardware in most cases.

Either way this discussion is probably off-topic for this particular ticket ^^

[ProbablyRusty]

I agree that the latter half of the discussion warrants conversation in an alternate channel, but I stand by my request for better management of one-to-many app-id to user-id pairings as on-topic to this ticket.

[sgran]

Hi,

I'm used to config management doing declarative management of resources. I'd like to be able to model app-ids and user-ids and the association between them as resources, so that config management can add, remove, and update them as appropriate.

In order for this to work, I am starting with the following workflow:

• obtain list of user-ids
• for each user-id, obtain associated data and model as a resource (in this case, data will be an array of app-ids)
• obtain list of app-ids
• for each app-id, obtain associated data and model as a resource (in this case, data will be an array of policies
• obtain list of policies
• for each policy, obtain associated data
• obtain list of secrets
• for each secret, obtain associated data
• traverse list, ensuring that after update, the data set will be referentially coherent - all app-ids referenced from user-ids must exist, all policies referenced from app-ids must exist, all secrets referenced from policies must exist.
• update each resource type to match config managent declaration
• remove unmanaged resources.

At present, I can do most of this - I can correctly model secrets and policies and the relationship between them. If I start with a known user-id, I can traverse the list to ensure coherency of the relations to app-ids, and their relations.

I can not enumerate either unknown user-ids or unknown app-ids, so I can not model the system as a whole. Being able to list these maps does not seem like it is structurally difficult. Is there a reason beyond effort that this has not been implemented?

Cheers,

[jefferai]

@sgran It's actually much more difficult than you think because of the way the backend was built. Partially because of this, and to solve various other issues with it, AppID is going to be deprecated and replaced with #1426. Please note that the code there is very early and will definitely be changing in various ways, but if you like you can peruse it and see how it's different.

There's nothing you can do with AppID that you can't do with the replacement, but the new one will enable much better workflows and management.

[jefferai]

Closing since AppRole implements this, App-ID can't, and App-ID is now deprecated.