-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Add support for API keys to access Elasticsearch (#38291) #38399
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bizybot
added
:Security/Authentication
Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
backport
labels
Feb 5, 2019
Pinging @elastic/es-security |
bizybot
force-pushed
the
backport-api-keys
branch
from
February 5, 2019 09:47
024b0a6
to
05ce708
Compare
@elasticmachine run elasticsearch-ci/packaging-sample |
X-Pack security supports built-in authentication service `token-service` that allows access tokens to be used to access Elasticsearch without using Basic authentication. The tokens are generated by `token-service` based on OAuth2 spec. The access token is a short-lived token (defaults to 20m) and refresh token with a lifetime of 24 hours, making them unsuitable for long-lived or recurring tasks where the system might go offline thereby failing refresh of tokens. This commit introduces a built-in authentication service `api-key-service` that adds support for long-lived tokens aka API keys to access Elasticsearch. The `api-key-service` is consulted after `token-service` in the authentication chain. By default, if TLS is enabled then `api-key-service` is also enabled. The service can be disabled using the configuration setting. The API keys:- - by default do not have an expiration but expiration can be configured where the API keys need to be expired after a certain amount of time. - when generated will keep authentication information of the user that generated them. - can be defined with a role describing the privileges for accessing Elasticsearch and will be limited by the role of the user that generated them - can be invalidated via invalidation API - information can be retrieved via a get API - that have been expired or invalidated will be retained for 1 week before being deleted. The expired API keys remover task handles this. Following are the API key management APIs:- 1. Create API Key - `PUT/POST /_security/api_key` 2. Get API key(s) - `GET /_security/api_key` 3. Invalidate API Key(s) `DELETE /_security/api_key` The API keys can be used to access Elasticsearch using `Authorization` header, where the auth scheme is `ApiKey` and the credentials, is the base64 encoding of API key Id and API key separated by a colon. Example:- ``` curl -H "Authorization: ApiKey YXBpLWtleS1pZDphcGkta2V5" http://localhost:9200/_cluster/health ``` Closes elastic#34383
bizybot
force-pushed
the
backport-api-keys
branch
from
February 5, 2019 10:52
05ce708
to
3554850
Compare
@elasticmachine run elasticsearch-ci/2 |
@elasticmachine run elasticsearch-ci/2 |
@elasticmachine run elasticsearch-ci/1 |
jasontedor
added a commit
to jasontedor/elasticsearch
that referenced
this pull request
Feb 6, 2019
* 6.x: (25 commits) Backport of types removal for Put/Get index templates (elastic#38465) Add support for API keys to access Elasticsearch (elastic#38291) (elastic#38399) Deprecate support for internal versioning for concurrency control (elastic#38451) Deprecate types in rollover index API (elastic#38389) (elastic#38458) Add typless client side GetIndexRequest calls and response class (elastic#38422) [ML] Report index unavailable instead of waiting for lazy node (elastic#38444) await fix CurtIT#testIndex until elastic#38451 is merged (elastic#38466) Update ilm-api.asciidoc, point to REMOVE policy (elastic#38235) (elastic#38464) SQL: Fix esType for DATETIME/DATE and INTERVALS (elastic#38179) Clean up duplicate follow config parameter code (elastic#37688) (elastic#38443) Deprecation check for No Master Block setting (elastic#38383) Bubble-up exceptions from scheduler (elastic#38441) Lift retention lease expiration to index shard (elastic#38391) Deprecate maxRetryTimeout in RestClient and increase default value (elastic#38425) Update Rollup Caps to allow unknown fields (elastic#38446) Backport of elastic#38411: `if_seq_no` and `if_primary_term` parameters aren't wired correctly in REST Client's CRUD API Support unknown fields in ingest pipeline map configuration (elastic#38429) SQL: Implement CURRENT_DATE (elastic#38175) Backport changes to the release notes script. (elastic#38346) Fix ILM explain response to allow unknown fields (elastic#38363) ...
bizybot
pushed a commit
to bizybot/elasticsearch
that referenced
this pull request
Feb 6, 2019
This commit changes the minimum supported version to 6.7.0 for API keys, the change for the API keys has been backported to 6.7.0 version elastic#38399
bizybot
added a commit
that referenced
this pull request
Feb 6, 2019
This commit changes the minimum supported version to 6.7.0 for API keys, the change for the API keys has been backported to 6.7.0 version #38399
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
backport
:Security/Authentication
Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
X-Pack security supports built-in authentication service
token-service
that allows access tokens to be used toaccess Elasticsearch without using Basic authentication.
The tokens are generated by
token-service
based onOAuth2 spec. The access token is a short-lived token
(defaults to 20m) and refresh token with a lifetime of 24 hours,
making them unsuitable for long-lived or recurring tasks where
the system might go offline thereby failing refresh of tokens.
This commit introduces a built-in authentication service
api-key-service
that adds support for long-lived tokens aka APIkeys to access Elasticsearch. The
api-key-service
is consultedafter
token-service
in the authentication chain. By default,if TLS is enabled then
api-key-service
is also enabled.The service can be disabled using the configuration setting.
The API keys:-
configured where the API keys need to be expired after a
certain amount of time.
generated them.
Elasticsearch and will be limited by the role of the user that
generated them
before being deleted. The expired API keys remover task handles this.
Following are the API key management APIs:-
PUT/POST /_security/api_key
GET /_security/api_key
DELETE /_security/api_key
The API keys can be used to access Elasticsearch using
Authorization
header, where the auth scheme is
ApiKey
and the credentials, is thebase64 encoding of API key Id and API key separated by a colon.
Example:-
Closes #34383