Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Agent registration process #56

Closed
pmm-sumo opened this issue Jan 13, 2022 · 4 comments
Closed

Agent registration process #56

pmm-sumo opened this issue Jan 13, 2022 · 4 comments

Comments

@pmm-sumo
Copy link
Contributor

Currently, OpAMP Client can practically identify itself using two means:

  • instance_uid field, included in AgentToServer message
  • via HTTP authentication fields (using either Basic Auth or Bearer) - if it is using unique credentials

The UID generation is a concern of the agent, which might limit some use cases where certain formats of UID can be used to identify different groups of agents and as such should be provided by server, also ensuring that two agent instances always use different ID's.

For HTTP authentication, there are different use-cases and sometimes a single set of credentials can be used for a larger group of clients. However, it might be preferred to have an initial, installation-only auth token that is used only to identify the type of the agent and handle the registration after which the agent is provided with a unique token that will be used for any further communication. The unique identifier of the agent can be embedded into such token.

Perhaps there's a room to provide support for agent registration procedure, in which a registration-only token is used to get the agent-unique token that will be persisted and used for future communication?

@mtwo
Copy link
Member

mtwo commented Jan 25, 2022

Following up from the weekly call, we should discuss this next session once @pmm-sumo is back. We'd like to understand more about the scenarios that require the unique ID to be provided by the server.

@tigrannajaryan
Copy link
Member

Discussed in Workgroup meeting. We can add ability for the Server to command the Agent to use a different UID. We can also make UUID optional in the first message from the Agent. The combination of these 2 features allows to:

  • Agent to request the Server to assign it a UUID on first connect.
  • Server to detect duplicate UUIDs and order Agents to use a different UUID.

@pmm-sumo
Copy link
Contributor Author

I promised to prepare a PR with proposal of the spec update, got a bit delayed but should have it this week

tigrannajaryan pushed a commit that referenced this issue Mar 22, 2022
This is a first approach towards #56 

It assumes that Agent's `instance_uid` can always be updated by Server (since resolving potential issues with conflicts is important).

There's a gap with multiplexed websocket connections which perhaps could be handled by adding Agent capability flag indicating if overrides can be accepted or not
@tigrannajaryan
Copy link
Member

I think #63 resolves this issue. Closing, but feel free to reopen if there is more to do.

dsvanlani added a commit to observIQ/opamp-spec that referenced this issue Mar 22, 2022
* Add support for detached signatures (open-telemetry#69)

Resolves open-telemetry#65

- Added signature field to DownloadableFile message.
- Added a short explanation about how the signature field can be used
  for detached signatures.

* Set instance_uid by Server on conflict or request for generation (open-telemetry#63)

This is a first approach towards open-telemetry#56 

It assumes that Agent's `instance_uid` can always be updated by Server (since resolving potential issues with conflicts is important).

There's a gap with multiplexed websocket connections which perhaps could be handled by adding Agent capability flag indicating if overrides can be accepted or not

Co-authored-by: Tigran Najaryan <[email protected]>
Co-authored-by: Przemek Maciolek <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants