-
Notifications
You must be signed in to change notification settings - Fork 81
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
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪 |
TypeOutput | ||
) | ||
|
||
func (t Type) String() string { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that the Go way
There was a problem hiding this 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.
cmd/fleet/handleEnroll.go
Outdated
apikey.Metadata{ | ||
Application: apikey.FleetAgentApplication, | ||
AgentId: agentId, | ||
Type: apikey.TypeAccess.String(), |
There was a problem hiding this comment.
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?
cmd/fleet/handleEnroll.go
Outdated
return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON), | ||
apikey.Metadata{ | ||
Application: apikey.FleetAgentApplication, | ||
AgentId: agentId, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 :-)
There was a problem hiding this comment.
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
cmd/fleet/handleEnroll.go
Outdated
@@ -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{ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will add
cmd/fleet/handleEnroll.go
Outdated
return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON)) | ||
return apikey.Create(ctx, client, agentId, "", []byte(kFleetAccessRolesJSON), | ||
apikey.Metadata{ | ||
Application: apikey.FleetAgentApplication, |
There was a problem hiding this comment.
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? ...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
Yep. I added the integration test that should fail on 7.x until this API is backported. |
@aleksmaus I would get this PR in independent of the naming discussions. It will be easy to update it later on. |
Updated the metadata format based on more recent conversations
|
just need one 👍 |
* 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)
* 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]>
What does this PR do?
Adds metadata to they api keys.
Not sure about the
type
field, wanted to capture the possible valuesoutput
andaccess
.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
Related issues
Screenshots