* Return worker process information in the health endpoint.
Experimental: The worker_info and returned worker_process_info fields are experimental and can change or be removed without notice.
When a user passes in "worker_info=1" or "worker_info=true" and a worker is running the returned json will be returned with a key named "worker_process_info" which value is a json object with information about the worker process.
* feat(workers): Add ability to read and reinitialize cert authority (#2312)
* feat(workers): Return Release Version on worker list and read (#2377)
* feat(cli): Read and reinitialize worker certificate authority (#2387)
* feat(workers): added latencies histogram for server side multihop workers
* refactor(daemon): combine common grpc metric functions into daemon/internal/metric
Co-authored-by: Todd <github@quaddi.com>
This adds an action to the API that allows pulling out an activation
token that can be given to a worker in its config (directly or via env
or file). The worker can pass this along with its normal request in
place of its normal nonce and the server will automatically accept it.
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>
On a SIGHUP, if the worker's `initial_upstreams` config option has
changed, it will use the new values as the address to send its status.
Any previously discovered upstream addresses from previous status
requests are dropped. Once a successful status request is made to the
new addresses, the worker will resume its normal behavior of using the
addresses from the response to the status request.
This allows a worker to be deployed in a more stable way in a dynamic
environment where controller IPs could change. In particular this helps
with a case where all controllers are replaced with new controllers
running on new IPs.
To illustrate with an example, suppose there is an instance group of
controllers instances. And there are worker instances that have their
config rendered from consul-template that sets `initial_upstreams` to
the IPs of the controller instances. If all controller instances are
restarted or replaced at the same time and assigned new IPs, a new
config will be rendered for the worker. Previously the only way for the
worker to use the new value would be for the worker process to be
restarted. Otherwise the worker would only know about the previous IPs
and would fail to connect to the new controllers. However, a restart
would mean any active sessions and session connections on the worker
instance would be terminated. With this update, consul-template can send
a SIGHUP to the worker, the worker will connect to the new controllers
and resume normal status reporting, allowing the sessions and session
connections to remain.
The same principles would apply for other examples of dynamic
environments such as nomad and kubernetes.
See:
https://github.com/hashicorp/consul-templatehttps://www.nomadproject.io/docs/job-specification/template
Although there is a compile time check on the type, it will always
succeed due to the Unimplemented embedding requirement.
As a result, this PR also changes Unimplemented calls to Unsafe calls,
which were added later "for those that prefer their code to break"; the
comments on these state:
// UnsafeXServiceServer may be embedded to opt out of forward compatibility for this service.
// Use of this interface is not recommended, as added methods to XServiceServer will
// result in compilation errors.
See https://github.com/grpc/grpc-go/issues/4500#issuecomment-852597871
for some more context.
I think we're fine with compilation errors though; we own both the
server and client side of things and generally are going to add new
methods only when we intend to also add them on the client side.
Notably, what the comment does not indicate is that it will break at
runtime; already it should return a suitable (404 or 405) error if the
client requests a method that does not exist.
The intention of the code was to have one-hop-away workers list KMS
workers to get initial upstreams, and have other workers continue using
what was in their config file. However, nothing stops people from having
initial_upstreams but _also_ adding a cluster ID in their config file,
in which case we'd always run this check and replace the config-set
initial upstreams. So, ensure the config-set initial upstreams is also
len zero.
* Clean up some dev config kms code
Although it didn't matter in the combined state, the KMS for auth
storage was not actually being set properly if only a worker was being
instantiated.
* feat(credentials): Refactor credential purposes
* Application credentials have been refactored to Brokered credentials
* Egress credentials have been refactored to Injected Application
credentials
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
Right now there is a bit of a race condition in that a status call that
indirectly tells the controller that a worker is ready to accept
sessions can have its response unable to be processed in time for an
actual session to come in from a client. It's very unlikely but
technically there.
This changes where we check if we have ever successfully authenticated
from the function called by the ticker to the ticker itself, allowing us
to reset the timer to a very short time if we have not yet
authenticated. We already have the initial timer set to 0 for "as soon
as possible" behavior, but if that initial status failed we'd wait for
the normal interval. Now we will instead continue with the "as soon as
possible" behavior, and reduce the very unlikely race condition to
extremely unlikely.
(There are more permanent fixes but those are bigger and can come
later.)
* (refactor) change all sql references of user_password to username_password
* refactor(pkg) renamed pkg userpassword to usernamepassword
* refactor(proto) updated protocol buffers to use UsernamePassword
* refactor(code) updated references from UserPassword to UsernamePassword in golang files
* refactor(test) updated unit tests to reference UsernamePassword changes
* refactor(ddtest) updated references in dbtests to use UsernamePassword
* chore(sql-test) fixed spelling issue
* chore(sql) added and updated comments in migartion & tables. fixed indentations
* chore(proto) updated comments to reflect username_password changes
* refactor(tests) updated unit tests to replace user-password with username-password
* refactor(cmd) updated cmd help text to use username
* chore(tests) update test name & comments
* fix(cmd) fixed cmd usage definition for credentials update
* refactor(tests) removed out of scope changes
* fix(sql) incremented sql migration id & updated migration comments
* fix (worker): send workerId when authorizing session
Send the workerId returned from the last success worker status
when authorizing a session.
* fixup! fix (worker): send workerId when authorizing session
* fixup! fix (worker): send workerId when authorizing session
* refactor (worker): deprecate workerId in ActivateSessionRequest
It wasn't being used anywho
* fixup! fix (worker): send workerId when authorizing session
* Update LookupSessionRequest
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
This essentially worked for non-dev mode before but would create storage
directories that weren't actually used or needed, and it didn't work in
dev mode because it made assumptions about the presence of a worker auth
kms or not. This fixes those behaviors.
* Don't automatically create worker names, as this is now invalid for
PKI workers
* Fix a check in dev that clears out name/description in exactly the
wrong cases
* Change eventing setup to use a hostname-based ID instead of the name
(which could change on every start anyways)
Irena Rindos
Jeff Mitchell
Louis Ruch
Todd
HaotianandTodd
Timothy Messier
Johan Brandhorst-Satzkorn
Jim
Damian Debkowski
irenarindos