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

Add support for API keys to access Elasticsearch (#38291) #38399

Merged
merged 5 commits into from
Feb 6, 2019

Conversation

bizybot
Copy link
Contributor

@bizybot bizybot commented Feb 5, 2019

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 #34383

@bizybot bizybot added :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) backport labels Feb 5, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@bizybot
Copy link
Contributor Author

bizybot commented Feb 5, 2019

@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
Copy link
Contributor Author

bizybot commented Feb 5, 2019

@elasticmachine run elasticsearch-ci/2

@jaymode
Copy link
Member

jaymode commented Feb 5, 2019

@elasticmachine run elasticsearch-ci/2

@jaymode
Copy link
Member

jaymode commented Feb 5, 2019

@elasticmachine run elasticsearch-ci/1

@bizybot bizybot merged commit 7b743a0 into elastic:6.x Feb 6, 2019
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)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants