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

Implement support for API Key metadata #195

Merged
merged 5 commits into from
Apr 1, 2021

Conversation

aleksmaus
Copy link
Member

What does this PR do?

Adds metadata to they api keys.

      "metadata" : {
        "application" : "fleet-agent",
        "agent_id" : "887f1001-5dc8-45e2-aa61-413123c8013b",
        "type" : "access"
      }

Not sure about the type field, wanted to capture the possible values output and access.
Maybe a better name? or can remove if not needed. @scunningham @ruflin

P.S. If you are having issues running integration tests locally, try delete the elasticsearch docker image and pull the latest one that implements the new api.

Why is it important?

Adopting new ES Api elastic/elasticsearch#48182 for 7.13.

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas

Related issues

Screenshots

Screen Shot 2021-03-31 at 12 55 03 PM

@aleksmaus aleksmaus added the enhancement New feature or request label Mar 31, 2021
@elasticmachine
Copy link
Contributor

elasticmachine commented Mar 31, 2021

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Build Cause: Pull request #195 updated

  • Start Time: 2021-04-01T13:31:08.909+0000

  • Duration: 4 min 11 sec

  • Commit: 64e94bd

Test stats 🧪

Test Results
Failed 0
Passed 66
Skipped 0
Total 66

Trends 🧪

Image of Build Times

Image of Tests

TypeOutput
)

func (t Type) String() string {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is some magic. Switch too boring?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that the Go way

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments on naming and content, but overall LGTM. As soon as we get this in, we should open the backport but AFAIK the feature is not backported yet in ES to 7.13 so testing might / should fail at first.

apikey.Metadata{
Application: apikey.FleetAgentApplication,
AgentId: agentId,
Type: apikey.TypeAccess.String(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea to have type as part of the metadata to differentiate between the output and "access" key. I stumbled over the name "access", may communication or similar? Anyone other ideas?

return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON),
apikey.Metadata{
Application: apikey.FleetAgentApplication,
AgentId: agentId,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Torn if we should call it agent_id or agent.id. to be consistent with ECS. agent.id makes the code more complicated I guess?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tsg FYI, we already add the agent id. Any opinion on format?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that's awesome, thanks for the ping. Also FYI @andrewkroh.

I'd say that we don't really need the . here, since we expect this to be internal. Unless it can be added without headaches.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just had similar debate on the other PR elastic/kibana#95935
user.id vs user_id .... was asked to change to user_id.
can do either way, just let me know

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😆 Can't see the discussion on the commit change. Was the reason there? In the end agree with @tsg it probably does not matter here, especially if in kibana we also use user_id. I always have an ECS preference but I probably spent too much time with ECS :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was a discussion on Slack with one of the reviewers, thus few commits there iterating on the final shape

@@ -293,12 +293,22 @@ func createFleetAgent(ctx context.Context, bulker bulk.Bulk, id string, agent mo
}

func generateAccessApiKey(ctx context.Context, client *elasticsearch.Client, agentId string) (*apikey.ApiKey, error) {
return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON))
return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON),
apikey.Metadata{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One metadata we have for other assets is "managed": true to indicate that this is managed by tooling internally. I think we should add it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will add

return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON))
return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON),
apikey.Metadata{
Application: apikey.FleetAgentApplication,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming: Should we call this application? Service? ...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

naming is hard. the original ES ticket used "application" elastic/elasticsearch#48182
easy to change, I have no preference. let me know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tvernum I think you were the one using application there. Any preference?

@aleksmaus
Copy link
Member Author

Left some comments on naming and content, but overall LGTM. As soon as we get this in, we should open the backport but AFAIK the feature is not backported yet in ES to 7.13 so testing might / should fail at first.

Yep. I added the integration test that should fail on 7.x until this API is backported.

@ruflin
Copy link
Member

ruflin commented Apr 1, 2021

@aleksmaus I would get this PR in independent of the naming discussions. It will be easy to update it later on.

@aleksmaus
Copy link
Member Author

Updated the metadata format based on more recent conversations

    {
      "id" : "jWeejXgBOfmSk3GHgDWJ",
      "name" : "e4dede19-759e-45d5-b08f-0e78dec888e5",
      "creation" : 1617283678345,
      "invalidated" : false,
      "username" : "elastic",
      "realm" : "reserved",
      "metadata" : {
        "agent_id" : "e4dede19-759e-45d5-b08f-0e78dec888e5",
        "managed_by" : "fleet-server",
        "managed" : true,
        "type" : "access"
      }
    },
    {
      "id" : "j2eejXgBOfmSk3GHlDXj",
      "name" : "e4dede19-759e-45d5-b08f-0e78dec888e5:default",
      "creation" : 1617283683555,
      "invalidated" : false,
      "username" : "elastic",
      "realm" : "reserved",
      "metadata" : {
        "agent_id" : "e4dede19-759e-45d5-b08f-0e78dec888e5",
        "managed_by" : "fleet-server",
        "managed" : true,
        "type" : "output"
      }
    }

Screen Shot 2021-04-01 at 9 28 59 AM

@aleksmaus
Copy link
Member Author

@aleksmaus I would get this PR in independent of the naming discussions. It will be easy to update it later on.

just need one 👍

@aleksmaus aleksmaus merged commit 82ea1e7 into elastic:master Apr 1, 2021
mergify bot pushed a commit that referenced this pull request Apr 13, 2021
* Implement support for API Key metadata

* Adjust apikey.Create to make the metadata functional options

* Address code review feedback

* Make metadata properties json omitempty

* Additional changes to the metatadata format

(cherry picked from commit 82ea1e7)
mergify bot added a commit that referenced this pull request Apr 13, 2021
* Implement support for API Key metadata

* Adjust apikey.Create to make the metadata functional options

* Address code review feedback

* Make metadata properties json omitempty

* Additional changes to the metatadata format

(cherry picked from commit 82ea1e7)

Co-authored-by: Aleksandr Maus <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request v7.13.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement support for API Key metadata
6 participants