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

[Fleet] Add support for authorizing kibana fleet or fleet server apis using the security api key #93051

Open
narph opened this issue Mar 1, 2021 · 7 comments
Labels
Team:Fleet Team label for Observability Data Collection Fleet team

Comments

@narph
Copy link
Contributor

narph commented Mar 1, 2021

When calling the Kibana Fleet apis and using the ApIKey authorization instead of Basic auth (username:password) the response is:
{"statusCode":403,"error":"Forbidden","message":"Access to Fleet API require the superuser role."}

The user creating the api key has superuser role, also this was tested with an api key which had as role decriptors a superuser role.

More on the security api key here: https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-create-api-key.html

It looks like this is not supported atm and @nchaulet confirmed this.

@andresrc
Copy link

andresrc commented Mar 2, 2021

/cc @ruflin

@andresrc andresrc added the Team:Fleet Team label for Observability Data Collection Fleet team label Mar 2, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@ruflin
Copy link
Member

ruflin commented Mar 2, 2021

I need to read up on this more but I think a role can be specified for an API but in the end the API Key only gets the permissions of the role itself. So if we check for the role, it will not be there and is the reason why it doesn't work.

@narph What is the API call you are making? Is this for /setup?

@narph
Copy link
Contributor Author

narph commented Mar 3, 2021

@ruflin , atm we are making the following calls to the kibana fleet apis:

  • ${KIBANA_URL}"/api/fleet/enrollment-api-keys to retrieve the list of enrollment keys
  • ${KIBANA_URL}/api/fleet/enrollment-api-keys/$ENROLLMENT_TOKEN_ID to retrieve the enrollment token for a specific policy
    We use the above calls to enroll the elastic agent after it has been installed.
  • ${KIBANA_URL}/api/fleet/agents/$agent_id/unenroll to unenroll the agent - we call this api before uninstalling the elastic agent.

Also, right now we use the Default policy to enroll the agent but in the future we might want to create and use a dedicated policy, I do not know if the kibana fleet apis support this or if the fleet server apis will support this in the future but they should be considered as well.

@ruflin
Copy link
Member

ruflin commented Mar 4, 2021

Pinging @tvernum on this. We are checking for a role in Kibana but an API key does not have a role AFAIK so the check fails. Is this assumption correct?

@tvernum
Copy link
Contributor

tvernum commented Mar 5, 2021

You are correct @ruflin - API keys do not have roles, so it is impossible to check whether an API key is superuser.

The stack doesn't really work well with role (name) based checks. We have the same issue with Kibana reporting's reliance on reporting_user as a marker role.

We need to move Fleet to a model where it is checking explicit privileges for each API rather than just leveraging superuser everywhere, but obviously that's a reasonably large change on a long list of things we need to get done here.
Is that something you want to talk about soon, or leave on the list for later?

@ruflin
Copy link
Member

ruflin commented Mar 5, 2021

@tvernum I'm tempted to say we have already enough issue at the same time it means if anyone wants to setup Fleet through the API, username / password is required. I assume if we would have here service accounts, we would have a role if the token is used?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Fleet Team label for Observability Data Collection Fleet team
Projects
None yet
Development

No branches or pull requests

5 participants