IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Due to the way our crypto library is implemented, it can't generate a
key from CA with ECDSA-SHA256 on older versions of Talos.
Talos >= 0.13: ECDSA-SHA256 with P-256
Talos < 0.13: ECDSA-SHA512 with P-256
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This fixes the instabilitiy on some of the internal resources, as they
get regenerated as a result of machine config changes. As map iteration
order is not stable this might cause unexpected static pod defition
regeneration with the only difference is the flag order.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Previously Talos used ECDSA-SHA512 with P-256 EC key, which is not
widely supported combination. Use ECDSA-SHA256 instead.
There's no security benefit to use ECDSA-SHA512 with P-256 key, and this
combination is officially supported by TLS 1.3 standard.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Only `jump` syncs are logged to the console and any errors syncing.
Regular `slew` syncs are suppressed (only visible in
`talosctl logs controller-runtime`).
The very first sync is always reported to console.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This breaks some pods which specifically drop everything but gain
capabilities back via file capabilities (e.g. `nginx-ingress`).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Our CI amd64 builders are 3-4 times faster to build Talos than our arm64
builders when building Talos.
Our Dockerfile was restructured a while ago to support cross-compilation
on all platforms but CI was still using amd64/arm64 workers, so arm64
part was done on arm64 builders.
As our CI runs on Talos, `binfmt_misc` is not enabled in the kernel, but
buildkit has built-in QEMU emulation layer which works just fine for
those small pieces which actually need to run arm64 binaries on amd64
(mostly `apk add` in the installer container). Interesting enough,
buildkit QEMU support fails for `ca-certificates` script which runs
after install. At the same time I believe we don't need
`ca-certificates` in the installer, as installer doesn't download
anything from the network, and `ca-certificates` were added a while ago
when installer was actually downloading configuration on its own.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
We use hacked version with a workaround for capability issues with
`--privileged` in Docker.
See moby/moby#42906
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Update component versions, Go module versions.
Add platform tiers to the support matrix.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4243
The idea is to make sure kubelet picks node IP based on filtering by
CIDRs of the node's addresses. The flow is simple - every address is
filtered by subnet and picked if it matches the subnet.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
If Talos is built with `sidero.debug` build tag (`make WITH_DEBUG=1`),
the machine configuration is allowed to use insecure HTTP for the discovery service.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
Also ignore expected errors for other platforms to keep controller from
failing over and over again.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4250
Each KubeSpan peer sees each other KubeSpan peer endpoint as it got
connected. If the peer is behind NAT, the discovered endpoint is
different from the endpoints node knows about itself (as it punched a
hole in NAT). This discovered endpoint is pushed to the discovery
service so that every other peer now can use that punched hole to talk
to the peer.
If the endpoint observed is actually in the list of the endpoints
reported by the peer itself, discovery service will take care of
deduplicating them and suppressing updates.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This means that ExternalIPs (as presented by the platform) will be
published as `AddressStatus` resource, and transitively as
`NodeAddresses` (which includes cert generation) and as KubeSpan
endpoints (for KubeSpan connectivity in the cloud).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This fixes a bug when after an error generating certificates controller
gets into a state of not being able to read its expected inputs
(NetworkStatus specifically).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Use `argsbuilder` same way as it's used in services.
Rewrite `kubeProxy` generation code to override default args.
As a consequence of this change now flags do not have determined order
as they all come from a single merged map.
Introduced merge policy in the `ArgsBuilder` to deny overrides for some
arguments and do additive merge of others.
Fixes: https://github.com/talos-systems/talos/issues/4238
Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
Looks like `zaptest` package when used from the goroutine (like in gRPC
server) results in a potential data race on test tear down.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This provides integration layer with discovery service to provide
cluster discovery (and transitively KubeSpan peer discovery).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This distributes API CA (just the certificate, not the key) to the
worker nodes on config generation, and if the CA cert is present on the
worker node, it verifies TLS connection to the trustd with the CA
certificate.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Talos supports automatic virtual IP for the control plane with pure
layer 2 connectivity. Hetzner Cloud API supports assigning Floating IPs
to the nodes, this PR combines existing virtual IP functionality with calls
to HCloud API to move the IP address on HCloud side to the leader node.
The only thing which should be supplied in the machine configuration is
the Hetzner Cloud API token, every other setting is automatically
discovered by Talos.
Talos supports two types of floating IPs:
* external Floating IP for external network
* server alias IP for local networks
The controlplane can have only one alias on the local network interface.
Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
That PR contains an example of how fuzz tests can be written with Go 1.18.
It also fixes a few panics with invalid configs.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
Fixes#4094
Deprecate old networkd APIs, `talosctl interfaces` and `talosctl routes`
now suggest different commands to be used to achieve same task.
TUI installer was updated to stop using Interfaces API.
Those APIs will be completely removed in 0.14.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This should fix lookup of CD-ROM devices.
Update `go-blockdevice` library to the version with the fix.
Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
This basically provides `talosctl get --insecure` in maintenance mode.
Only non-sensitive resources are available (equivalent to having
`os:reader` role in the Talos client certificate).
Changes:
* refactored insecure/maintenance client setup in talosctl
* `LinkStatus` is no longer sensitive as it shows only Wireguard public
key, `LinkSpec` still contains private key for obvious reasons
* maintenance mode injects `os:reader` role implicitly
The motivation behind this PR is to deprecate networkd-era interfaces &
routes APIs which are being used in TUI installer, and we need a
replacement.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Update `go-blockdevice` library.
Readwrite mode doesn't work when there are readonly devices like `iso`.
Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
This field is not marshalable, as it's technically an interface.
This will be used to save/load SecretsBundle as a whole in the CABPT.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Note: Talos can be still run under `Firecracker`, support for
Firecracker was only removed for `talosctl cluster create`.
Reason:
* code is untested/unmaintained, and probably doesn't work correctly
* firecracker Go SDK pulls lots of dependencies and it blocks CNI Go
module update
Bonus: `talosctl-linux-amd64` shrinks by 2 MiB.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4232
The result:
```
talosctl -n 172.20.0.2 get members
NODE NAMESPACE TYPE ID VERSION HOSTNAME MACHINE TYPE OS ADDRESSES
172.20.0.2 cluster Member talos-default-master-1 2 talos-default-master-1 controlplane Talos (v0.13.0-alpha.0-13-gfdd80a12-dirty) ["172.20.0.2","fdd1:f54:2697:3902:44f8:92ff:fe2e:1aea"]
172.20.0.2 cluster Member talos-default-worker-1 1 talos-default-worker-1 worker Talos (v0.13.0-alpha.0-13-gfdd80a12-dirty) ["172.20.0.3","fdd1:f54:2697:3902:d4ba:55ff:fe8a:f551"]
172.20.0.2 cluster Member talos-default-worker-2 1 talos-default-worker-2 worker Talos (v0.13.0-alpha.0-13-gfdd80a12-dirty) ["172.20.0.4","fdd1:f54:2697:3902:e00d:f4ff:fecf:51c8"]
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
The problem is that the kubelet kubeconfig gets created early, but the
actual client key and cert files are not written, so controllers spam
with scary errors that the config is not valid. This PR removes those
scary messages as we wait for the kubeconfig to be usable.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This fixes the bug with host networking pods not being able to reach out
to the Kubernetes services.
This also moves any node-to-node networking over to KubeSpan link as
well.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
