2018-10-26 22:20:02 +00:00
/ *
Copyright 2018 Gravitational , Inc .
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 .
* /
2018-04-08 21:37:33 +00:00
package service
import (
2021-04-20 23:59:01 +00:00
"crypto/tls"
2019-05-03 00:40:46 +00:00
"net"
2018-10-03 19:35:57 +00:00
"path/filepath"
2019-05-03 00:40:46 +00:00
"strconv"
2018-04-08 21:37:33 +00:00
"time"
2018-10-03 19:35:57 +00:00
"golang.org/x/crypto/ssh"
2021-04-20 23:59:01 +00:00
"github.com/gravitational/roundtrip"
2018-04-08 21:37:33 +00:00
"github.com/gravitational/teleport"
2020-12-29 17:24:16 +00:00
apiclient "github.com/gravitational/teleport/api/client"
2021-04-20 23:44:17 +00:00
"github.com/gravitational/teleport/api/client/webclient"
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
"github.com/gravitational/teleport/lib"
2018-04-08 21:37:33 +00:00
"github.com/gravitational/teleport/lib/auth"
2018-12-12 00:22:44 +00:00
"github.com/gravitational/teleport/lib/backend"
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
"github.com/gravitational/teleport/lib/client"
2018-10-03 19:35:57 +00:00
"github.com/gravitational/teleport/lib/defaults"
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
"github.com/gravitational/teleport/lib/reversetunnel"
2018-04-08 21:37:33 +00:00
"github.com/gravitational/teleport/lib/services"
2018-09-01 01:26:18 +00:00
"github.com/gravitational/teleport/lib/tlsca"
2018-04-08 21:37:33 +00:00
"github.com/gravitational/teleport/lib/utils"
2021-03-31 20:33:22 +00:00
"github.com/gravitational/teleport/lib/utils/interval"
2018-09-01 01:26:18 +00:00
2018-04-08 21:37:33 +00:00
"github.com/gravitational/trace"
2021-04-15 19:11:48 +00:00
2020-12-07 14:35:15 +00:00
"github.com/sirupsen/logrus"
2018-04-08 21:37:33 +00:00
)
2018-12-12 00:22:44 +00:00
// reconnectToAuthService continuously attempts to reconnect to the auth
// service until succeeds or process gets shut down
func ( process * TeleportProcess ) reconnectToAuthService ( role teleport . Role ) ( * Connector , error ) {
retryTime := defaults . HighResPollingPeriod
for {
connector , err := process . connectToAuthService ( role )
if err == nil {
// if connected and client is present, make sure the connector's
// client works, by using call that should succeed at all times
if connector . Client != nil {
2021-05-05 21:58:43 +00:00
pingResponse , err := connector . Client . Ping ( process . ExitContext ( ) )
2018-12-12 00:22:44 +00:00
if err == nil {
2021-05-05 21:58:43 +00:00
process . setClusterFeatures ( pingResponse . GetServerFeatures ( ) )
process . log . Infof ( "%v: features loaded from auth server: %+v" , role , pingResponse . GetServerFeatures ( ) )
2018-12-12 00:22:44 +00:00
return connector , nil
}
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Connected client %v failed to execute test call: %v. Node or proxy credentials are out of sync." , role , err )
2018-12-12 00:22:44 +00:00
if err := connector . Client . Close ( ) ; err != nil {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Failed to close the client: %v." , err )
2018-12-12 00:22:44 +00:00
}
}
}
2020-12-07 14:35:15 +00:00
process . log . Errorf ( "%v failed to establish connection to cluster: %v." , role , err )
2019-06-12 22:57:56 +00:00
2018-12-12 00:22:44 +00:00
// Wait in between attempts, but return if teleport is shutting down
select {
case <- time . After ( retryTime ) :
case <- process . ExitContext ( ) . Done ( ) :
2020-12-07 14:35:15 +00:00
process . log . Infof ( "%v stopping connection attempts, teleport is shutting down." , role )
2018-12-12 00:22:44 +00:00
return nil , ErrTeleportExited
}
}
}
2018-04-08 21:37:33 +00:00
// connectToAuthService attempts to login into the auth servers specified in the
// configuration and receive credentials.
func ( process * TeleportProcess ) connectToAuthService ( role teleport . Role ) ( * Connector , error ) {
connector , err := process . connect ( role )
if err != nil {
return nil , trace . Wrap ( err )
}
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Connected client: %v" , connector . ClientIdentity )
process . log . Debugf ( "Connected server: %v" , connector . ServerIdentity )
2018-04-08 21:37:33 +00:00
process . addConnector ( connector )
2018-12-12 00:22:44 +00:00
2018-04-08 21:37:33 +00:00
return connector , nil
}
2018-06-08 23:50:43 +00:00
func ( process * TeleportProcess ) connect ( role teleport . Role ) ( conn * Connector , err error ) {
2018-04-08 21:37:33 +00:00
state , err := process . storage . GetState ( role )
if err != nil {
if ! trace . IsNotFound ( err ) {
return nil , trace . Wrap ( err )
}
// no state recorded - this is the first connect
// process will try to connect with the security token.
return process . firstTimeConnect ( role )
}
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Connected state: %v." , state . Spec . Rotation . String ( ) )
2018-04-08 21:37:33 +00:00
identity , err := process . GetIdentity ( role )
if err != nil {
return nil , trace . Wrap ( err )
}
2018-09-21 20:07:48 +00:00
// TODO(klizhentas): REMOVE IN 3.1
// this is a migration clutch, used to re-register
// in case if identity of the auth server does not have the wildcard cert
if role == teleport . RoleAdmin || role == teleport . RoleAuth {
2019-03-21 02:51:32 +00:00
if ! identity . HasDNSNames ( [ ] string { "*." + teleport . APIDomain } ) {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Detected Auth server certificate without wildcard principals: %v, regenerating." , identity . Cert . ValidPrincipals )
2018-09-21 20:07:48 +00:00
return process . firstTimeConnect ( role )
}
}
2018-04-08 21:37:33 +00:00
rotation := state . Spec . Rotation
switch rotation . State {
// rotation is on standby, so just use whatever is current
case "" , services . RotationStateStandby :
2018-09-21 20:07:48 +00:00
// The roles of admin and auth are treated in a special way, as in this case
2018-04-08 21:37:33 +00:00
// the process does not need TLS clients and can use local auth directly.
if role == teleport . RoleAdmin || role == teleport . RoleAuth {
return & Connector {
ClientIdentity : identity ,
ServerIdentity : identity ,
} , nil
}
2020-12-07 14:35:15 +00:00
process . log . Infof ( "Connecting to the cluster %v with TLS client certificate." , identity . ClusterName )
2019-05-03 04:34:15 +00:00
client , err := process . newClient ( process . Config . AuthServers , identity )
2018-04-08 21:37:33 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
return & Connector {
Client : client ,
ClientIdentity : identity ,
ServerIdentity : identity ,
} , nil
2018-04-08 21:37:33 +00:00
case services . RotationStateInProgress :
switch rotation . Phase {
2018-05-07 21:44:46 +00:00
case services . RotationPhaseInit :
// Both clients and servers are using old credentials,
// this phase exists for remote clusters to propagate information about the new CA
if role == teleport . RoleAdmin || role == teleport . RoleAuth {
return & Connector {
ClientIdentity : identity ,
ServerIdentity : identity ,
} , nil
}
2019-05-03 04:34:15 +00:00
client , err := process . newClient ( process . Config . AuthServers , identity )
2018-05-07 21:44:46 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
return & Connector {
Client : client ,
ClientIdentity : identity ,
ServerIdentity : identity ,
} , nil
2018-04-08 21:37:33 +00:00
case services . RotationPhaseUpdateClients :
// Clients should use updated credentials,
// while servers should use old credentials to answer auth requests.
newIdentity , err := process . storage . ReadIdentity ( auth . IdentityReplacement , role )
if err != nil {
return nil , trace . Wrap ( err )
}
if role == teleport . RoleAdmin || role == teleport . RoleAuth {
return & Connector {
ClientIdentity : newIdentity ,
ServerIdentity : identity ,
} , nil
}
2019-05-03 04:34:15 +00:00
client , err := process . newClient ( process . Config . AuthServers , newIdentity )
2018-04-08 21:37:33 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
return & Connector {
Client : client ,
ClientIdentity : newIdentity ,
ServerIdentity : identity ,
} , nil
case services . RotationPhaseUpdateServers :
// Servers and clients are using new identity credentials, but the
// identity is still set up to trust the old certificate authority certificates.
newIdentity , err := process . storage . ReadIdentity ( auth . IdentityReplacement , role )
if err != nil {
return nil , trace . Wrap ( err )
}
if role == teleport . RoleAdmin || role == teleport . RoleAuth {
return & Connector {
ClientIdentity : newIdentity ,
ServerIdentity : newIdentity ,
} , nil
}
2019-05-03 04:34:15 +00:00
client , err := process . newClient ( process . Config . AuthServers , newIdentity )
2018-04-08 21:37:33 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
return & Connector {
Client : client ,
ClientIdentity : newIdentity ,
ServerIdentity : newIdentity ,
} , nil
case services . RotationPhaseRollback :
// In rollback phase, clients and servers should switch back
// to the old certificate authority-issued credentials,
// but the new certificate authority should be trusted
// because not all clients can update at the same time.
if role == teleport . RoleAdmin || role == teleport . RoleAuth {
return & Connector {
ClientIdentity : identity ,
ServerIdentity : identity ,
} , nil
}
2019-05-03 04:34:15 +00:00
client , err := process . newClient ( process . Config . AuthServers , identity )
2018-04-08 21:37:33 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
return & Connector {
Client : client ,
ClientIdentity : identity ,
ServerIdentity : identity ,
} , nil
default :
return nil , trace . BadParameter ( "unsupported rotation phase: %q" , rotation . Phase )
}
default :
return nil , trace . BadParameter ( "unsupported rotation state: %q" , rotation . State )
}
}
2018-09-01 01:26:18 +00:00
// KeyPair is a private/public key pair
type KeyPair struct {
// PrivateKey is a private key in PEM format
PrivateKey [ ] byte
// PublicSSHKey is a public key in SSH format
PublicSSHKey [ ] byte
// PublicTLSKey is a public key in X509 format
PublicTLSKey [ ] byte
}
func ( process * TeleportProcess ) deleteKeyPair ( role teleport . Role , reason string ) {
process . keyMutex . Lock ( )
defer process . keyMutex . Unlock ( )
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Deleted generated key pair %v %v." , role , reason )
2018-09-01 01:26:18 +00:00
delete ( process . keyPairs , keyPairKey { role : role , reason : reason } )
}
func ( process * TeleportProcess ) generateKeyPair ( role teleport . Role , reason string ) ( * KeyPair , error ) {
process . keyMutex . Lock ( )
defer process . keyMutex . Unlock ( )
mapKey := keyPairKey { role : role , reason : reason }
keyPair , ok := process . keyPairs [ mapKey ]
if ok {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Returning existing key pair for %v %v." , role , reason )
2018-09-01 01:26:18 +00:00
return & keyPair , nil
}
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Generating new key pair for %v %v." , role , reason )
2018-09-01 01:26:18 +00:00
privPEM , pubSSH , err := process . Config . Keygen . GenerateKeyPair ( "" )
if err != nil {
return nil , trace . Wrap ( err )
}
privateKey , err := ssh . ParseRawPrivateKey ( privPEM )
if err != nil {
return nil , trace . Wrap ( err )
}
pubTLS , err := tlsca . MarshalPublicKeyFromPrivateKeyPEM ( privateKey )
if err != nil {
return nil , trace . Wrap ( err )
}
keyPair = KeyPair { PrivateKey : privPEM , PublicSSHKey : pubSSH , PublicTLSKey : pubTLS }
process . keyPairs [ mapKey ] = keyPair
return & keyPair , nil
}
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
// newWatcher returns a new watcher,
// either using local auth server connection or remote client
func ( process * TeleportProcess ) newWatcher ( conn * Connector , watch services . Watch ) ( services . Watcher , error ) {
if conn . ClientIdentity . ID . Role == teleport . RoleAdmin || conn . ClientIdentity . ID . Role == teleport . RoleAuth {
return process . localAuth . NewWatcher ( process . ExitContext ( ) , watch )
}
return conn . Client . NewWatcher ( process . ExitContext ( ) , watch )
}
2018-09-01 01:26:18 +00:00
// getCertAuthority returns cert authority by ID.
// In case if auth servers, the role is 'TeleportAdmin' and instead of using
// TLS client this method uses the local auth server.
func ( process * TeleportProcess ) getCertAuthority ( conn * Connector , id services . CertAuthID , loadPrivateKeys bool ) ( services . CertAuthority , error ) {
if conn . ClientIdentity . ID . Role == teleport . RoleAdmin || conn . ClientIdentity . ID . Role == teleport . RoleAuth {
return process . localAuth . GetCertAuthority ( id , loadPrivateKeys )
}
return conn . Client . GetCertAuthority ( id , loadPrivateKeys )
}
// reRegister receives new identity credentials for proxy, node and auth.
// In case if auth servers, the role is 'TeleportAdmin' and instead of using
// TLS client this method uses the local auth server.
2018-12-12 00:22:44 +00:00
func ( process * TeleportProcess ) reRegister ( conn * Connector , additionalPrincipals [ ] string , dnsNames [ ] string , rotation services . Rotation ) ( * auth . Identity , error ) {
2018-09-01 01:26:18 +00:00
if conn . ClientIdentity . ID . Role == teleport . RoleAdmin || conn . ClientIdentity . ID . Role == teleport . RoleAuth {
2019-03-21 02:51:32 +00:00
return auth . GenerateIdentity ( process . localAuth , conn . ClientIdentity . ID , additionalPrincipals , dnsNames )
2018-09-01 01:26:18 +00:00
}
const reason = "re-register"
keyPair , err := process . generateKeyPair ( conn . ClientIdentity . ID . Role , reason )
if err != nil {
return nil , trace . Wrap ( err )
}
identity , err := auth . ReRegister ( auth . ReRegisterParams {
Client : conn . Client ,
ID : conn . ClientIdentity . ID ,
AdditionalPrincipals : additionalPrincipals ,
PrivateKey : keyPair . PrivateKey ,
PublicTLSKey : keyPair . PublicTLSKey ,
PublicSSHKey : keyPair . PublicSSHKey ,
2019-03-21 02:51:32 +00:00
DNSNames : dnsNames ,
2018-12-12 00:22:44 +00:00
Rotation : rotation ,
2018-09-01 01:26:18 +00:00
} )
if err != nil {
return nil , trace . Wrap ( err )
}
process . deleteKeyPair ( conn . ClientIdentity . ID . Role , reason )
return identity , nil
}
2018-04-08 21:37:33 +00:00
func ( process * TeleportProcess ) firstTimeConnect ( role teleport . Role ) ( * Connector , error ) {
id := auth . IdentityID {
Role : role ,
HostUUID : process . Config . HostUUID ,
NodeName : process . Config . Hostname ,
}
2019-03-21 02:51:32 +00:00
additionalPrincipals , dnsNames , err := process . getAdditionalPrincipals ( role )
2018-04-08 21:37:33 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
var identity * auth . Identity
if process . getLocalAuth ( ) != nil {
// Auth service is on the same host, no need to go though the invitation
// procedure.
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "This server has local Auth server started, using it to add role to the cluster." )
2019-03-21 02:51:32 +00:00
identity , err = auth . LocalRegister ( id , process . getLocalAuth ( ) , additionalPrincipals , dnsNames , process . Config . AdvertiseIP )
2018-09-07 21:35:23 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
2018-04-08 21:37:33 +00:00
} else {
// Auth server is remote, so we need a provisioning token.
if process . Config . Token == "" {
return nil , trace . BadParameter ( "%v must join a cluster and needs a provisioning token" , role )
}
2020-12-07 14:35:15 +00:00
process . log . Infof ( "Joining the cluster with a secure token." )
2018-09-01 01:26:18 +00:00
const reason = "first-time-connect"
keyPair , err := process . generateKeyPair ( role , reason )
if err != nil {
return nil , trace . Wrap ( err )
}
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
2018-09-01 01:26:18 +00:00
identity , err = auth . Register ( auth . RegisterParams {
DataDir : process . Config . DataDir ,
Token : process . Config . Token ,
ID : id ,
Servers : process . Config . AuthServers ,
AdditionalPrincipals : additionalPrincipals ,
2019-03-21 02:51:32 +00:00
DNSNames : dnsNames ,
2018-09-01 01:26:18 +00:00
PrivateKey : keyPair . PrivateKey ,
PublicTLSKey : keyPair . PublicTLSKey ,
PublicSSHKey : keyPair . PublicSSHKey ,
CipherSuites : process . Config . CipherSuites ,
2018-10-03 19:35:57 +00:00
CAPin : process . Config . CAPin ,
CAPath : filepath . Join ( defaults . DataDir , defaults . CACertFile ) ,
2019-05-20 22:25:31 +00:00
GetHostCredentials : client . HostCredentials ,
2021-03-01 14:16:55 +00:00
Clock : process . Clock ,
2018-09-01 01:26:18 +00:00
} )
2018-09-07 21:35:23 +00:00
if err != nil {
return nil , trace . Wrap ( err )
2018-09-01 01:26:18 +00:00
}
2018-09-07 21:35:23 +00:00
process . deleteKeyPair ( role , reason )
2018-04-08 21:37:33 +00:00
}
2020-12-07 14:35:15 +00:00
process . log . Infof ( "%v has obtained credentials to connect to cluster." , role )
2018-04-08 21:37:33 +00:00
var connector * Connector
if role == teleport . RoleAdmin || role == teleport . RoleAuth {
connector = & Connector {
ClientIdentity : identity ,
ServerIdentity : identity ,
}
} else {
2019-05-03 04:34:15 +00:00
client , err := process . newClient ( process . Config . AuthServers , identity )
2018-04-08 21:37:33 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
connector = & Connector {
ClientIdentity : identity ,
ServerIdentity : identity ,
Client : client ,
}
}
// Sync local rotation state to match the remote rotation state.
2018-09-01 01:26:18 +00:00
ca , err := process . getCertAuthority ( connector , services . CertAuthID {
2018-04-08 21:37:33 +00:00
DomainName : connector . ClientIdentity . ClusterName ,
Type : services . HostCA ,
} , false )
if err != nil {
return nil , trace . Wrap ( err )
}
err = process . storage . WriteIdentity ( auth . IdentityCurrent , * identity )
if err != nil {
2020-12-07 14:35:15 +00:00
process . log . Warningf ( "Failed to write %v identity: %v." , role , err )
2018-04-08 21:37:33 +00:00
}
err = process . storage . WriteState ( role , auth . StateV2 {
Spec : auth . StateSpecV2 {
Rotation : ca . GetRotation ( ) ,
} ,
} )
if err != nil {
return nil , trace . Wrap ( err )
}
2020-12-07 14:35:15 +00:00
process . log . Infof ( "The process has successfully wrote credentials and state of %v to disk." , role )
2018-04-08 21:37:33 +00:00
return connector , nil
}
// periodicSyncRotationState checks rotation state periodically and
// takes action if necessary
func ( process * TeleportProcess ) periodicSyncRotationState ( ) error {
// start rotation only after teleport process has started
eventC := make ( chan Event , 1 )
process . WaitForEvent ( process . ExitContext ( ) , TeleportReadyEvent , eventC )
select {
case <- eventC :
2020-12-07 14:35:15 +00:00
process . log . Infof ( "The new service has started successfully. Starting syncing rotation status with period %v." , process . Config . PollingPeriod )
2018-04-08 21:37:33 +00:00
case <- process . ExitContext ( ) . Done ( ) :
return nil
}
2021-03-31 20:33:22 +00:00
periodic := interval . New ( interval . Config {
Duration : defaults . HighResPollingPeriod ,
FirstDuration : utils . HalfJitter ( defaults . HighResPollingPeriod ) ,
Jitter : utils . NewSeventhJitter ( ) ,
} )
defer periodic . Stop ( )
2018-04-08 21:37:33 +00:00
for {
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
err := process . syncRotationStateCycle ( )
if err == nil {
return nil
}
2021-03-31 20:33:22 +00:00
process . log . Warningf ( "Sync rotation state cycle failed: %v, going to retry after ~%v." , err , defaults . HighResPollingPeriod )
2018-04-08 21:37:33 +00:00
select {
2021-03-31 20:33:22 +00:00
case <- periodic . Next ( ) :
2018-04-08 21:37:33 +00:00
case <- process . ExitContext ( ) . Done ( ) :
return nil
}
}
}
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
// syncRotationCycle executes a rotation cycle that returns:
//
// * nil whenever rotation state leads to teleport reload event
// * error whenever rotation sycle has to be restarted
//
// the function accepts extra delay timer extraDelay in case if parent
// function needs a
func ( process * TeleportProcess ) syncRotationStateCycle ( ) error {
2018-04-08 21:37:33 +00:00
connectors := process . getConnectors ( )
if len ( connectors ) == 0 {
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
return trace . BadParameter ( "no connectors found" )
2018-04-08 21:37:33 +00:00
}
// it is important to use the same view of the certificate authority
// for all internal services at the same time, so that the same
// procedure will be applied at the same time for multiple service process
// and no internal services is left behind.
conn := connectors [ 0 ]
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
status , err := process . syncRotationStateAndBroadcast ( conn )
if err != nil {
return trace . Wrap ( err )
}
if status . needsReload {
return nil
}
2018-12-12 00:22:44 +00:00
watcher , err := process . newWatcher ( conn , services . Watch { Kinds : [ ] services . WatchKind { { Kind : services . KindCertAuthority } } } )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
if err != nil {
return trace . Wrap ( err )
}
defer watcher . Close ( )
2021-03-31 20:33:22 +00:00
periodic := interval . New ( interval . Config {
Duration : process . Config . PollingPeriod ,
FirstDuration : utils . HalfJitter ( process . Config . PollingPeriod ) ,
Jitter : utils . NewSeventhJitter ( ) ,
} )
defer periodic . Stop ( )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
for {
select {
case event := <- watcher . Events ( ) :
2018-12-12 00:22:44 +00:00
if event . Type == backend . OpInit || event . Type == backend . OpDelete {
continue
}
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
ca , ok := event . Resource . ( services . CertAuthority )
if ! ok {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Skipping event %v for %v" , event . Type , event . Resource . GetName ( ) )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
continue
}
if ca . GetType ( ) != services . HostCA && ca . GetClusterName ( ) != conn . ClientIdentity . ClusterName {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Skipping event for %v %v" , ca . GetType ( ) , ca . GetClusterName ( ) )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
continue
}
if status . ca . GetResourceID ( ) > ca . GetResourceID ( ) {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Skipping stale event %v, latest object version is %v." , ca . GetResourceID ( ) , status . ca . GetResourceID ( ) )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
continue
}
status , err := process . syncRotationStateAndBroadcast ( conn )
if err != nil {
return trace . Wrap ( err )
}
if status . needsReload {
return nil
}
case <- watcher . Done ( ) :
return trace . ConnectionProblem ( watcher . Error ( ) , "watcher has disconnected" )
2021-03-31 20:33:22 +00:00
case <- periodic . Next ( ) :
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
status , err := process . syncRotationStateAndBroadcast ( conn )
if err != nil {
return trace . Wrap ( err )
}
if status . needsReload {
return nil
}
case <- process . ExitContext ( ) . Done ( ) :
return nil
}
}
}
// syncRotationStateAndBroadcast syncs rotation state and broadcasts events
// when phase has been changed or reload happened
func ( process * TeleportProcess ) syncRotationStateAndBroadcast ( conn * Connector ) ( * rotationStatus , error ) {
status , err := process . syncRotationState ( conn )
if err != nil {
if trace . IsConnectionProblem ( err ) {
2020-12-07 14:35:15 +00:00
process . log . Warningf ( "Connection problem: sync rotation state: %v." , err )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
} else {
2020-12-07 14:35:15 +00:00
process . log . Warningf ( "Failed to sync rotation state: %v." , err )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
}
return nil , trace . Wrap ( err )
}
if status . phaseChanged || status . needsReload {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Sync rotation state detected cert authority reload phase update." )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
}
if status . phaseChanged {
process . BroadcastEvent ( Event { Name : TeleportPhaseChangeEvent } )
}
if status . needsReload {
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Triggering reload process." )
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
process . BroadcastEvent ( Event { Name : TeleportReloadEvent } )
}
return status , nil
}
// syncRotationState compares cluster rotation state with the state of
// internal services and performs the rotation if necessary.
func ( process * TeleportProcess ) syncRotationState ( conn * Connector ) ( * rotationStatus , error ) {
connectors := process . getConnectors ( )
2018-09-01 01:26:18 +00:00
ca , err := process . getCertAuthority ( conn , services . CertAuthID {
2018-04-08 21:37:33 +00:00
DomainName : conn . ClientIdentity . ClusterName ,
Type : services . HostCA ,
} , false )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
2018-05-07 21:44:46 +00:00
var status rotationStatus
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
status . ca = ca
2018-04-08 21:37:33 +00:00
for _ , conn := range connectors {
2018-05-07 21:44:46 +00:00
serviceStatus , err := process . syncServiceRotationState ( ca , conn )
2018-04-08 21:37:33 +00:00
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
2018-05-07 21:44:46 +00:00
if serviceStatus . needsReload {
status . needsReload = true
}
if serviceStatus . phaseChanged {
status . phaseChanged = true
2018-04-08 21:37:33 +00:00
}
}
2018-05-07 21:44:46 +00:00
return & status , nil
2018-04-08 21:37:33 +00:00
}
// syncServiceRotationState syncs up rotation state for internal services (Auth, Proxy, Node) and
// if necessary, updates credentials. Returns true if the service will need to reload.
2018-05-07 21:44:46 +00:00
func ( process * TeleportProcess ) syncServiceRotationState ( ca services . CertAuthority , conn * Connector ) ( * rotationStatus , error ) {
2018-04-08 21:37:33 +00:00
state , err := process . storage . GetState ( conn . ClientIdentity . ID . Role )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
2018-05-07 21:44:46 +00:00
return process . rotate ( conn , * state , ca . GetRotation ( ) )
}
type rotationStatus struct {
// needsReload means that phase has been updated
// and teleport process has to reload
needsReload bool
// phaseChanged means that teleport phase has been updated,
// but teleport does not need reload
phaseChanged bool
Events and GRPC API
This commit introduces several key changes to
Teleport backend and API infrastructure
in order to achieve scalability improvements
on 10K+ node deployments.
Events and plain keyspace
--------------------------
New backend interface supports events,
pagination and range queries
and moves away from buckets to
plain keyspace, what better aligns
with DynamoDB and Etcd featuring similar
interfaces.
All backend implementations are
exposing Events API, allowing
multiple subscribers to consume the same
event stream and avoid polling database.
Replacing BoltDB, Dir with SQLite
-------------------------------
BoltDB backend does not support
having two processes access the database at the
same time. This prevented Teleport
using BoltDB backend to be live reloaded.
SQLite supports reads/writes by multiple
processes and makes Dir backend obsolete
as SQLite is more efficient on larger collections,
supports transactions and can detect data
corruption.
Teleport automatically migrates data from
Bolt and Dir backends into SQLite.
GRPC API and protobuf resources
-------------------------------
GRPC API has been introduced for
the auth server. The auth server now serves both GRPC
and JSON-HTTP API on the same TLS socket and uses
the same client certificate authentication.
All future API methods should use GRPC and HTTP-JSON
API is considered obsolete.
In addition to that some resources like
Server and CertificateAuthority are now
generated from protobuf service specifications in
a way that is fully backward compatible with
original JSON spec and schema, so the same resource
can be encoded and decoded from JSON, YAML
and protobuf.
All models should be refactored
into new proto specification over time.
Streaming presence service
--------------------------
In order to cut bandwidth, nodes
are sending full updates only when changes
to labels or spec have occured, otherwise
new light-weight GRPC keep alive updates are sent
over to the presence service, reducing
bandwidth usage on multi-node deployments.
In addition to that nodes are no longer polling
auth server for certificate authority rotation
updates, instead they subscribe to event updates
to detect updates as soon as they happen.
This is a new API, so the errors are inevitable,
that's why polling is still done, but
on a way slower rate.
2018-11-07 23:33:38 +00:00
// ca is the certificate authority
// fetched during status check
ca services . CertAuthority
2018-04-08 21:37:33 +00:00
}
2020-02-26 22:39:33 +00:00
// checkServerIdentity returns a boolean that indicates the host certificate
2019-06-28 20:12:38 +00:00
// needs to be regenerated.
2020-12-07 14:35:15 +00:00
func checkServerIdentity ( conn * Connector , additionalPrincipals [ ] string , dnsNames [ ] string , log logrus . FieldLogger ) bool {
2019-06-28 20:12:38 +00:00
var principalsChanged bool
var dnsNamesChanged bool
// Remove 0.0.0.0 (meaning advertise_ip has not) if it exists in the list of
// principals. The 0.0.0.0 values tells the auth server to "guess" the nodes
// IP. If 0.0.0.0 is not removed, a check is performed if it exists in the
// list of principals in the certificate. Since it never exists in the list
// of principals (auth server will always remove it before issuing a
// certificate) regeneration is always requested.
principalsToCheck := utils . RemoveFromSlice ( additionalPrincipals , defaults . AnyAddress )
// If advertise_ip, public_addr, or listen_addr in file configuration were
// updated, the list of principals (SSH) or DNS names (TLS) on the
// certificate need to be updated.
if len ( additionalPrincipals ) != 0 && ! conn . ServerIdentity . HasPrincipals ( principalsToCheck ) {
principalsChanged = true
log . Debugf ( "Rotation in progress, adding %v to SSH principals %v." ,
additionalPrincipals , conn . ServerIdentity . Cert . ValidPrincipals )
}
if len ( dnsNames ) != 0 && ! conn . ServerIdentity . HasDNSNames ( dnsNames ) {
dnsNamesChanged = true
log . Debugf ( "Rotation in progress, adding %v to x590 DNS names in SAN %v." ,
dnsNames , conn . ServerIdentity . XCert . DNSNames )
}
2020-03-17 17:01:53 +00:00
return principalsChanged || dnsNamesChanged
2019-06-28 20:12:38 +00:00
}
2018-04-08 21:37:33 +00:00
// rotate is called to check if rotation should be triggered.
2018-05-07 21:44:46 +00:00
func ( process * TeleportProcess ) rotate ( conn * Connector , localState auth . StateV2 , remote services . Rotation ) ( * rotationStatus , error ) {
2018-04-08 21:37:33 +00:00
id := conn . ClientIdentity . ID
local := localState . Spec . Rotation
2019-03-21 02:51:32 +00:00
additionalPrincipals , dnsNames , err := process . getAdditionalPrincipals ( id . Role )
2018-04-08 21:37:33 +00:00
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
2019-03-21 02:51:32 +00:00
2019-06-28 20:12:38 +00:00
// Check if any of the SSH principals or TLS DNS names have changed and the
// host credentials need to be regenerated.
2020-12-07 14:35:15 +00:00
regenerateCertificate := checkServerIdentity ( conn , additionalPrincipals , dnsNames , process . log )
2019-06-21 00:04:13 +00:00
// If the local state matches remote state and neither principals or DNS
// names changed, nothing to do. CA is in sync.
2019-06-28 20:12:38 +00:00
if local . Matches ( remote ) && ! regenerateCertificate {
2018-05-07 21:44:46 +00:00
return & rotationStatus { } , nil
2018-05-02 22:45:31 +00:00
}
2018-04-08 21:37:33 +00:00
storage := process . storage
const outOfSync = "%v and cluster rotation state (%v) is out of sync with local (%v). Clear local state and re-register this %v."
writeStateAndIdentity := func ( name string , identity * auth . Identity ) error {
err = storage . WriteIdentity ( name , * identity )
if err != nil {
return trace . Wrap ( err )
}
localState . Spec . Rotation = remote
err = storage . WriteState ( id . Role , localState )
if err != nil {
return trace . Wrap ( err )
}
return nil
}
switch remote . State {
case "" , services . RotationStateStandby :
switch local . State {
// There is nothing to do, it could happen
// that the old node came up and missed the whole rotation
// rollback cycle.
case "" , services . RotationStateStandby :
2019-06-28 20:12:38 +00:00
if regenerateCertificate {
2020-12-07 14:35:15 +00:00
process . log . Infof ( "Service %v has updated principals to %q, DNS Names to %q, going to request new principals and update." , id . Role , additionalPrincipals , dnsNames )
2018-12-12 00:22:44 +00:00
identity , err := process . reRegister ( conn , additionalPrincipals , dnsNames , remote )
2018-04-08 21:37:33 +00:00
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
err = storage . WriteIdentity ( auth . IdentityCurrent , * identity )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
2018-05-07 21:44:46 +00:00
return & rotationStatus { needsReload : true } , nil
2018-04-08 21:37:33 +00:00
}
2018-05-07 21:44:46 +00:00
return & rotationStatus { } , nil
2018-04-08 21:37:33 +00:00
case services . RotationStateInProgress :
// Rollback phase has been completed, all services
// will receive new identities.
if local . Phase != services . RotationPhaseRollback && local . CurrentID != remote . CurrentID {
2018-05-07 21:44:46 +00:00
return nil , trace . CompareFailed ( outOfSync , id . Role , remote , local , id . Role )
2018-04-08 21:37:33 +00:00
}
2018-12-12 00:22:44 +00:00
identity , err := process . reRegister ( conn , additionalPrincipals , dnsNames , remote )
2018-04-08 21:37:33 +00:00
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
err = writeStateAndIdentity ( auth . IdentityCurrent , identity )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
2018-05-07 21:44:46 +00:00
return & rotationStatus { needsReload : true } , nil
2018-04-08 21:37:33 +00:00
default :
2018-05-07 21:44:46 +00:00
return nil , trace . BadParameter ( "unsupported state: %q" , localState )
2018-04-08 21:37:33 +00:00
}
case services . RotationStateInProgress :
switch remote . Phase {
case services . RotationPhaseStandby , "" :
// There is nothing to do.
2018-05-07 21:44:46 +00:00
return & rotationStatus { } , nil
case services . RotationPhaseInit :
2018-04-08 21:37:33 +00:00
// Only allow transition in case if local rotation state is standby
// so this server is in the "clean" state.
if local . State != services . RotationStateStandby && local . State != "" {
2018-05-07 21:44:46 +00:00
return nil , trace . CompareFailed ( outOfSync , id . Role , remote , local , id . Role )
}
// only update local phase, there is no need to reload
localState . Spec . Rotation = remote
err = storage . WriteState ( id . Role , localState )
if err != nil {
return nil , trace . Wrap ( err )
}
return & rotationStatus { phaseChanged : true } , nil
case services . RotationPhaseUpdateClients :
// Allow transition to this phase only if the previous
// phase was "Init".
if local . Phase != services . RotationPhaseInit && local . CurrentID != remote . CurrentID {
return nil , trace . CompareFailed ( outOfSync , id . Role , remote , local , id . Role )
2018-04-08 21:37:33 +00:00
}
2018-12-12 00:22:44 +00:00
identity , err := process . reRegister ( conn , additionalPrincipals , dnsNames , remote )
2018-04-08 21:37:33 +00:00
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Re-registered, received new identity %v." , identity )
2018-04-08 21:37:33 +00:00
err = writeStateAndIdentity ( auth . IdentityReplacement , identity )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
// Require reload of teleport process to update client and servers.
2018-05-07 21:44:46 +00:00
return & rotationStatus { needsReload : true } , nil
2018-04-08 21:37:33 +00:00
case services . RotationPhaseUpdateServers :
// Allow transition to this phase only if the previous
// phase was "Update clients".
if local . Phase != services . RotationPhaseUpdateClients && local . CurrentID != remote . CurrentID {
2018-05-07 21:44:46 +00:00
return nil , trace . CompareFailed ( outOfSync , id . Role , remote , local , id . Role )
2018-04-08 21:37:33 +00:00
}
// Write the replacement identity as a current identity and reload the server.
replacement , err := storage . ReadIdentity ( auth . IdentityReplacement , id . Role )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
err = writeStateAndIdentity ( auth . IdentityCurrent , replacement )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
// Require reload of teleport process to update servers.
2018-05-07 21:44:46 +00:00
return & rotationStatus { needsReload : true } , nil
2018-04-08 21:37:33 +00:00
case services . RotationPhaseRollback :
// Allow transition to this phase from any other local phase
// because it will be widely used to recover cluster state to
// the previously valid state, client will re-register to receive
// credentials signed by the "old" CA.
2018-12-12 00:22:44 +00:00
identity , err := process . reRegister ( conn , additionalPrincipals , dnsNames , remote )
2018-04-08 21:37:33 +00:00
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
err = writeStateAndIdentity ( auth . IdentityCurrent , identity )
if err != nil {
2018-05-07 21:44:46 +00:00
return nil , trace . Wrap ( err )
2018-04-08 21:37:33 +00:00
}
// Require reload of teleport process to update servers.
2018-05-07 21:44:46 +00:00
return & rotationStatus { needsReload : true } , nil
2018-04-08 21:37:33 +00:00
default :
2018-05-07 21:44:46 +00:00
return nil , trace . BadParameter ( "unsupported phase: %q" , remote . Phase )
2018-04-08 21:37:33 +00:00
}
default :
2018-05-07 21:44:46 +00:00
return nil , trace . BadParameter ( "unsupported state: %q" , remote . State )
2018-04-08 21:37:33 +00:00
}
}
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
// newClient attempts to connect directly to the Auth Server. If it fails, it
// falls back to trying to connect to the Auth Server through the proxy.
2021-04-15 19:11:48 +00:00
// The proxy address might be configured in process environment as defaults.TunnelPublicAddrEnvar
// in which case, no attempt at discovering the reverse tunnel address is made.
2019-05-03 04:34:15 +00:00
func ( process * TeleportProcess ) newClient ( authServers [ ] utils . NetAddr , identity * auth . Identity ) ( * auth . Client , error ) {
2021-04-20 23:59:01 +00:00
tlsConfig , err := identity . TLSConfig ( process . Config . CipherSuites )
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
if err != nil {
2019-05-03 04:34:15 +00:00
return nil , trace . Wrap ( err )
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
}
// Try and connect to the Auth Server. If the request fails, try and
// connect through a tunnel.
2020-12-07 14:35:15 +00:00
process . log . Debugf ( "Attempting to connect to Auth Server directly." )
2021-04-20 23:59:01 +00:00
directClient , err := process . newClientDirect ( authServers , tlsConfig )
if err == nil {
process . log . Debug ( "Connected to Auth Server with direct connection." )
return directClient , nil
}
process . log . Debug ( "Failed to connect to Auth Server directly." )
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
2021-04-20 23:59:01 +00:00
// Don't attempt to connect through a tunnel as a proxy or auth server.
if identity . ID . Role == teleport . RoleAuth || identity . ID . Role == teleport . RoleProxy {
return nil , trace . Wrap ( err )
}
directDialErr := err
2021-04-15 19:11:48 +00:00
2021-04-20 23:59:01 +00:00
var proxyAddr string
if process . Config . SSH . ProxyReverseTunnelFallbackAddr != nil {
proxyAddr = process . Config . SSH . ProxyReverseTunnelFallbackAddr . String ( )
} else {
// Discover address of SSH reverse tunnel server.
proxyAddr , err = process . findReverseTunnel ( authServers )
2019-06-12 22:57:56 +00:00
if err != nil {
2021-04-20 23:59:01 +00:00
process . log . Debug ( "Failed to discover reverse tunnel address." )
return nil , trace . NewAggregate ( directDialErr , err )
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
}
2021-04-20 23:59:01 +00:00
}
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
2021-04-20 23:59:01 +00:00
logger := process . log . WithField ( "proxy-addr" , proxyAddr )
logger . Debug ( "Attempting to connect to Auth Server through tunnel." )
tunnelClient , err := process . newClientThroughTunnel ( proxyAddr , tlsConfig , identity . SSHClientConfig ( ) )
if err != nil {
logger . Debug ( "Failed to connect to Auth Server through tunnel." )
return nil , trace . NewAggregate ( directDialErr , err )
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
}
2021-04-20 23:59:01 +00:00
logger . Debug ( "Connected to Auth Server through tunnel." )
return tunnelClient , nil
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
}
// findReverseTunnel uses the web proxy to discover where the SSH reverse tunnel
// server is running.
func ( process * TeleportProcess ) findReverseTunnel ( addrs [ ] utils . NetAddr ) ( string , error ) {
var errs [ ] error
for _ , addr := range addrs {
// In insecure mode, any certificate is accepted. In secure mode the hosts
// CAs are used to validate the certificate on the proxy.
2021-04-20 23:44:17 +00:00
resp , err := webclient . Find ( process . ExitContext ( ) ,
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
addr . String ( ) ,
lib . IsInsecureDevMode ( ) ,
nil )
if err == nil {
2019-05-03 00:40:46 +00:00
return tunnelAddr ( resp . Proxy )
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
}
errs = append ( errs , err )
}
return "" , trace . NewAggregate ( errs ... )
}
2019-05-03 00:40:46 +00:00
// tunnelAddr returns the tunnel address in the following preference order:
// 1. Reverse Tunnel Public Address.
// 2. SSH Proxy Public Address.
// 3. HTTP Proxy Public Address.
// 4. Tunnel Listen Address.
2021-04-20 23:44:17 +00:00
func tunnelAddr ( settings webclient . ProxySettings ) ( string , error ) {
2019-05-03 00:40:46 +00:00
// Extract the port the tunnel server is listening on.
netAddr , err := utils . ParseHostPortAddr ( settings . SSH . TunnelListenAddr , defaults . SSHProxyTunnelListenPort )
if err != nil {
return "" , trace . Wrap ( err )
}
tunnelPort := netAddr . Port ( defaults . SSHProxyTunnelListenPort )
// If a tunnel public address is set, nothing else has to be done, return it.
if settings . SSH . TunnelPublicAddr != "" {
return settings . SSH . TunnelPublicAddr , nil
}
// If a tunnel public address has not been set, but a related HTTP or SSH
// public address has been set, extract the hostname but use the port from
// the tunnel listen address.
if settings . SSH . SSHPublicAddr != "" {
addr , err := utils . ParseHostPortAddr ( settings . SSH . SSHPublicAddr , tunnelPort )
if err != nil {
return "" , trace . Wrap ( err )
}
return net . JoinHostPort ( addr . Host ( ) , strconv . Itoa ( tunnelPort ) ) , nil
}
if settings . SSH . PublicAddr != "" {
addr , err := utils . ParseHostPortAddr ( settings . SSH . PublicAddr , tunnelPort )
if err != nil {
return "" , trace . Wrap ( err )
}
return net . JoinHostPort ( addr . Host ( ) , strconv . Itoa ( tunnelPort ) ) , nil
}
// If nothing is set, fallback to the tunnel listen address.
return settings . SSH . TunnelListenAddr , nil
}
2021-04-20 23:59:01 +00:00
func ( process * TeleportProcess ) newClientThroughTunnel ( proxyAddr string , tlsConfig * tls . Config , sshConfig * ssh . ClientConfig ) ( * auth . Client , error ) {
2020-12-29 17:24:16 +00:00
clt , err := auth . NewClient ( apiclient . Config {
2019-05-03 04:34:15 +00:00
Dialer : & reversetunnel . TunnelAuthDialer {
ProxyAddr : proxyAddr ,
2021-04-20 23:59:01 +00:00
ClientConfig : sshConfig ,
2019-05-03 04:34:15 +00:00
} ,
2021-02-23 00:43:00 +00:00
Credentials : [ ] apiclient . Credentials {
apiclient . LoadTLS ( tlsConfig ) ,
} ,
2019-05-02 01:56:42 +00:00
} )
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
if err != nil {
return nil , trace . Wrap ( err )
}
2019-06-12 22:57:56 +00:00
// Check connectivity to cluster. If the request fails, unwrap the error to
// get the underlying error.
_ , err = clt . GetLocalClusterName ( )
if err != nil {
2021-04-20 23:59:01 +00:00
if err2 := clt . Close ( ) ; err != nil {
process . log . WithError ( err2 ) . Warn ( "Failed to close Auth Server tunnel client." )
}
2019-06-12 22:57:56 +00:00
return nil , trace . Unwrap ( err )
}
Added support for nodes dialing back to cluster.
Updated services.ReverseTunnel to support type (proxy or node). For
proxy types, which represent trusted cluster connections, when a
services.ReverseTunnel is created, it's created on the remote side with
name /reverseTunnels/example.com. For node types, services.ReverseTunnel
is created on the main side as /reverseTunnels/{nodeUUID}.clusterName.
Updated services.TunnelConn to support type (proxy or node). For proxy
types, which represent trusted cluster connections, tunnel connections
are created on the main side under
/tunnelConnections/remote.example.com/{proxyUUID}-remote.example.com.
For nodes, tunnel connections are created on the main side under
/tunnelConnections/example.com/{proxyUUID}-example.com. This allows
searching for tunnel connections by cluster then allows easily creating
a set of proxies that are missing matching services.TunnelConn.
The reverse tunnel server has been updated to handle heartbeats from
proxies as well as nodes. Proxy heartbeat behavior has not changed.
Heartbeats from nodes now add remote connections to the matching local
site. In addition, the reverse tunnel server now proxies connection to
the Auth Server for requests that are already authenticated (a second
authentication to the Auth Server is required).
For registration, nodes try and connect to the Auth Server to fetch host
credentials. Upon failure, nodes now try and fallback to fetching host
credentials from the web proxy.
To establish a connection to an Auth Server, nodes first try and connect
directly, and if the connection fails, fallback to obtaining a
connection to the Auth Server through the reverse tunnel. If a
connection is established directly, node startup behavior has not
changed. If a node establishes a connection through the reverse tunnel,
it creates an AgentPool that attempts to dial back to the cluster and
establish a reverse tunnel.
When nodes heartbeat, they also heartbeat if they are connected directly
to the cluster or through a reverse tunnel. For nodes that are connected
through a reverse tunnel, the proxy subsystem now directs the reverse
tunnel server to establish a connection through the reverse tunnel
instead of directly.
When sending discovery requests, the domain field has been replaced with
tunnelID. The tunnelID field is either the cluster name (same as before)
for proxies, or {nodeUUID}.example.com for nodes.
2019-04-26 20:51:59 +00:00
return clt , nil
}
2021-04-20 23:59:01 +00:00
func ( process * TeleportProcess ) newClientDirect ( authServers [ ] utils . NetAddr , tlsConfig * tls . Config ) ( * auth . Client , error ) {
var cltParams [ ] roundtrip . ClientParam
2018-04-08 21:37:33 +00:00
if process . Config . ClientTimeout != 0 {
2021-04-20 23:59:01 +00:00
cltParams = [ ] roundtrip . ClientParam { auth . ClientTimeout ( process . Config . ClientTimeout ) }
}
clt , err := auth . NewClient ( apiclient . Config {
2021-02-23 00:43:00 +00:00
Addrs : utils . NetAddrsToStrings ( authServers ) ,
Credentials : [ ] apiclient . Credentials {
apiclient . LoadTLS ( tlsConfig ) ,
} ,
2021-04-20 23:59:01 +00:00
} , cltParams ... )
if err != nil {
return nil , trace . Wrap ( err )
}
if _ , err := clt . GetLocalClusterName ( ) ; err != nil {
if err2 := clt . Close ( ) ; err2 != nil {
process . log . WithError ( err2 ) . Warn ( "Failed to close direct Auth Server client." )
}
return nil , trace . Wrap ( err )
}
return clt , nil
2018-04-08 21:37:33 +00:00
}