etcd/auth/simple_token.go

248 lines
5.9 KiB
Go
Raw Normal View History

2016-05-13 06:51:14 +03:00
// Copyright 2016 The etcd Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package auth
// CAUTION: This random number based token mechanism is only for testing purpose.
// JWT based mechanism will be added in the near future.
import (
"context"
"crypto/rand"
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
"fmt"
"math/big"
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
"strconv"
auth, etcdserver: introduce revision of authStore for avoiding TOCTOU problem This commit introduces revision of authStore. The revision number represents a version of authStore that is incremented by updating auth related information. The revision is required for avoiding TOCTOU problems. Currently there are two types of the TOCTOU problems in v3 auth. The first one is in ordinal linearizable requests with a sequence like below (): 1. Request from client CA is processed in follower FA. FA looks up the username (let it U) for the request from a token of the request. At this time, the request is authorized correctly. 2. Another request from client CB is processed in follower FB. CB is for changing U's password. 3. FB forwards the request from CB to the leader before FA. Now U's password is updated and the request from CA should be rejected. 4. However, the request from CA is processed by the leader because authentication is already done in FA. For avoiding the above sequence, this commit lets etcdserverpb.RequestHeader have a member revision. The member is initialized during authentication by followers and checked in a leader. If the revision in RequestHeader is lower than the leader's authStore revision, it means a sequence like above happened. In such a case, the state machine returns auth.ErrAuthRevisionObsolete. The error code lets nodes retry their requests. The second one, a case of serializable range and txn, is more subtle. Because these requests are processed in follower directly. The TOCTOU problem can be caused by a sequence like below: 1. Serializable request from client CA is processed in follower FA. At first, FA looks up the username (let it U) and its permission before actual access to KV. 2. Another request from client CB is processed in follower FB and forwarded to the leader. The cluster including FA now commits a log entry of the request from CB. Assume the request changed the permission or password of U. 3. Now the serializable request from CA is accessing to KV. Even if the access is allowed at the point of 1, now it can be invalid because of the change introduced in 2. For avoiding the above sequence, this commit lets the functions of serializable requests (EtcdServer.Range() and EtcdServer.Txn()) compare the revision in the request header with the latest revision of authStore after the actual access. If the saved revision is lower than the latest one, it means the permission can be changed. Although it would introduce false positives (e.g. changing other user's password), it prevents the TOCTOU problem. This idea is an implementation of Anthony's comment: https://github.com/coreos/etcd/pull/5739#issuecomment-228128254
2016-06-23 12:31:12 +03:00
"strings"
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
"sync"
"time"
"go.uber.org/zap"
)
const (
letters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
defaultSimpleTokenLength = 16
)
// var for testing purposes
// TODO: Remove this mutable global state - as it's race-prone.
var (
simpleTokenTTLDefault = 300 * time.Second
simpleTokenTTLResolution = 1 * time.Second
)
type simpleTokenTTLKeeper struct {
tokens map[string]time.Time
donec chan struct{}
stopc chan struct{}
deleteTokenFunc func(string)
mu *sync.Mutex
simpleTokenTTL time.Duration
}
func (tm *simpleTokenTTLKeeper) stop() {
select {
case tm.stopc <- struct{}{}:
case <-tm.donec:
}
<-tm.donec
}
func (tm *simpleTokenTTLKeeper) addSimpleToken(token string) {
tm.tokens[token] = time.Now().Add(tm.simpleTokenTTL)
}
func (tm *simpleTokenTTLKeeper) resetSimpleToken(token string) {
if _, ok := tm.tokens[token]; ok {
tm.tokens[token] = time.Now().Add(tm.simpleTokenTTL)
}
}
func (tm *simpleTokenTTLKeeper) deleteSimpleToken(token string) {
delete(tm.tokens, token)
}
func (tm *simpleTokenTTLKeeper) run() {
tokenTicker := time.NewTicker(simpleTokenTTLResolution)
defer func() {
tokenTicker.Stop()
close(tm.donec)
}()
for {
select {
case <-tokenTicker.C:
nowtime := time.Now()
tm.mu.Lock()
for t, tokenendtime := range tm.tokens {
if nowtime.After(tokenendtime) {
tm.deleteTokenFunc(t)
delete(tm.tokens, t)
}
}
tm.mu.Unlock()
case <-tm.stopc:
return
}
}
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
type tokenSimple struct {
lg *zap.Logger
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
indexWaiter func(uint64) <-chan struct{}
simpleTokenKeeper *simpleTokenTTLKeeper
simpleTokensMu sync.Mutex
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
simpleTokens map[string]string // token -> username
simpleTokenTTL time.Duration
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
}
func (t *tokenSimple) genTokenPrefix() (string, error) {
ret := make([]byte, defaultSimpleTokenLength)
for i := 0; i < defaultSimpleTokenLength; i++ {
bInt, err := rand.Int(rand.Reader, big.NewInt(int64(len(letters))))
if err != nil {
return "", err
}
ret[i] = letters[bInt.Int64()]
}
return string(ret), nil
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
func (t *tokenSimple) assignSimpleTokenToUser(username, token string) {
t.simpleTokensMu.Lock()
defer t.simpleTokensMu.Unlock()
if t.simpleTokenKeeper == nil {
return
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
_, ok := t.simpleTokens[token]
if ok {
2020-02-06 23:28:14 +03:00
t.lg.Panic(
"failed to assign already-used simple token to a user",
zap.String("user-name", username),
zap.String("token", token),
)
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
t.simpleTokens[token] = username
t.simpleTokenKeeper.addSimpleToken(token)
}
auth, etcdserver: introduce revision of authStore for avoiding TOCTOU problem This commit introduces revision of authStore. The revision number represents a version of authStore that is incremented by updating auth related information. The revision is required for avoiding TOCTOU problems. Currently there are two types of the TOCTOU problems in v3 auth. The first one is in ordinal linearizable requests with a sequence like below (): 1. Request from client CA is processed in follower FA. FA looks up the username (let it U) for the request from a token of the request. At this time, the request is authorized correctly. 2. Another request from client CB is processed in follower FB. CB is for changing U's password. 3. FB forwards the request from CB to the leader before FA. Now U's password is updated and the request from CA should be rejected. 4. However, the request from CA is processed by the leader because authentication is already done in FA. For avoiding the above sequence, this commit lets etcdserverpb.RequestHeader have a member revision. The member is initialized during authentication by followers and checked in a leader. If the revision in RequestHeader is lower than the leader's authStore revision, it means a sequence like above happened. In such a case, the state machine returns auth.ErrAuthRevisionObsolete. The error code lets nodes retry their requests. The second one, a case of serializable range and txn, is more subtle. Because these requests are processed in follower directly. The TOCTOU problem can be caused by a sequence like below: 1. Serializable request from client CA is processed in follower FA. At first, FA looks up the username (let it U) and its permission before actual access to KV. 2. Another request from client CB is processed in follower FB and forwarded to the leader. The cluster including FA now commits a log entry of the request from CB. Assume the request changed the permission or password of U. 3. Now the serializable request from CA is accessing to KV. Even if the access is allowed at the point of 1, now it can be invalid because of the change introduced in 2. For avoiding the above sequence, this commit lets the functions of serializable requests (EtcdServer.Range() and EtcdServer.Txn()) compare the revision in the request header with the latest revision of authStore after the actual access. If the saved revision is lower than the latest one, it means the permission can be changed. Although it would introduce false positives (e.g. changing other user's password), it prevents the TOCTOU problem. This idea is an implementation of Anthony's comment: https://github.com/coreos/etcd/pull/5739#issuecomment-228128254
2016-06-23 12:31:12 +03:00
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
func (t *tokenSimple) invalidateUser(username string) {
if t.simpleTokenKeeper == nil {
return
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
t.simpleTokensMu.Lock()
for token, name := range t.simpleTokens {
if name == username {
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
delete(t.simpleTokens, token)
t.simpleTokenKeeper.deleteSimpleToken(token)
auth, etcdserver: introduce revision of authStore for avoiding TOCTOU problem This commit introduces revision of authStore. The revision number represents a version of authStore that is incremented by updating auth related information. The revision is required for avoiding TOCTOU problems. Currently there are two types of the TOCTOU problems in v3 auth. The first one is in ordinal linearizable requests with a sequence like below (): 1. Request from client CA is processed in follower FA. FA looks up the username (let it U) for the request from a token of the request. At this time, the request is authorized correctly. 2. Another request from client CB is processed in follower FB. CB is for changing U's password. 3. FB forwards the request from CB to the leader before FA. Now U's password is updated and the request from CA should be rejected. 4. However, the request from CA is processed by the leader because authentication is already done in FA. For avoiding the above sequence, this commit lets etcdserverpb.RequestHeader have a member revision. The member is initialized during authentication by followers and checked in a leader. If the revision in RequestHeader is lower than the leader's authStore revision, it means a sequence like above happened. In such a case, the state machine returns auth.ErrAuthRevisionObsolete. The error code lets nodes retry their requests. The second one, a case of serializable range and txn, is more subtle. Because these requests are processed in follower directly. The TOCTOU problem can be caused by a sequence like below: 1. Serializable request from client CA is processed in follower FA. At first, FA looks up the username (let it U) and its permission before actual access to KV. 2. Another request from client CB is processed in follower FB and forwarded to the leader. The cluster including FA now commits a log entry of the request from CB. Assume the request changed the permission or password of U. 3. Now the serializable request from CA is accessing to KV. Even if the access is allowed at the point of 1, now it can be invalid because of the change introduced in 2. For avoiding the above sequence, this commit lets the functions of serializable requests (EtcdServer.Range() and EtcdServer.Txn()) compare the revision in the request header with the latest revision of authStore after the actual access. If the saved revision is lower than the latest one, it means the permission can be changed. Although it would introduce false positives (e.g. changing other user's password), it prevents the TOCTOU problem. This idea is an implementation of Anthony's comment: https://github.com/coreos/etcd/pull/5739#issuecomment-228128254
2016-06-23 12:31:12 +03:00
}
}
t.simpleTokensMu.Unlock()
auth, etcdserver: introduce revision of authStore for avoiding TOCTOU problem This commit introduces revision of authStore. The revision number represents a version of authStore that is incremented by updating auth related information. The revision is required for avoiding TOCTOU problems. Currently there are two types of the TOCTOU problems in v3 auth. The first one is in ordinal linearizable requests with a sequence like below (): 1. Request from client CA is processed in follower FA. FA looks up the username (let it U) for the request from a token of the request. At this time, the request is authorized correctly. 2. Another request from client CB is processed in follower FB. CB is for changing U's password. 3. FB forwards the request from CB to the leader before FA. Now U's password is updated and the request from CA should be rejected. 4. However, the request from CA is processed by the leader because authentication is already done in FA. For avoiding the above sequence, this commit lets etcdserverpb.RequestHeader have a member revision. The member is initialized during authentication by followers and checked in a leader. If the revision in RequestHeader is lower than the leader's authStore revision, it means a sequence like above happened. In such a case, the state machine returns auth.ErrAuthRevisionObsolete. The error code lets nodes retry their requests. The second one, a case of serializable range and txn, is more subtle. Because these requests are processed in follower directly. The TOCTOU problem can be caused by a sequence like below: 1. Serializable request from client CA is processed in follower FA. At first, FA looks up the username (let it U) and its permission before actual access to KV. 2. Another request from client CB is processed in follower FB and forwarded to the leader. The cluster including FA now commits a log entry of the request from CB. Assume the request changed the permission or password of U. 3. Now the serializable request from CA is accessing to KV. Even if the access is allowed at the point of 1, now it can be invalid because of the change introduced in 2. For avoiding the above sequence, this commit lets the functions of serializable requests (EtcdServer.Range() and EtcdServer.Txn()) compare the revision in the request header with the latest revision of authStore after the actual access. If the saved revision is lower than the latest one, it means the permission can be changed. Although it would introduce false positives (e.g. changing other user's password), it prevents the TOCTOU problem. This idea is an implementation of Anthony's comment: https://github.com/coreos/etcd/pull/5739#issuecomment-228128254
2016-06-23 12:31:12 +03:00
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
func (t *tokenSimple) enable() {
if t.simpleTokenTTL <= 0 {
t.simpleTokenTTL = simpleTokenTTLDefault
}
delf := func(tk string) {
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
if username, ok := t.simpleTokens[tk]; ok {
2020-02-06 23:28:14 +03:00
t.lg.Info(
"deleted a simple token",
zap.String("user-name", username),
zap.String("token", tk),
)
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
delete(t.simpleTokens, tk)
}
}
t.simpleTokenKeeper = &simpleTokenTTLKeeper{
tokens: make(map[string]time.Time),
donec: make(chan struct{}),
stopc: make(chan struct{}),
deleteTokenFunc: delf,
mu: &t.simpleTokensMu,
simpleTokenTTL: t.simpleTokenTTL,
}
go t.simpleTokenKeeper.run()
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
}
func (t *tokenSimple) disable() {
t.simpleTokensMu.Lock()
tk := t.simpleTokenKeeper
t.simpleTokenKeeper = nil
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
t.simpleTokens = make(map[string]string) // invalidate all tokens
t.simpleTokensMu.Unlock()
if tk != nil {
tk.stop()
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
}
func (t *tokenSimple) info(ctx context.Context, token string, revision uint64) (*AuthInfo, bool) {
if !t.isValidSimpleToken(ctx, token) {
return nil, false
}
t.simpleTokensMu.Lock()
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
username, ok := t.simpleTokens[token]
if ok && t.simpleTokenKeeper != nil {
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
t.simpleTokenKeeper.resetSimpleToken(token)
}
t.simpleTokensMu.Unlock()
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
return &AuthInfo{Username: username, Revision: revision}, ok
}
func (t *tokenSimple) assign(ctx context.Context, username string, rev uint64) (string, error) {
// rev isn't used in simple token, it is only used in JWT
index := ctx.Value(AuthenticateParamIndex{}).(uint64)
simpleTokenPrefix := ctx.Value(AuthenticateParamSimpleTokenPrefix{}).(string)
token := fmt.Sprintf("%s.%d", simpleTokenPrefix, index)
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
t.assignSimpleTokenToUser(username, token)
return token, nil
}
func (t *tokenSimple) isValidSimpleToken(ctx context.Context, token string) bool {
splitted := strings.Split(token, ".")
if len(splitted) != 2 {
return false
}
index, err := strconv.ParseUint(splitted[1], 10, 0)
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
if err != nil {
return false
}
select {
case <-t.indexWaiter(uint64(index)):
return true
case <-ctx.Done():
}
return false
}
func newTokenProviderSimple(lg *zap.Logger, indexWaiter func(uint64) <-chan struct{}, TokenTTL time.Duration) *tokenSimple {
2020-02-06 23:28:14 +03:00
if lg == nil {
lg = zap.NewNop()
}
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
return &tokenSimple{
lg: lg,
simpleTokens: make(map[string]string),
indexWaiter: indexWaiter,
simpleTokenTTL: TokenTTL,
*: support jwt token in v3 auth API This commit adds jwt token support in v3 auth API. Remaining major ToDos: - Currently token type isn't hidden from etcdserver. In the near future the information should be completely invisible from etcdserver package. - Configurable expiration of token. Currently tokens can be valid until keys are changed. How to use: 1. generate keys for signing and verfying jwt tokens: $ openssl genrsa -out app.rsa 1024 $ openssl rsa -in app.rsa -pubout > app.rsa.pub 2. add command line options to etcd like below: --auth-token-type jwt \ --auth-jwt-pub-key app.rsa.pub --auth-jwt-priv-key app.rsa \ --auth-jwt-sign-method RS512 3. launch etcd cluster Below is a performance comparison of serializable read w/ and w/o jwt token. Every (3) etcd node is executed on a single machine. Signing method is RS512 and key length is 1024 bit. As the results show, jwt based token introduces a performance overhead but it would be acceptable for a case that requires authentication. w/o jwt token auth (no auth): Summary: Total: 1.6172 secs. Slowest: 0.0125 secs. Fastest: 0.0001 secs. Average: 0.0002 secs. Stddev: 0.0004 secs. Requests/sec: 6183.5877 Response time histogram: 0.000 [1] | 0.001 [9982] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.003 [1] | 0.004 [1] | 0.005 [0] | 0.006 [0] | 0.008 [6] | 0.009 [0] | 0.010 [1] | 0.011 [5] | 0.013 [3] | Latency distribution: 10% in 0.0001 secs. 25% in 0.0001 secs. 50% in 0.0001 secs. 75% in 0.0001 secs. 90% in 0.0002 secs. 95% in 0.0002 secs. 99% in 0.0003 secs. w/ jwt token auth: Summary: Total: 2.5364 secs. Slowest: 0.0182 secs. Fastest: 0.0002 secs. Average: 0.0003 secs. Stddev: 0.0005 secs. Requests/sec: 3942.5185 Response time histogram: 0.000 [1] | 0.002 [9975] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.004 [0] | 0.006 [1] | 0.007 [11] | 0.009 [2] | 0.011 [4] | 0.013 [5] | 0.015 [0] | 0.016 [0] | 0.018 [1] | Latency distribution: 10% in 0.0002 secs. 25% in 0.0002 secs. 50% in 0.0002 secs. 75% in 0.0002 secs. 90% in 0.0003 secs. 95% in 0.0003 secs. 99% in 0.0004 secs.
2016-07-21 08:13:57 +03:00
}
}