1. Docs
  2. Changes and releases
  3. Security

Security

  • Security falco-app v0.14.0

    Changed

    • Updated falco to upstream version v0.45.0.
    • Updated k8s-metacollector to upstream version v0.1.4.
    • Updated charts to upstream version falco-9.2.0.
  • Security starboard-exporter v1.2.19

    Fixed

    Full Changelog: https://github.com/giantswarm/starboard-exporter/compare/v1.2.18...v1.2.19

  • Security dex-app v3.2.2

    Fixed

    • A pre-defined static client (gitopsui, muster, mcpKubernetes, mcpCapi, mcpPrometheus) with both clientSecret and clientSecretRef uses the reference and ignores the inline value instead of failing the render: a client moves from an inline secret to a referenced Secret by adding the reference where the plaintext values live, even while the encrypted values still carry the old inline secret. The release notes (helm get notes) name such a client until the inline value is deleted. A client with neither is left out as in 3.2.1; dex-k8s-authenticator and extra static clients that are not public still need exactly one source.
  • Security dex-app v3.2.1

    Fixed

    • A pre-defined static client (gitopsui, muster, mcpKubernetes, mcpCapi, mcpPrometheus) with a clientID and neither clientSecret nor clientSecretRef is left out of the dex configuration again, as before v3.1.0, and named in the release notes, instead of failing the render: values shared by several installations can declare a client whose secret only some of them carry. Both sources on one client still fail the render naming the client; dex-k8s-authenticator and extra static clients that are not public still need exactly one. Clients with a secret render unchanged.
  • Security dex-app v3.2.0

    Added

    • Built-in static clients mcpCapi and mcpPrometheus (oidc.staticClients.mcpCapi, oidc.staticClients.mcpPrometheus) with the shape and rules of mcpKubernetes: clientID, redirectURI, trustedPeers, and exactly one of clientSecret and clientSecretRef: {name, key}; both are trusted peers of dex-k8s-authenticator. Values under these keys were accepted by the schema and ignored by the templates before: an installation that carries them gets the two clients with this version, and one that carries a clientID without a secret fails the render naming the client. Installations without them render unchanged.
  • Security dex-app v3.1.0

    Added

    • Static clients read their secret from a Kubernetes Secret: secretRef: {name, key} in an extraStaticClients entry, clientSecretRef: {name, key} in the pre-defined clients (gitopsui, muster, mcpKubernetes, dexK8SAuthenticator), in place of the inline secret. The chart sets DEX_CLIENT_SECRET_<ID> on the dex container from the referenced key and names it in the client’s secretEnv, so a client is added by a new Secret and a plaintext list entry. Exactly one of the inline secret and the reference per client: both, or neither on a client that is not public, fails the render naming the client. Inline clients render unchanged.

    Changed

    • A pre-defined static client with a clientID but no secret (gitopsui, muster, mcpKubernetes) fails the render naming the client instead of being left out of the configuration silently.
  • Security dex-app v3.0.1

    Fixed

    • Roll dex on a configuration change: the pod template carries a checksum/config annotation with the hash of the rendered dex configuration, so every change to it produces a new ReplicaSet in the same helm upgrade that writes the secret. The Deployment is rendered by the parent chart from the subchart’s template to compute the checksum; its output is unchanged apart from the annotation. Before, the pod kept the configuration it had loaded at startup until something else restarted it.
  • Security starboard-exporter v1.2.18

    Fixed

    Full Changelog: https://github.com/giantswarm/starboard-exporter/compare/v1.2.17...v1.2.18

  • Security starboard-exporter v1.2.17

    Fixed

    Full Changelog: https://github.com/giantswarm/starboard-exporter/compare/v1.2.16...v1.2.17

  • Security rbac-operator v1.2.0

    Added

    • RBAC: Grant the automation ServiceAccounts of all organization namespaces (org-<organization>) read-only access to cluster-scoped resources looked up at Helm render time by the cluster-* (release-*) charts. For this, a cluster-app-chart-lookups ClusterRole is created, plus a per-organization ClusterRoleBinding of the same name suffixed with the namespace.