There's a cyclic dependency on siderolink library which imports talos
machinery back. We will fix that after we get talos pushed under a new
name.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
We add a new CRD, `serviceaccounts.talos.dev` (with `tsa` as short name), and its controller which allows users to get a `Secret` containing a short-lived Talosconfig in their namespaces with the roles they need. Additionally, we introduce the `talosctl inject serviceaccount` command to accept a YAML file with Kubernetes manifests and inject them with Talos service accounts so that they can be directly applied to Kubernetes afterwards. If Talos API access feature is enabled on Talos side, the injected workloads will be able to talk to Talos API.
Closessiderolabs/talos#4422.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
With the advent of generics, redo pointer functionality and remove github.com/AlekSi/pointer dependency.
Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Having polymorphic (spec type depends on ID) resources is not a good
idea, and it's not compatible with protobuf encoding.
Introduce new resources for each polymorphic sub-spec using new Go 1.18
generic typed.Resource to reduce the boilerplate code.
(Still needs proper deepcopy-gen, but I'm skipping it for now, as
K8sControlPlane had also broken deep copy).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This continues the process of removing extra dependencies before moving
`pkg/resources` into machinery.
See also: #4420#4469
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4418
Only one resource (one of the very first ones) was polymorphic: its
actual spec type depends on its ID. This was a bad idea, and it doesn't
work with protobuf specs (as type <> protobuf relationship can't be
established).
Refactor this by splitting into three separate resource types:
`OSRoot` (OS-level root secrets), `EtcdRoot` (for etcd),
`KubernetesRoot` (for Kubernetes).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Use only one service for single/dual ip stack
Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This changes machinery API for the configuration to make it more
obvious that the returned value is a list of CIDRs and adjusts usage
accordingly.
For the K8s Address Filter controller, fix the actual bug by parsing
CIDRs as a list of values.
Fixes#4192
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This feature comes as PSP is deprecated and going to be removed in 1.25.
In preparation for that, add an option to disable PSP which was always
enabled in Talos by default.
To keep backwards compatibility, PSP is still enabled by default.
See also #3971
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Co-authored-by: Adam Szucs-Matyas <szucsitg@gmail.com>
Fixes: https://github.com/talos-systems/talos/issues/3556
Introduce `coredns.disabled` flag to the machine config that allows
turning off coredns deployment during cluster bootstrap.
Signed-off-by: Artem Chernyshev <artem.0xD2@gmail.com>
Route handling is very similar to addresses:
* `RouteStatus` describes kernel routing table state,
`RouteStatusController` reflects kernel state into resources
* `RouteSpec` defines routes to be configured
* `RouteConfigController` creates `RouteSpec`s based on cmdline and
machine configuration
* `RouteMergeController` merges different configuration layers into the
final representation
* `RouteSpecController` applies the specs to the kernel routing table
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Enable logging using default development config with some fine tuning.
Additionally, now `info` and below logs go to kmsg.
Signed-off-by: Artem Chernyshev <artem.0xD2@gmail.com>
This is mostly refactoring to adapt to the new APIs.
There are some small changes which are not user-visible immediately (but
visible when using `talosctl get` to inspect low-level details):
* `extras` namespace is removed, it was a hack to distinguish extra and
system manifests
* `Manifests` are managed by two controllers as shared outputs, stored
in the `controlplane` namespace now
* `talosctl inspect dependencies` output got slightly changed
* resources now have `md.owner` set to the controller name which manages
the resource
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
JSON is a subset of YAML, so we can use JSON to escape whole YAML value
to handle any kind of symbols.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This options drops kube-proxy manifest from the list of bootstrap
manifests. It might be used with CNIs which don't need `kube-proxy`.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Fixes#3062
There's no user-visible change in this PR.
It carefully separates generated secrets (e.g. certs) from source
secrets from the config (e.g. CAs), so that certs are generated on
config changes which actually affect cert input.
And same way separates etcd and Kubernetes PKI, so if etcd CA got
changed, only etcd certs will be regenerated.
This should have noticeable impact with RSA-based PKI as it reduces
number of times PKI gets generated.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This is required to upgrade from Talos 0.8.x to 0.9.x. After the cluster
is fully upgraded, control plane is still self-hosted (as it was
bootstrapped with bootkube).
Tool `talosctl convert-k8s` (and library behind it) performs the upgrade
to self-hosted version.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Control plane components are running as static pods managed by the
kubelets.
Whole subsystem is managed via resources/controllers from os-runtime.
Many supporting changes/refactoring to enable new code paths.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
