etcd/auth/store.go

1416 lines
35 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
import (
"bytes"
"context"
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
"encoding/binary"
"errors"
"sort"
"strings"
"sync"
"sync/atomic"
"go.etcd.io/etcd/auth/authpb"
"go.etcd.io/etcd/etcdserver/api/v3rpc/rpctypes"
pb "go.etcd.io/etcd/etcdserver/etcdserverpb"
"go.etcd.io/etcd/mvcc/backend"
2016-03-23 03:10:28 +03:00
"github.com/coreos/pkg/capnslog"
"go.uber.org/zap"
"golang.org/x/crypto/bcrypt"
"google.golang.org/grpc/credentials"
"google.golang.org/grpc/metadata"
"google.golang.org/grpc/peer"
)
var (
2016-04-01 05:07:43 +03:00
enableFlagKey = []byte("authEnabled")
2016-06-10 19:37:37 +03:00
authEnabled = []byte{1}
authDisabled = []byte{0}
2016-04-01 05:07:43 +03:00
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
revisionKey = []byte("authRevision")
authBucketName = []byte("auth")
authUsersBucketName = []byte("authUsers")
2016-04-01 05:07:43 +03:00
authRolesBucketName = []byte("authRoles")
plog = capnslog.NewPackageLogger("go.etcd.io/etcd", "auth")
2016-06-08 07:44:54 +03:00
ErrRootUserNotExist = errors.New("auth: root user does not exist")
ErrRootRoleNotExist = errors.New("auth: root user does not have root role")
ErrUserAlreadyExist = errors.New("auth: user already exists")
ErrUserEmpty = errors.New("auth: user name is empty")
ErrUserNotFound = errors.New("auth: user not found")
ErrRoleAlreadyExist = errors.New("auth: role already exists")
ErrRoleNotFound = errors.New("auth: role not found")
ErrAuthFailed = errors.New("auth: authentication failed, invalid user ID or password")
ErrPermissionDenied = errors.New("auth: permission denied")
ErrRoleNotGranted = errors.New("auth: role is not granted to the user")
ErrPermissionNotGranted = errors.New("auth: permission is not granted to the role")
ErrAuthNotEnabled = errors.New("auth: authentication is not enabled")
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
ErrAuthOldRevision = errors.New("auth: revision in header is old")
ErrInvalidAuthToken = errors.New("auth: invalid auth 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
ErrInvalidAuthOpts = errors.New("auth: invalid auth options")
ErrInvalidAuthMgmt = errors.New("auth: invalid auth management")
ErrInvalidAuthMethod = errors.New("auth: invalid auth signature method")
ErrMissingKey = errors.New("auth: missing key data")
ErrKeyMismatch = errors.New("auth: public and private keys don't match")
ErrVerifyOnly = errors.New("auth: token signing attempted with verify-only key")
)
2016-06-08 07:44:54 +03:00
const (
rootUser = "root"
rootRole = "root"
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
tokenTypeSimple = "simple"
tokenTypeJWT = "jwt"
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
revBytesLen = 8
2016-06-08 07:44:54 +03:00
)
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
type AuthInfo struct {
Username string
Revision uint64
}
// AuthenticateParamIndex is used for a key of context in the parameters of Authenticate()
type AuthenticateParamIndex struct{}
// AuthenticateParamSimpleTokenPrefix is used for a key of context in the parameters of Authenticate()
type AuthenticateParamSimpleTokenPrefix struct{}
// AuthStore defines auth storage interface.
type AuthStore interface {
2016-04-27 19:15:23 +03:00
// AuthEnable turns on the authentication feature
2016-06-08 07:44:54 +03:00
AuthEnable() error
// AuthDisable turns off the authentication feature
AuthDisable()
// IsAuthEnabled returns true if the authentication feature is enabled.
IsAuthEnabled() bool
// Authenticate does authentication based on given user name and password
Authenticate(ctx context.Context, username, password string) (*pb.AuthenticateResponse, error)
// Recover recovers the state of auth store from the given backend
Recover(b backend.Backend)
// UserAdd adds a new user
UserAdd(r *pb.AuthUserAddRequest) (*pb.AuthUserAddResponse, error)
// UserDelete deletes a user
UserDelete(r *pb.AuthUserDeleteRequest) (*pb.AuthUserDeleteResponse, error)
// UserChangePassword changes a password of a user
UserChangePassword(r *pb.AuthUserChangePasswordRequest) (*pb.AuthUserChangePasswordResponse, error)
2016-04-01 05:07:43 +03:00
2016-06-07 06:17:28 +03:00
// UserGrantRole grants a role to the user
UserGrantRole(r *pb.AuthUserGrantRoleRequest) (*pb.AuthUserGrantRoleResponse, error)
// UserGet gets the detailed information of a users
UserGet(r *pb.AuthUserGetRequest) (*pb.AuthUserGetResponse, error)
// UserRevokeRole revokes a role of a user
UserRevokeRole(r *pb.AuthUserRevokeRoleRequest) (*pb.AuthUserRevokeRoleResponse, error)
2016-04-01 05:07:43 +03:00
// RoleAdd adds a new role
RoleAdd(r *pb.AuthRoleAddRequest) (*pb.AuthRoleAddResponse, error)
2016-06-07 06:17:28 +03:00
// RoleGrantPermission grants a permission to a role
RoleGrantPermission(r *pb.AuthRoleGrantPermissionRequest) (*pb.AuthRoleGrantPermissionResponse, error)
// RoleGet gets the detailed information of a role
RoleGet(r *pb.AuthRoleGetRequest) (*pb.AuthRoleGetResponse, error)
// RoleRevokePermission gets the detailed information of a role
RoleRevokePermission(r *pb.AuthRoleRevokePermissionRequest) (*pb.AuthRoleRevokePermissionResponse, error)
// RoleDelete gets the detailed information of a role
RoleDelete(r *pb.AuthRoleDeleteRequest) (*pb.AuthRoleDeleteResponse, error)
// UserList gets a list of all users
UserList(r *pb.AuthUserListRequest) (*pb.AuthUserListResponse, error)
// RoleList gets a list of all roles
RoleList(r *pb.AuthRoleListRequest) (*pb.AuthRoleListResponse, error)
// IsPutPermitted checks put permission of the user
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
IsPutPermitted(authInfo *AuthInfo, key []byte) error
// IsRangePermitted checks range permission of the user
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
IsRangePermitted(authInfo *AuthInfo, key, rangeEnd []byte) error
2016-06-09 23:40:26 +03:00
2016-06-14 03:19:59 +03:00
// IsDeleteRangePermitted checks delete-range permission of the user
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
IsDeleteRangePermitted(authInfo *AuthInfo, key, rangeEnd []byte) error
2016-06-14 03:19:59 +03:00
2016-06-09 23:40:26 +03:00
// IsAdminPermitted checks admin permission of the user
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
IsAdminPermitted(authInfo *AuthInfo) error
*: 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
// GenTokenPrefix produces a random string in a case of simple token
// in a case of JWT, it produces an empty string
GenTokenPrefix() (string, error)
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
// Revision gets current revision of authStore
Revision() uint64
// CheckPassword checks a given pair of username and password is correct
CheckPassword(username, password string) (uint64, error)
// Close does cleanup of AuthStore
Close() error
// AuthInfoFromCtx gets AuthInfo from gRPC's context
AuthInfoFromCtx(ctx context.Context) (*AuthInfo, error)
// AuthInfoFromTLS gets AuthInfo from TLS info of gRPC's context
AuthInfoFromTLS(ctx context.Context) *AuthInfo
// WithRoot generates and installs a token that can be used as a root credential
WithRoot(ctx context.Context) context.Context
// HasRole checks that user has role
HasRole(user, role string) bool
}
*: 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 TokenProvider interface {
info(ctx context.Context, token string, revision uint64) (*AuthInfo, bool)
assign(ctx context.Context, username string, revision uint64) (string, error)
enable()
disable()
invalidateUser(string)
genTokenPrefix() (string, error)
}
type authStore struct {
// atomic operations; need 64-bit align, or 32-bit tests will crash
revision uint64
lg *zap.Logger
be backend.Backend
enabled bool
enabledMu sync.RWMutex
rangePermCache map[string]*unifiedRangePermissions // username -> unifiedRangePermissions
*: 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
tokenProvider TokenProvider
2018-05-03 21:43:32 +03:00
bcryptCost int // the algorithm cost / strength for hashing auth passwords
}
2016-06-08 07:44:54 +03:00
func (as *authStore) AuthEnable() error {
as.enabledMu.Lock()
defer as.enabledMu.Unlock()
if as.enabled {
if as.lg != nil {
as.lg.Info("authentication is already enabled; ignored auth enable request")
} else {
plog.Noticef("Authentication already enabled")
}
return nil
}
b := as.be
tx := b.BatchTx()
tx.Lock()
2016-06-08 07:44:54 +03:00
defer func() {
tx.Unlock()
b.ForceCommit()
}()
u := getUser(as.lg, tx, rootUser)
2016-06-08 07:44:54 +03:00
if u == nil {
return ErrRootUserNotExist
}
2016-06-09 23:40:26 +03:00
if !hasRootRole(u) {
2016-06-08 07:44:54 +03:00
return ErrRootRoleNotExist
}
2016-06-10 19:37:37 +03:00
tx.UnsafePut(authBucketName, enableFlagKey, authEnabled)
as.enabled = true
*: 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
as.tokenProvider.enable()
as.rangePermCache = make(map[string]*unifiedRangePermissions)
as.setRevision(getRevision(tx))
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
if as.lg != nil {
as.lg.Info("enabled authentication")
} else {
plog.Noticef("Authentication enabled")
}
2016-06-08 07:44:54 +03:00
return nil
}
func (as *authStore) AuthDisable() {
as.enabledMu.Lock()
defer as.enabledMu.Unlock()
if !as.enabled {
return
}
b := as.be
tx := b.BatchTx()
tx.Lock()
2016-06-10 19:37:37 +03:00
tx.UnsafePut(authBucketName, enableFlagKey, authDisabled)
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
as.commitRevision(tx)
tx.Unlock()
b.ForceCommit()
as.enabled = false
*: 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
as.tokenProvider.disable()
if as.lg != nil {
as.lg.Info("disabled authentication")
} else {
plog.Noticef("Authentication disabled")
}
}
func (as *authStore) Close() error {
as.enabledMu.Lock()
defer as.enabledMu.Unlock()
if !as.enabled {
return 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
as.tokenProvider.disable()
return nil
}
func (as *authStore) Authenticate(ctx context.Context, username, password string) (*pb.AuthenticateResponse, error) {
if !as.IsAuthEnabled() {
return nil, ErrAuthNotEnabled
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, username)
if user == nil {
return nil, ErrAuthFailed
}
if user.Options.NoPassword {
return nil, ErrAuthFailed
}
*: 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
// Password checking is already performed in the API layer, so we don't need to check for now.
// Staleness of password can be detected with OCC in the API layer, too.
token, err := as.tokenProvider.assign(ctx, username, as.Revision())
*: 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 nil, err
}
if as.lg != nil {
as.lg.Debug(
"authenticated a user",
zap.String("user-name", username),
zap.String("token", token),
)
} else {
plog.Debugf("authorized %s, token is %s", username, token)
}
return &pb.AuthenticateResponse{Token: token}, nil
}
func (as *authStore) CheckPassword(username, password string) (uint64, error) {
if !as.IsAuthEnabled() {
return 0, ErrAuthNotEnabled
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, username)
if user == nil {
return 0, ErrAuthFailed
}
if user.Options.NoPassword {
return 0, ErrAuthFailed
}
if bcrypt.CompareHashAndPassword(user.Password, []byte(password)) != nil {
if as.lg != nil {
as.lg.Info("invalid password", zap.String("user-name", username))
} else {
plog.Noticef("authentication failed, invalid password for user %s", username)
}
return 0, ErrAuthFailed
}
return getRevision(tx), nil
}
func (as *authStore) Recover(be backend.Backend) {
2016-06-10 19:37:37 +03:00
enabled := false
as.be = be
2016-06-10 19:37:37 +03:00
tx := be.BatchTx()
tx.Lock()
_, vs := tx.UnsafeRange(authBucketName, enableFlagKey, nil, 0)
if len(vs) == 1 {
if bytes.Equal(vs[0], authEnabled) {
enabled = true
}
}
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
as.setRevision(getRevision(tx))
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
2016-06-10 19:37:37 +03:00
tx.Unlock()
as.enabledMu.Lock()
as.enabled = enabled
as.enabledMu.Unlock()
}
func (as *authStore) UserAdd(r *pb.AuthUserAddRequest) (*pb.AuthUserAddResponse, error) {
if len(r.Name) == 0 {
return nil, ErrUserEmpty
}
var hashed []byte
var err error
if !r.Options.NoPassword {
hashed, err = bcrypt.GenerateFromPassword([]byte(r.Password), as.bcryptCost)
if err != nil {
if as.lg != nil {
as.lg.Warn(
"failed to bcrypt hash password",
zap.String("user-name", r.Name),
zap.Error(err),
)
} else {
plog.Errorf("failed to hash password: %s", err)
}
return nil, err
}
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, r.Name)
2016-06-08 08:42:39 +03:00
if user != nil {
return nil, ErrUserAlreadyExist
}
options := r.Options
if options == nil {
options = &authpb.UserAddOptions{
NoPassword: false,
}
}
2016-06-10 21:27:42 +03:00
newUser := &authpb.User{
Name: []byte(r.Name),
Password: hashed,
Options: options,
}
putUser(as.lg, tx, newUser)
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
as.commitRevision(tx)
if as.lg != nil {
as.lg.Info("added a user", zap.String("user-name", r.Name))
} else {
plog.Noticef("added a new user: %s", r.Name)
}
return &pb.AuthUserAddResponse{}, nil
}
func (as *authStore) UserDelete(r *pb.AuthUserDeleteRequest) (*pb.AuthUserDeleteResponse, error) {
if as.enabled && r.Name == rootUser {
if as.lg != nil {
as.lg.Warn("cannot delete 'root' user", zap.String("user-name", r.Name))
} else {
plog.Errorf("the user root must not be deleted")
}
return nil, ErrInvalidAuthMgmt
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, r.Name)
2016-06-08 08:42:39 +03:00
if user == nil {
return nil, ErrUserNotFound
}
2016-06-11 00:11:00 +03:00
delUser(tx, r.Name)
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
as.commitRevision(tx)
as.invalidateCachedPerm(r.Name)
*: 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
as.tokenProvider.invalidateUser(r.Name)
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
if as.lg != nil {
as.lg.Info(
"deleted a user",
zap.String("user-name", r.Name),
zap.Strings("user-roles", user.Roles),
)
} else {
plog.Noticef("deleted a user: %s", r.Name)
}
return &pb.AuthUserDeleteResponse{}, nil
}
func (as *authStore) UserChangePassword(r *pb.AuthUserChangePasswordRequest) (*pb.AuthUserChangePasswordResponse, error) {
// TODO(mitake): measure the cost of bcrypt.GenerateFromPassword()
// If the cost is too high, we should move the encryption to outside of the raft
2018-05-03 21:43:32 +03:00
hashed, err := bcrypt.GenerateFromPassword([]byte(r.Password), as.bcryptCost)
if err != nil {
if as.lg != nil {
as.lg.Warn(
"failed to bcrypt hash password",
zap.String("user-name", r.Name),
zap.Error(err),
)
} else {
plog.Errorf("failed to hash password: %s", err)
}
return nil, err
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, r.Name)
2016-06-08 08:42:39 +03:00
if user == nil {
return nil, ErrUserNotFound
}
2016-06-10 21:27:42 +03:00
updatedUser := &authpb.User{
Name: []byte(r.Name),
2016-06-10 21:27:42 +03:00
Roles: user.Roles,
Password: hashed,
Options: user.Options,
}
putUser(as.lg, tx, updatedUser)
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
as.commitRevision(tx)
as.invalidateCachedPerm(r.Name)
*: 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
as.tokenProvider.invalidateUser(r.Name)
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
if as.lg != nil {
as.lg.Info(
"changed a password of a user",
zap.String("user-name", r.Name),
zap.Strings("user-roles", user.Roles),
)
} else {
plog.Noticef("changed a password of a user: %s", r.Name)
}
return &pb.AuthUserChangePasswordResponse{}, nil
}
2016-06-07 06:17:28 +03:00
func (as *authStore) UserGrantRole(r *pb.AuthUserGrantRoleRequest) (*pb.AuthUserGrantRoleResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, r.User)
2016-06-08 08:42:39 +03:00
if user == nil {
return nil, ErrUserNotFound
}
2016-06-08 07:44:54 +03:00
if r.Role != rootRole {
role := getRole(tx, r.Role)
if role == nil {
2016-06-08 07:44:54 +03:00
return nil, ErrRoleNotFound
}
}
idx := sort.SearchStrings(user.Roles, r.Role)
if idx < len(user.Roles) && user.Roles[idx] == r.Role {
if as.lg != nil {
as.lg.Warn(
"ignored grant role request to a user",
zap.String("user-name", r.User),
zap.Strings("user-roles", user.Roles),
zap.String("duplicate-role-name", r.Role),
)
} else {
plog.Warningf("user %s is already granted role %s", r.User, r.Role)
}
2016-06-07 06:17:28 +03:00
return &pb.AuthUserGrantRoleResponse{}, nil
}
user.Roles = append(user.Roles, r.Role)
sort.Strings(user.Roles)
putUser(as.lg, tx, user)
as.invalidateCachedPerm(r.User)
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
as.commitRevision(tx)
if as.lg != nil {
as.lg.Info(
"granted a role to a user",
zap.String("user-name", r.User),
zap.Strings("user-roles", user.Roles),
zap.String("added-role-name", r.Role),
)
} else {
plog.Noticef("granted role %s to user %s", r.Role, r.User)
}
2016-06-07 06:17:28 +03:00
return &pb.AuthUserGrantRoleResponse{}, nil
}
func (as *authStore) UserGet(r *pb.AuthUserGetRequest) (*pb.AuthUserGetResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
user := getUser(as.lg, tx, r.Name)
tx.Unlock()
2016-06-08 08:42:39 +03:00
if user == nil {
return nil, ErrUserNotFound
}
var resp pb.AuthUserGetResponse
2016-12-09 23:05:19 +03:00
resp.Roles = append(resp.Roles, user.Roles...)
return &resp, nil
}
func (as *authStore) UserList(r *pb.AuthUserListRequest) (*pb.AuthUserListResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
users := getAllUsers(as.lg, tx)
tx.Unlock()
resp := &pb.AuthUserListResponse{Users: make([]string, len(users))}
for i := range users {
resp.Users[i] = string(users[i].Name)
}
return resp, nil
}
func (as *authStore) UserRevokeRole(r *pb.AuthUserRevokeRoleRequest) (*pb.AuthUserRevokeRoleResponse, error) {
if as.enabled && r.Name == rootUser && r.Role == rootRole {
if as.lg != nil {
as.lg.Warn(
"'root' user cannot revoke 'root' role",
zap.String("user-name", r.Name),
zap.String("role-name", r.Role),
)
} else {
plog.Errorf("the role root must not be revoked from the user root")
}
return nil, ErrInvalidAuthMgmt
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, r.Name)
2016-06-08 08:42:39 +03:00
if user == nil {
return nil, ErrUserNotFound
}
2016-06-11 00:19:29 +03:00
updatedUser := &authpb.User{
Name: user.Name,
Password: user.Password,
Options: user.Options,
2016-06-11 00:19:29 +03:00
}
for _, role := range user.Roles {
if role != r.Role {
updatedUser.Roles = append(updatedUser.Roles, role)
}
}
2016-06-11 00:19:29 +03:00
if len(updatedUser.Roles) == len(user.Roles) {
return nil, ErrRoleNotGranted
}
putUser(as.lg, tx, updatedUser)
as.invalidateCachedPerm(r.Name)
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
as.commitRevision(tx)
if as.lg != nil {
as.lg.Info(
"revoked a role from a user",
zap.String("user-name", r.Name),
zap.Strings("old-user-roles", user.Roles),
zap.Strings("new-user-roles", updatedUser.Roles),
zap.String("revoked-role-name", r.Role),
)
} else {
plog.Noticef("revoked role %s from user %s", r.Role, r.Name)
}
return &pb.AuthUserRevokeRoleResponse{}, nil
}
func (as *authStore) RoleGet(r *pb.AuthRoleGetRequest) (*pb.AuthRoleGetResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
var resp pb.AuthRoleGetResponse
2016-06-10 20:59:34 +03:00
role := getRole(tx, r.Role)
if role == nil {
return nil, ErrRoleNotFound
}
2016-12-09 23:05:19 +03:00
resp.Perm = append(resp.Perm, role.KeyPermission...)
return &resp, nil
}
func (as *authStore) RoleList(r *pb.AuthRoleListRequest) (*pb.AuthRoleListResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
roles := getAllRoles(as.lg, tx)
tx.Unlock()
resp := &pb.AuthRoleListResponse{Roles: make([]string, len(roles))}
for i := range roles {
resp.Roles[i] = string(roles[i].Name)
}
return resp, nil
}
func (as *authStore) RoleRevokePermission(r *pb.AuthRoleRevokePermissionRequest) (*pb.AuthRoleRevokePermissionResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
2016-06-10 20:59:34 +03:00
role := getRole(tx, r.Role)
if role == nil {
return nil, ErrRoleNotFound
}
2016-06-11 00:19:29 +03:00
updatedRole := &authpb.Role{
Name: role.Name,
}
for _, perm := range role.KeyPermission {
if !bytes.Equal(perm.Key, r.Key) || !bytes.Equal(perm.RangeEnd, r.RangeEnd) {
updatedRole.KeyPermission = append(updatedRole.KeyPermission, perm)
}
}
2016-06-11 00:19:29 +03:00
if len(role.KeyPermission) == len(updatedRole.KeyPermission) {
return nil, ErrPermissionNotGranted
}
putRole(as.lg, tx, updatedRole)
// TODO(mitake): currently single role update invalidates every cache
// It should be optimized.
as.clearCachedPerm()
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
as.commitRevision(tx)
if as.lg != nil {
as.lg.Info(
"revoked a permission on range",
zap.String("role-name", r.Role),
zap.String("key", string(r.Key)),
zap.String("range-end", string(r.RangeEnd)),
)
} else {
plog.Noticef("revoked key %s from role %s", r.Key, r.Role)
}
return &pb.AuthRoleRevokePermissionResponse{}, nil
}
func (as *authStore) RoleDelete(r *pb.AuthRoleDeleteRequest) (*pb.AuthRoleDeleteResponse, error) {
if as.enabled && r.Role == rootRole {
if as.lg != nil {
as.lg.Warn("cannot delete 'root' role", zap.String("role-name", r.Role))
} else {
plog.Errorf("the role root must not be deleted")
}
return nil, ErrInvalidAuthMgmt
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
2016-06-10 20:59:34 +03:00
role := getRole(tx, r.Role)
if role == nil {
return nil, ErrRoleNotFound
}
2016-06-11 00:11:00 +03:00
delRole(tx, r.Role)
users := getAllUsers(as.lg, tx)
for _, user := range users {
updatedUser := &authpb.User{
Name: user.Name,
Password: user.Password,
Options: user.Options,
}
for _, role := range user.Roles {
if role != r.Role {
updatedUser.Roles = append(updatedUser.Roles, role)
}
}
if len(updatedUser.Roles) == len(user.Roles) {
continue
}
putUser(as.lg, tx, updatedUser)
as.invalidateCachedPerm(string(user.Name))
}
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
as.commitRevision(tx)
if as.lg != nil {
as.lg.Info("deleted a role", zap.String("role-name", r.Role))
} else {
plog.Noticef("deleted role %s", r.Role)
}
return &pb.AuthRoleDeleteResponse{}, nil
}
2016-04-01 05:07:43 +03:00
func (as *authStore) RoleAdd(r *pb.AuthRoleAddRequest) (*pb.AuthRoleAddResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
2016-06-10 20:59:34 +03:00
role := getRole(tx, r.Name)
if role != nil {
2016-04-01 05:07:43 +03:00
return nil, ErrRoleAlreadyExist
}
newRole := &authpb.Role{
Name: []byte(r.Name),
}
putRole(as.lg, tx, newRole)
2016-04-01 05:07:43 +03:00
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
as.commitRevision(tx)
if as.lg != nil {
as.lg.Info("created a role", zap.String("role-name", r.Name))
} else {
plog.Noticef("Role %s is created", r.Name)
}
2016-04-01 05:07:43 +03:00
return &pb.AuthRoleAddResponse{}, 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 (as *authStore) authInfoFromToken(ctx context.Context, token string) (*AuthInfo, bool) {
return as.tokenProvider.info(ctx, token, as.Revision())
}
type permSlice []*authpb.Permission
func (perms permSlice) Len() int {
return len(perms)
}
func (perms permSlice) Less(i, j int) bool {
return bytes.Compare(perms[i].Key, perms[j].Key) < 0
}
func (perms permSlice) Swap(i, j int) {
perms[i], perms[j] = perms[j], perms[i]
}
2016-06-07 06:17:28 +03:00
func (as *authStore) RoleGrantPermission(r *pb.AuthRoleGrantPermissionRequest) (*pb.AuthRoleGrantPermissionResponse, error) {
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
2016-06-10 20:59:34 +03:00
role := getRole(tx, r.Name)
if role == nil {
return nil, ErrRoleNotFound
}
idx := sort.Search(len(role.KeyPermission), func(i int) bool {
return bytes.Compare(role.KeyPermission[i].Key, r.Perm.Key) >= 0
})
if idx < len(role.KeyPermission) && bytes.Equal(role.KeyPermission[idx].Key, r.Perm.Key) && bytes.Equal(role.KeyPermission[idx].RangeEnd, r.Perm.RangeEnd) {
// update existing permission
role.KeyPermission[idx].PermType = r.Perm.PermType
} else {
// append new permission to the role
newPerm := &authpb.Permission{
Key: r.Perm.Key,
RangeEnd: r.Perm.RangeEnd,
PermType: r.Perm.PermType,
}
role.KeyPermission = append(role.KeyPermission, newPerm)
sort.Sort(permSlice(role.KeyPermission))
}
putRole(as.lg, tx, role)
// TODO(mitake): currently single role update invalidates every cache
// It should be optimized.
as.clearCachedPerm()
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
as.commitRevision(tx)
if as.lg != nil {
as.lg.Info(
"granted/updated a permission to a user",
zap.String("user-name", r.Name),
zap.String("permission-name", authpb.Permission_Type_name[int32(r.Perm.PermType)]),
)
} else {
plog.Noticef("role %s's permission of key %s is updated as %s", r.Name, r.Perm.Key, authpb.Permission_Type_name[int32(r.Perm.PermType)])
}
2016-06-07 06:17:28 +03:00
return &pb.AuthRoleGrantPermissionResponse{}, nil
}
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
func (as *authStore) isOpPermitted(userName string, revision uint64, key, rangeEnd []byte, permTyp authpb.Permission_Type) error {
// TODO(mitake): this function would be costly so we need a caching mechanism
if !as.IsAuthEnabled() {
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
return nil
}
// only gets rev == 0 when passed AuthInfo{}; no user given
if revision == 0 {
return ErrUserEmpty
}
if revision < as.Revision() {
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
return ErrAuthOldRevision
}
tx := as.be.BatchTx()
tx.Lock()
defer tx.Unlock()
user := getUser(as.lg, tx, userName)
2016-06-08 08:42:39 +03:00
if user == nil {
if as.lg != nil {
as.lg.Warn("cannot find a user for permission check", zap.String("user-name", userName))
} else {
plog.Errorf("invalid user name %s for permission checking", userName)
}
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
return ErrPermissionDenied
}
// root role should have permission on all ranges
if hasRootRole(user) {
return nil
}
if as.isRangeOpPermitted(tx, userName, key, rangeEnd, permTyp) {
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
return nil
}
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
return ErrPermissionDenied
}
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
func (as *authStore) IsPutPermitted(authInfo *AuthInfo, key []byte) error {
return as.isOpPermitted(authInfo.Username, authInfo.Revision, key, nil, authpb.WRITE)
}
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
func (as *authStore) IsRangePermitted(authInfo *AuthInfo, key, rangeEnd []byte) error {
return as.isOpPermitted(authInfo.Username, authInfo.Revision, key, rangeEnd, authpb.READ)
}
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
func (as *authStore) IsDeleteRangePermitted(authInfo *AuthInfo, key, rangeEnd []byte) error {
return as.isOpPermitted(authInfo.Username, authInfo.Revision, key, rangeEnd, authpb.WRITE)
2016-06-14 03:19:59 +03:00
}
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
func (as *authStore) IsAdminPermitted(authInfo *AuthInfo) error {
if !as.IsAuthEnabled() {
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
return nil
2016-06-09 23:40:26 +03:00
}
if authInfo == nil {
return ErrUserEmpty
}
2016-06-09 23:40:26 +03:00
tx := as.be.BatchTx()
tx.Lock()
u := getUser(as.lg, tx, authInfo.Username)
tx.Unlock()
2016-06-09 23:40:26 +03:00
if u == nil {
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
return ErrUserNotFound
}
if !hasRootRole(u) {
return ErrPermissionDenied
2016-06-09 23:40:26 +03:00
}
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
return nil
2016-06-09 23:40:26 +03:00
}
func getUser(lg *zap.Logger, tx backend.BatchTx, username string) *authpb.User {
2016-06-08 08:42:39 +03:00
_, vs := tx.UnsafeRange(authUsersBucketName, []byte(username), nil, 0)
if len(vs) == 0 {
return nil
}
user := &authpb.User{}
err := user.Unmarshal(vs[0])
if err != nil {
if lg != nil {
lg.Panic(
"failed to unmarshal 'authpb.User'",
zap.String("user-name", username),
zap.Error(err),
)
} else {
plog.Panicf("failed to unmarshal user struct (name: %s): %s", username, err)
}
2016-06-08 08:42:39 +03:00
}
return user
}
func getAllUsers(lg *zap.Logger, tx backend.BatchTx) []*authpb.User {
_, vs := tx.UnsafeRange(authUsersBucketName, []byte{0}, []byte{0xff}, -1)
if len(vs) == 0 {
return nil
}
users := make([]*authpb.User, len(vs))
for i := range vs {
user := &authpb.User{}
err := user.Unmarshal(vs[i])
if err != nil {
if lg != nil {
lg.Panic("failed to unmarshal 'authpb.User'", zap.Error(err))
} else {
plog.Panicf("failed to unmarshal user struct: %s", err)
}
}
users[i] = user
}
return users
}
func putUser(lg *zap.Logger, tx backend.BatchTx, user *authpb.User) {
2016-06-10 21:27:42 +03:00
b, err := user.Marshal()
if err != nil {
if lg != nil {
lg.Panic("failed to unmarshal 'authpb.User'", zap.Error(err))
} else {
plog.Panicf("failed to marshal user struct (name: %s): %s", user.Name, err)
}
2016-06-10 21:27:42 +03:00
}
tx.UnsafePut(authUsersBucketName, user.Name, b)
}
2016-06-11 00:11:00 +03:00
func delUser(tx backend.BatchTx, username string) {
tx.UnsafeDelete(authUsersBucketName, []byte(username))
}
2016-06-10 20:59:34 +03:00
func getRole(tx backend.BatchTx, rolename string) *authpb.Role {
_, vs := tx.UnsafeRange(authRolesBucketName, []byte(rolename), nil, 0)
if len(vs) == 0 {
return nil
}
role := &authpb.Role{}
err := role.Unmarshal(vs[0])
if err != nil {
plog.Panicf("failed to unmarshal role struct (name: %s): %s", rolename, err)
}
return role
}
func getAllRoles(lg *zap.Logger, tx backend.BatchTx) []*authpb.Role {
_, vs := tx.UnsafeRange(authRolesBucketName, []byte{0}, []byte{0xff}, -1)
if len(vs) == 0 {
return nil
}
roles := make([]*authpb.Role, len(vs))
for i := range vs {
role := &authpb.Role{}
err := role.Unmarshal(vs[i])
if err != nil {
if lg != nil {
lg.Panic("failed to unmarshal 'authpb.Role'", zap.Error(err))
} else {
plog.Panicf("failed to unmarshal role struct: %s", err)
}
}
roles[i] = role
}
return roles
}
func putRole(lg *zap.Logger, tx backend.BatchTx, role *authpb.Role) {
2016-06-10 23:20:48 +03:00
b, err := role.Marshal()
if err != nil {
if lg != nil {
lg.Panic(
"failed to marshal 'authpb.Role'",
zap.String("role-name", string(role.Name)),
zap.Error(err),
)
} else {
plog.Panicf("failed to marshal role struct (name: %s): %s", role.Name, err)
}
2016-06-10 23:20:48 +03:00
}
tx.UnsafePut(authRolesBucketName, role.Name, b)
2016-06-10 23:20:48 +03:00
}
2016-06-11 00:11:00 +03:00
func delRole(tx backend.BatchTx, rolename string) {
tx.UnsafeDelete(authRolesBucketName, []byte(rolename))
}
func (as *authStore) IsAuthEnabled() bool {
as.enabledMu.RLock()
defer as.enabledMu.RUnlock()
return as.enabled
}
// NewAuthStore creates a new AuthStore.
2018-05-03 21:43:32 +03:00
func NewAuthStore(lg *zap.Logger, be backend.Backend, tp TokenProvider, bcryptCost int) *authStore {
if bcryptCost < bcrypt.MinCost || bcryptCost > bcrypt.MaxCost {
if lg != nil {
lg.Warn(
"use default bcrypt cost instead of the invalid given cost",
zap.Int("min-cost", bcrypt.MinCost),
zap.Int("max-cost", bcrypt.MaxCost),
zap.Int("default-cost", bcrypt.DefaultCost),
zap.Int("given-cost", bcryptCost))
} else {
plog.Warningf("Use default bcrypt-cost %d instead of the invalid value %d",
bcrypt.DefaultCost, bcryptCost)
}
bcryptCost = bcrypt.DefaultCost
}
tx := be.BatchTx()
tx.Lock()
tx.UnsafeCreateBucket(authBucketName)
tx.UnsafeCreateBucket(authUsersBucketName)
2016-04-01 05:07:43 +03:00
tx.UnsafeCreateBucket(authRolesBucketName)
enabled := false
_, vs := tx.UnsafeRange(authBucketName, enableFlagKey, nil, 0)
if len(vs) == 1 {
if bytes.Equal(vs[0], authEnabled) {
enabled = true
}
}
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
as := &authStore{
revision: getRevision(tx),
lg: lg,
be: be,
enabled: enabled,
rangePermCache: make(map[string]*unifiedRangePermissions),
*: 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
tokenProvider: tp,
2018-05-03 21:43:32 +03:00
bcryptCost: bcryptCost,
}
if enabled {
*: 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
as.tokenProvider.enable()
}
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
if as.Revision() == 0 {
as.commitRevision(tx)
}
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
tx.Unlock()
be.ForceCommit()
return as
}
2016-06-09 23:40:26 +03:00
func hasRootRole(u *authpb.User) bool {
// u.Roles is sorted in UserGrantRole(), so we can use binary search.
idx := sort.SearchStrings(u.Roles, rootRole)
return idx != len(u.Roles) && u.Roles[idx] == rootRole
2016-06-09 23:40:26 +03:00
}
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
func (as *authStore) commitRevision(tx backend.BatchTx) {
atomic.AddUint64(&as.revision, 1)
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
revBytes := make([]byte, revBytesLen)
binary.BigEndian.PutUint64(revBytes, as.Revision())
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
tx.UnsafePut(authBucketName, revisionKey, revBytes)
}
func getRevision(tx backend.BatchTx) uint64 {
_, vs := tx.UnsafeRange(authBucketName, revisionKey, nil, 0)
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
if len(vs) != 1 {
// this can happen in the initialization phase
return 0
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
}
return binary.BigEndian.Uint64(vs[0])
}
func (as *authStore) setRevision(rev uint64) {
atomic.StoreUint64(&as.revision, rev)
}
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
func (as *authStore) Revision() uint64 {
return atomic.LoadUint64(&as.revision)
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
}
func (as *authStore) AuthInfoFromTLS(ctx context.Context) (ai *AuthInfo) {
peer, ok := peer.FromContext(ctx)
if !ok || peer == nil || peer.AuthInfo == nil {
return nil
}
tlsInfo := peer.AuthInfo.(credentials.TLSInfo)
for _, chains := range tlsInfo.State.VerifiedChains {
if len(chains) < 1 {
continue
}
ai = &AuthInfo{
Username: chains[0].Subject.CommonName,
Revision: as.Revision(),
}
md, ok := metadata.FromIncomingContext(ctx)
if !ok {
return nil
}
// gRPC-gateway proxy request to etcd server includes Grpcgateway-Accept
// header. The proxy uses etcd client server certificate. If the certificate
// has a CommonName we should never use this for authentication.
if gw := md["grpcgateway-accept"]; len(gw) > 0 {
if as.lg != nil {
as.lg.Warn(
"ignoring common name in gRPC-gateway proxy request",
zap.String("common-name", ai.Username),
zap.String("user-name", ai.Username),
zap.Uint64("revision", ai.Revision),
)
} else {
plog.Warningf("ignoring common name in gRPC-gateway proxy request %s", ai.Username)
}
return nil
}
if as.lg != nil {
as.lg.Debug(
"found command name",
zap.String("common-name", ai.Username),
zap.String("user-name", ai.Username),
zap.Uint64("revision", ai.Revision),
)
} else {
plog.Debugf("found common name %s", ai.Username)
}
break
}
return ai
}
func (as *authStore) AuthInfoFromCtx(ctx context.Context) (*AuthInfo, error) {
md, ok := metadata.FromIncomingContext(ctx)
if !ok {
return nil, nil
}
//TODO(mitake|hexfusion) review unifying key names
ts, ok := md[rpctypes.TokenFieldNameGRPC]
if !ok {
ts, ok = md[rpctypes.TokenFieldNameSwagger]
}
if !ok {
return nil, nil
}
token := ts[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
authInfo, uok := as.authInfoFromToken(ctx, token)
if !uok {
if as.lg != nil {
as.lg.Warn("invalid auth token", zap.String("token", token))
} else {
plog.Warningf("invalid auth token: %s", token)
}
return nil, ErrInvalidAuthToken
}
return authInfo, 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 (as *authStore) GenTokenPrefix() (string, error) {
return as.tokenProvider.genTokenPrefix()
}
func decomposeOpts(lg *zap.Logger, optstr string) (string, map[string]string, error) {
*: 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
opts := strings.Split(optstr, ",")
tokenType := opts[0]
typeSpecificOpts := make(map[string]string)
for i := 1; i < len(opts); i++ {
pair := strings.Split(opts[i], "=")
if len(pair) != 2 {
if lg != nil {
lg.Warn("invalid token option", zap.String("option", optstr))
} else {
plog.Errorf("invalid token specific option: %s", optstr)
}
*: 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 "", nil, ErrInvalidAuthOpts
}
if _, ok := typeSpecificOpts[pair[0]]; ok {
if lg != nil {
lg.Warn(
"invalid token option",
zap.String("option", optstr),
zap.String("duplicate-parameter", pair[0]),
)
} else {
plog.Errorf("invalid token specific option, duplicated parameters (%s): %s", pair[0], optstr)
}
*: 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 "", nil, ErrInvalidAuthOpts
}
typeSpecificOpts[pair[0]] = pair[1]
}
return tokenType, typeSpecificOpts, nil
}
// NewTokenProvider creates a new token provider.
func NewTokenProvider(
lg *zap.Logger,
tokenOpts string,
indexWaiter func(uint64) <-chan struct{}) (TokenProvider, error) {
tokenType, typeSpecificOpts, err := decomposeOpts(lg, tokenOpts)
*: 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 nil, ErrInvalidAuthOpts
}
switch tokenType {
case tokenTypeSimple:
if lg != nil {
lg.Warn("simple token is not cryptographically signed")
} else {
plog.Warningf("simple token is not cryptographically signed")
}
return newTokenProviderSimple(lg, indexWaiter), nil
case tokenTypeJWT:
return newTokenProviderJWT(lg, typeSpecificOpts)
case "":
return newTokenProviderNop()
*: 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
default:
if lg != nil {
lg.Warn(
"unknown token type",
zap.String("type", tokenType),
zap.Error(ErrInvalidAuthOpts),
)
} else {
plog.Errorf("unknown token type: %s", tokenType)
}
*: 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 nil, ErrInvalidAuthOpts
}
}
func (as *authStore) WithRoot(ctx context.Context) context.Context {
if !as.IsAuthEnabled() {
return ctx
}
var ctxForAssign context.Context
if ts, ok := as.tokenProvider.(*tokenSimple); ok && ts != nil {
ctx1 := context.WithValue(ctx, AuthenticateParamIndex{}, uint64(0))
prefix, err := ts.genTokenPrefix()
if err != nil {
if as.lg != nil {
as.lg.Warn(
"failed to generate prefix of internally used token",
zap.Error(err),
)
} else {
plog.Errorf("failed to generate prefix of internally used token")
}
return ctx
}
ctxForAssign = context.WithValue(ctx1, AuthenticateParamSimpleTokenPrefix{}, prefix)
} else {
ctxForAssign = ctx
}
token, err := as.tokenProvider.assign(ctxForAssign, "root", as.Revision())
if err != nil {
// this must not happen
if as.lg != nil {
as.lg.Warn(
"failed to assign token for lease revoking",
zap.Error(err),
)
} else {
plog.Errorf("failed to assign token for lease revoking: %s", err)
}
return ctx
}
mdMap := map[string]string{
rpctypes.TokenFieldNameGRPC: token,
}
tokenMD := metadata.New(mdMap)
// use "mdIncomingKey{}" since it's called from local etcdserver
return metadata.NewIncomingContext(ctx, tokenMD)
}
func (as *authStore) HasRole(user, role string) bool {
tx := as.be.BatchTx()
tx.Lock()
u := getUser(as.lg, tx, user)
tx.Unlock()
if u == nil {
if as.lg != nil {
as.lg.Warn(
"'has-role' requested for non-existing user",
zap.String("user-name", user),
zap.String("role-name", role),
)
} else {
plog.Warningf("tried to check user %s has role %s, but user %s doesn't exist", user, role, user)
}
return false
}
for _, r := range u.Roles {
if role == r {
return true
}
}
return false
}
2018-05-03 21:43:32 +03:00
func (as *authStore) BcryptCost() int {
return as.bcryptCost
}