Poznámky k verzím

Historie verzí platformy MazeVault

Verze dokumentu: 1.0.61 Last Updated: 2026-11-13

---

Verze 1.0.61

Datum vydání: Nevydáno

Změny distribuce (vyžadují akci)

• Agent vyžaduje URL backendu s https:// (zkontrolujte před upgradem agentů) — Agent, jehož server_url (MAZEVAULT_SERVER_URL) používá http://, se teď při startu zastaví s chybou konfigurace, pokud host není localhost ani loopback adresa: tímto spojením jdou tokeny, privátní klíče a tajemství. Agenty se vzdálenou http:// URL je nutné přepnout na https:// adresu backendu nebo gateway dřív, než se mohou aktualizovat: agent této nebo novější verze odmítne self-update, dokud by jeho vlastní URL tímto pravidlem neprošla, a odmítnutí nahlásí backendu (update_error ve stavu zdraví), ale agent starší než toto vydání aktualizaci nainstaluje a pak se nespustí a vzdáleně už není dosažitelný.
• Scopes API tokenů se vynucují, role s omezením CIDR platí (před upgradem zkontrolujte tokeny se scopes) — API token (mvt_…) vytvořený se scopes nově na každém endpointu s kontrolou oprávnění jedná jen v jejich rámci (dřív se scopes nekontrolovaly u žádného tokenu): CI token s ["secret:read"] už nezapíše ani nesmaže a token se scopes smí vytvářet další tokeny jen v rámci svých scopes. Token bez scopes má dál všechna práva vlastníka; webové rozhraní, Go SDK i Terraform provider vytvářejí tokeny bez scopes, pokud je nezadáte. Před upgradem zkontrolujte scopes tokenů, které používá CLI, SDK, Terraform provider nebo Kubernetes operátor: SELECT name, scopes FROM api_tokens WHERE is_active AND deleted_at IS NULL AND scopes IS NOT NULL AND scopes <> '{}';. IP klienta se nově předává kontrole oprávnění, takže role s omezením CIDR platí pro klienty uvnitř rozsahu (dřív neplatily nikdy) a vyhodnocuje se podmínka ip_whitelist u oprávnění prostředí. Za reverzní proxy nastavte TRUSTED_PROXY_CIDRS na adresy proxy: jen od nich se použije X-Forwarded-For (první adresa zprava, která není důvěryhodná proxy); požadavek s X-Forwarded-For nebo X-Real-IP od jiného peeru IP nedostane a role s omezením CIDR pro něj neplatí. Stejná proměnná zapíná i čtení klientského certifikátu mTLS z hlaviček X-Client-Cert / ssl-client-cert, proxy proto musí tyto hlavičky z požadavků klientů odstraňovat. Token vytvořený API tokenem vyprší nejpozději s ním a nekladná duration se odmítne s 400. Oprávnění prostředí s mfa_required dál neplatí nikdy, protože přihlašovací tokeny zatím stav MFA nenesou; oprávnění s time_range se vyhodnocuje při každém požadavku.
• Oprávnění pochází jen z přiřazení rolí (vyžaduje akci) — Role v přihlašovacím tokenu uživatele (users.role) už nic neuděluje: uživatel má právě oprávnění svých přiřazení rolí (globálních, organizačních nebo projektových). Dříve uživatel bez jakéhokoli přiřazení dostal oprávnění role users.role všude a uživatel, jemuž bylo omezené přiřazení odebráno (nebo byl smazán jeho projekt či organizace), je držel až do přesynchronizování. Uživatelé, kteří měli přístup jen přes users.role, ho po upgradu ztratí, a uživatelé SSO a LDAP založení bez odpovídajícího mapování skupin nemají žádná oprávnění, dokud jim role není namapována nebo přiřazena. Před upgradem dotčené uživatele vypište dotazem SELECT u.id, u.email, u.role FROM users u WHERE u.deleted_at IS NULL AND NOT EXISTS (SELECT 1 FROM user_roles ur WHERE ur.user_id = u.id); a každému přiřaďte roli v Řízení přístupu → Správa rolí (nebo POST /api/v1/rbac/users/{id}/roles s role_id a volitelným scope). Vestavěné účty administrátora dostanou přiřazení role admin automaticky při startu. Agentů, OAuth klientů a servisních identit se změna netýká.
• Politika verzí agenta nahrazuje proměnné prostředí s verzí agenta — Jakou verzi agenta který agent dostane, nově určuje politika verzí (Nasazení → Agenti → Politika verzí). AGENT_VERSION, AGENT_MAX_ALLOWED_VERSION a AGENT_ROLLOUT_PERCENTAGE jsou zastaralé: jednou při prvním startu primary naplní prázdnou politiku (pozdější změny jen zapíší varování o zastarání). Přišpendlené hodnoty se stanou cílovými verzemi a stropem, takže agentům s vyšší verzí bude nabídnut downgrade na ně — pokud to nechcete, smažte cíle/strop v politice nebo nastavte minimální verzi pro rollback. Gatewaye se řídí politikou z primary. Nová spodní hranice pro rollback agenta min_rollback_version omezuje, jak daleko lze agenta vrátit; zrušit ji lze příkazem reset-min-rollback-version.
• Agent zapisuje jen do povolených adresářů (zkontrolujte před upgradem agentů) — Soubory, které určí backend (keystore u certificate_sync, soubory certificate_file_sync, cíle secret_sync, keytaby keytab_deploy, obnovené certifikáty, souborové a JKS cíle pravidelné synchronizace), agent nově zapisuje jen do cert_store_path a do adresářů z nového nastavení agenta allowed_write_paths. Bez nastavení platí výchozí /etc/ssl, /etc/pki, /etc/letsencrypt, /etc/nginx/ssl, /etc/nginx/certs, /etc/apache2/ssl, /etc/httpd/ssl, /etc/haproxy/certs, /etc/krb5.keytab, /var/lib/mazevault/certs a /etc/mazevault/certs na Linuxu, C:\ProgramData\MazeVault\certs na Windows. Cesty musí být absolutní (relativní target_path u secret_sync se nově odmítne) a nesmí obsahovat ..; symbolické odkazy se před kontrolou rozvinou; vlastní konfigurace, identita a stav agenta takto zapsat nejdou nikdy. Před upgradem agenta doplňte do allowed_write_paths v jeho agent.yaml všechny další adresáře, které používají jeho cíle nasazení, synchronizace tajemství, keytabů nebo obnovené certifikáty (např. /opt/tomcat/conf nebo C:\inetpub\app); odmítnutá cesta ukončí požadavek chybou, která allowed_write_paths jmenuje; výjimkou je pravidelná synchronizace certifikátů (souborové a JKS cíle, metadata install_target), jejíž odmítnutí se objeví jen v logu agenta (/var/log/mazevault/agent.log nebo journal, na Windows C:\ProgramData\MazeVault\logs\agent.log) — po upgradu v něm hledejte allowed_write_paths. Relativní cert_store_path nebo položka allowed_write_paths nově zastaví start agenta chybou konfigurace. Na Windows se odmítnou junctiony a přípojné body v cestě zápisu. keytab_renew ignoruje output_path a keytab vždy generuje do soukromého dočasného souboru. operation_token obnovy agent přijme jen jako prosté jméno (písmena, číslice, -, _) a ID certifikátu, které agent po enrollmentu stahuje, posílá v URL escapované. Viz Nasazení agenta → Povolené adresáře pro zápis.
• Image, Helm chart a Compose kit se přesouvají do MazeVault Harboru — Od tohoto releasu se MazeVault distribuuje jen z registry.mazevault.com: image registry.mazevault.com/mazevault/mazevault-{backend,frontend,docs,ocsp,init-certs}:vX.Y.Z, Helm chart oci://registry.mazevault.com/mazevault/mazevault-customer (verze X.Y.Z) a Compose kit (instalátor, upgrade/rollback skripty, docker-compose.yml, .env.example, SHA256SUMS) jako OCI artefakt registry.mazevault.com/mazevault/compose-kit:vX.Y.Z, který se stahuje přes oras pull (skripty spouštějte přes bash, ORAS nezachovává příznak spustitelnosti). Každý zákazník dostane robot účet jen pro čtení; GitHub token ani stahování z raw.githubusercontent.com už nejsou potřeba. v1.0.60 a starší zůstávají na GHCR (ghcr.io/mazevault); stávající instalace si ponechají IMAGE_REGISTRY, dokud ho výslovně nezměníte (install-mazevault.sh --registry nebo hodnoty image.repository v chartu).
• Online instalátor používá docker-compose.yml z kitu — install-mazevault.sh už nezapisuje vlastní vloženou kopii compose souboru; nainstaluje docker-compose.yml, který leží vedle něj v Compose kitu (stejně jako už to dělal install-mazevault-offline.sh), a když chybí, skončí chybou, proto ho spouštějte z rozbaleného kitu. Online instalace znovu spuštěné s tímto releasem tak převezmou nastavení z kitu, např. MAZEVAULT_ENV_CANONICAL_ENFORCE (výchozí false); MAZEVAULT_CUSTOMER_NAME, MAZEVAULT_CUSTOMER_EMAIL a MAZEVAULT_COMPANY_ID musí být v .env neprázdné (instalátor je generoval vždy). Compose soubor z kitu přebírá health check backendu z kopie v instalátoru a frontend startuje, až je backend zdravý. Nové přepínače pro automatizaci: MAZEVAULT_NO_SYSTEMD=1 přeskočí systemd službu i všechna volání systemctl a MAZEVAULT_COMPOSE_PROJECT přepíše název projektu Compose (výchozí mazevault). Nově vygenerovaná systemd jednotka předává název projektu (-p) příkazům up i down; jednotka se generuje jen tehdy, když neexistuje, takže stávající /etc/systemd/system/mazevault.service si ponechá původní příkaz (pro přegenerování ji smažte a instalátor spusťte znovu).
• Vygenerované stacky pro gateway stahují backend z MAZEVAULT_IMAGE_REGISTRY (výchozí MazeVault Harbor) ve verzi primary a při instalaci vyžadují MAZEVAULT_GATEWAY_ENVIRONMENT.
• Customer Helm chart — prostředky External Secrets používají external-secrets.io/v1 (vyžaduje External Secrets Operator 0.16 nebo novější); backend za ingressem běží přes HTTP (MAZEVAULT_TLS_ENABLED=false); přístupový klíč Redisu je v REDIS_URL URL-kódovaný. Host dokumentace má vlastní Ingress <release>-docs (se stejným certifikátem) a nová hodnota global.ingress.docsAllowedSourceRanges ho omezí na uvedené klientské CIDR.
• API pro nasazení agentů — os_type: darwin a agent_mode: gateway|sidecar se odmítají s HTTP 400; podporovaní agenti jsou Linux a Windows.
• Certifikační autority: odebrány staré endpointy pro konfiguraci externí CA — POST /api/v1/ca/{id}/external/configure, POST /api/v1/ca/{id}/external/test, POST /api/v1/ca/{id}/external/templates/sync a POST /api/v1/projects/{id}/ca/{caId}/external/configure už neexistují (volání nyní vrátí HTTP 404); externí CA se konfigurují jako CA účty organizace. Migrace 000217 odstraní tabulky external_ca_configs a external_ca_template_mappings a případné řádky ponechá v mazevault_internal pro svou down migraci.
• Integrace Azure Key Vault: metoda autentizace Default Credential Chain je odebrána (zkontrolujte před upgradem) — Krok Auth Method integrace Azure Key Vault nabízí On-Behalf-Of, Managed Identity a Client Secret (interaktivně) a Client Secret a Managed Identity (na pozadí). API, a tedy i Terraform resource mazevault_integration, vrací 400 pro default v interactive_auth_method, background_auth_method nebo config.auth_method při vytvoření, úpravě i testu připojení. Migrace 000211 nastaví u existujících integrací Azure Key Vault místo default hodnotu client_secret a vypne je s chybou poslední synchronizace Disabled by migration 000211: the Default Credential Chain auth method was replaced by Client Secret; choose Managed Identity or Client Secret and enable the integration; každou upravte, zvolte Managed Identity nebo Client Secret (s tenant ID, client ID a secretem app registrace) a znovu ji zapněte. Před upgradem je vypíše SELECT id, project_id, environment, name FROM project_integrations WHERE provider IN ('azure', 'azure_keyvault', 'azure_key_vault') AND (interactive_auth_method = 'default' OR background_auth_method = 'default');. Její down migrace obnoví předchozí hodnoty z mazevault_internal.migration_000211_default_auth_method_backup. Metoda autentizace Azure, kterou server nezná (např. překlep v config.auth_method), skončí chybou unsupported Azure auth method a integrace bez metody a bez klientských údajů chybou no Azure auth method configured; vlastní identita serveru v Azure se místo nich nepoužije. Preflight rotace nově zablokuje i rotaci, jejíž cíl propagace do Key Vault nebo post-rotační akce Key Vault míří na vypnutou integraci. Viz Konfigurace identit a oprávnění Azure, sekce 9.2.
• SSO: typ poskytovatele OIDC / OAuth2 je odebrán — Nastavení organizace → SSO už nenabízí OIDC / OAuth2; nebylo za ním žádné přihlášení. API, a tedy i Terraform resource mazevault_identity_provider, při vytvoření přijme jako type jen entra_id a ldap a pro jakoukoli jinou hodnotu, včetně oidc, vrací 400; Terraform resource jiný type odmítne už při terraform plan. Migrace 000212 smaže existující poskytovatele identit typu oidc stejně jako API (soft delete); její down migrace je obnoví z mazevault_internal.migration_000212_oidc_identity_provider_backup. Přihlašujte se přes Microsoft Entra ID (které používá OpenID Connect) nebo LDAP.
• SSO: přihlášení přes SAML 2.0 je odebráno — Nastavení organizace → SSO už nenabízí SAML 2.0 a endpointy GET /api/v1/auth/saml/metadata, GET /api/v1/auth/saml/login a POST /api/v1/auth/saml/callback už neexistují. API, a tedy i Terraform resource mazevault_identity_provider, vrací 400 pro type: saml při vytvoření. Migrace 000213 smaže existující poskytovatele identit typu saml stejně jako API (soft delete); její down migrace je obnoví z mazevault_internal.migration_000213_saml_identity_provider_backup. Uživatelé, kteří se přihlašovali přes SAML, si účty ponechají a přihlásí se přes Microsoft Entra ID nebo LDAP se stejnou e-mailovou adresou.
• SSO: přihlášení přes GitHub je odebráno — Endpointy GET /api/v1/auth/sso/github/login a GET /api/v1/auth/sso/github/callback už neexistují, Nastavení organizace → SSO už nenabízí GitHub a backend už nečte GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET a GITHUB_REDIRECT_URI; odeberte je z prostředí nebo úložiště tajemství. API, a tedy i Terraform resource mazevault_identity_provider, vrací 400 pro type: github při vytvoření. Migrace 000214 smaže existující poskytovatele identit typu github stejně jako API (soft delete), přesune GitHub identity uživatelů do zálohy a smaže rozpracované stavy přihlášení přes GitHub; její down migrace obnoví poskytovatele i identity z mazevault_internal. Uživatelé, kteří se přihlašovali přes GitHub, si účty ponechají a přihlásí se přes Microsoft Entra ID nebo LDAP se stejnou e-mailovou adresou. Integrace pro synchronizaci tajemství do GitHubu se nemění.
• SSO: přihlášení přes GitLab je odebráno — Endpointy GET /api/v1/auth/sso/gitlab/login a GET /api/v1/auth/sso/gitlab/callback už neexistují, Nastavení organizace → SSO už nenabízí GitLab a backend už nečte GITLAB_CLIENT_ID, GITLAB_CLIENT_SECRET, GITLAB_REDIRECT_URI a GITLAB_BASE_URL; odeberte je z prostředí nebo úložiště tajemství. API, a tedy i Terraform resource mazevault_identity_provider, vrací 400 pro type: gitlab při vytvoření; SSO se nastavuje typem entra_id nebo ldap. Migrace 000215 smaže existující poskytovatele identit typu gitlab stejně jako API (soft delete), přesune GitLab identity uživatelů do zálohy, smaže rozpracované stavy přihlášení přes GitLab a odebere nepoužívané sloupce github_org, github_team_restrictions a gitlab_group_restrictions tabulky identity_providers po zkopírování jejich hodnot do zálohy; její down migrace vše obnoví z mazevault_internal. Migrace 000216 pak odebere tabulku auth_identities, která obsahovala jen vazby na přihlášení přes GitHub a GitLab, po zkopírování zbylých řádků do mazevault_internal. Uživatelé, kteří se přihlašovali přes GitLab, si účty ponechají a přihlásí se přes Microsoft Entra ID nebo LDAP se stejnou e-mailovou adresou. Integrace pro synchronizaci tajemství do GitLabu se nemění.
• Endpoint pro import tajemství odstraněn — POST /api/v1/projects/{id}/secrets/import byl odstraněn spolu s náhledovou záložkou External Migrations v nastavení organizace. Tajemství se vytvářejí přes POST /api/v1/secrets a aktualizují přes PUT /api/v1/secrets/{id}; export (GET /api/v1/projects/{id}/secrets/export) se nemění.
• SCEP enrollment vyžaduje challenge password (bezpečnostní oprava, zkontrolujte před upgradem) — Enrollment přes PKIOperation na /api/v1/scep/<ca_id> dosud podepsal interní CA každý CSR bez jakékoli kontroly, takže kdokoli, kdo endpoint dosáhl, získal klientský certifikát vaší CA. Nově ho autorizuje challengePassword v CSR, který se musí shodovat s novou proměnnou backendu SCEP_CHALLENGE_PASSWORD (jedna hodnota pro všechny interní CA; v Helmu global.keyVault.secretKeys.scepChallengePassword). Po upgradu proměnná nastavená není, a proto se každý SCEP enrollment odmítne (podepsaný CertRep FAILURE / badRequest, žádný certifikát; backend při startu zaloguje SCEP enrolment disabled a u každého odmítnutého požadavku varování). Pokud SCEP používáte (např. Intune, Jamf, sscep), nastavte SCEP_CHALLENGE_PASSWORD na silnou náhodnou hodnotu a stejné challenge nastavte v SCEP klientech/profilech; GetCACaps a GetCACert se nemění. Nastavením proměnné se SCEP zapne pro interní CA všech organizací a kdokoli, kdo hodnotu zná, se může zaregistrovat u kterékoli z nich: v nasazení s více organizacemi ji nastavte jen tehdy, když si všechny organizace navzájem důvěřují, jinak nechte SCEP vypnutý. Certifikáty dříve vydané přes SCEP zůstávají platné; projděte je a ty, které nepoznáváte, zneplatněte.
• Terraform: změny, které API neumí provést, nově plánují nahrazení nebo plán odmítnou (před apply zkontrolujte terraform plan) — Několik atributů Terraformu šlo změnit na místě, přestože je backend změnit neumí: apply buď skončil chybou („Provider produced inconsistent result“, „Update not supported“), nebo ohlásil úspěch a změnu tiše zahodil. Nově vynucují nahrazení (zničení a nové vytvoření): mazevault_secret.project_id, key a environment; mazevault_api_token.name, scopes a duration; mazevault_shared_secret.ttl_hours a max_views; mazevault_group_mapping.group_name a role_id; všechny argumenty mazevault_secret_link; project_id u mazevault_integration, mazevault_integration_group a mazevault_consistency_group; mazevault_hsm_device.provider_type. S nahrazeným zdrojem se nahradí i všechny zdroje, které na něj odkazují (např. odkazy secretů nahrazené integrace). Nahrazení secretu smaže jeho historii verzí a znovu zapíše hodnotu z konfigurace: secret s generate dostane novou náhodnou hodnotu a hodnota rotovaná na serveru se vrátí na nakonfigurovanou. Nahrazení API tokenu odvolá starý token a vydá novou hodnotu (zvažte lifecycle { create_before_destroy = true }) a nahrazený sdílený odkaz se neodvolá (sdílení nejde smazat): platí vedle nového, dokud nevyprší nebo není vyzvednut. Dvě změny nově skončí chybou už při plánu, protože nahrazení by bylo destruktivní nebo nemůže uspět: mazevault_project.organization_id (API projekt přesunout neumí; nahrazení by smazalo projekt se všemi secrety: založte nový projekt a secrety převeďte) a display_name, description a permissions u mazevault_role při stejném name (API roli neumí změnit ani smazat: změňte ji v MazeVault, nebo jí dejte nové name, které vytvoří novou roli). Role bez description po refreshi nově neukazuje změnu (ani když ji starší verze provideru uložila jako ""), změna jen velikosti písmen v project_id nebo role_id nic nenahradí, role převzatá po „role already exists“ musí odpovídat konfiguraci a role_id, organization_id a project_id načtené v jiné velikosti písmen nově neukazují změnu. mazevault_group_mapping při update nově ukládá plánované hodnoty místo předchozího stavu. environment u mazevault_secret nenechávejte prázdné: backend prázdné uloží jako dev a další plán by secret nahradil.
• Certifikáty vznikají vždy v projektu (volající API: zkontrolujte před upgradem) — Každá cesta API, která certifikát vytváří nebo importuje, nyní potřebuje projekt: POST /api/v1/certificates/import, /import/bulk a /import/file (včetně PFX) a POST /api/v1/certificates/csr od uživatele odpoví bez project_id HTTP 400 project_id is required (UI ho posílalo vždy; převzetí nalezeného certifikátu a POST /api/v1/projects/{id}/csr ho vyžadovaly už dřív). Posílejte project_id; v Terraformu nastavte project_id u mazevault_certificate, v CLI použijte mazevault certs request --project <id> (přepínač nahrazuje povinný --agent). Netýká se to mTLS registrace agenta, Kubernetes controlleru agenta ani mTLS certifikátů gatewaye. Certifikáty bez projektu ze starších importů nepatří žádné organizaci: vidí a spravuje je jen globální role, role organizace nebo projektu dostane 403 a import téhož certifikátu do projektu je odmítnut, místo aby si ho přivlastnil. Globální administrátor takový certifikát přiřadí projektu přes PUT /api/v1/certificates/{id} (project_id); od té doby ho spravuje organizace projektu.
• Synchronizace mezi datacentry: mění se formát událostí (aktualizujte všechna datacentra najednou) — Synchronizační události mezi datacentry (POST /api/v1/sync/events, GET /api/v1/sync/events, GET /api/v1/sync/entities/{id}) nově nesou data entity včetně šifrované hodnoty secretu a potvrzení (POST /api/v1/sync/ack) se ukládají. Dřív události žádná data nenesly a každé potvrzení selhalo, takže se nereplikoval žádný secret, certifikát ani jiná entita a tytéž události se posílaly pořád dokola. Replikovaná entita má ve všech datacentrech stejné id a replikovaná změna už nemaže hash hesla uživatele ani další pole, která událost nenese. Na primáru i na všech gatewayích musí běžet stejné vydání: datacentrum staršího vydání nové události neodešle ani nepoužije. Po aktualizaci primár odešle i události uložené dříve (události, které datacentrum už přijalo, přeskočí); událost secretu uložená před aktualizací neobsahuje hodnotu, takže secret, který přijímajícímu datacentru chybí, z ní nevznikne a zreplikuje se při své další změně. V instalaci, která už synchronizovala, má každá gateway uloženou první dávku (až 100 událostí) bez dat a teď ji přeskočí, takže uživatelé, role, organizace, projekty a certifikáty z ní se nezreplikují, dokud se nezmění: po aktualizaci všech datacenter je na primáru znovu uložte (rekonciliace nepomůže, obě strany mají stejné kontrolní součty událostí). Secret, který rekonciliace stáhne z primáru staršího vydání bez hodnoty, se uloží jako names_only. Všechna datacentra musí jako dosud používat stejný šifrovací klíč (MAZEVAULT_MASTER_KEY). Odpovědi API šifrovanou hodnotu nikdy neobsahují a přehled synchronizace (/api/v1/sync-dashboard/events) vypisuje události bez jejich dat. Cache secretů v Redisu nově obsahuje šifrovanou hodnotu cachovaných secretů (ciphertext pod MAZEVAULT_MASTER_KEY, nikdy plaintext).
• Go SDK: při vytváření cíle rotace nastavte Enabled a SyncOnSuccess (vyžaduje akci) — POST /secrets/{id}/rotation/targets bere vynechané enabled nebo sync_on_success jako true, ale struktura požadavku v Go SDK posílá obyčejné booleany bez omitempty, takže volající, který je nenastaví, pošle false a dostane vypnutý cíl, který se nikdy nesynchronizuje (dříve výchozí hodnota v databázi toto false změnila na true). V kódu, který cíle rotace přes SDK vytváří, nastavte obě pole výslovně (Enabled: true, SyncOnSuccess: true).
• OCSP responder: X-Forwarded-For se věří jen od TRUSTED_PROXIES; limity požadavku (zkontrolujte rate limit za proxy) — Rate limit OCSP responderu na IP (RATE_LIMIT_ENABLED, RATE_LIMIT_BY_IP) už nevěří hlavičce X-Forwarded-For dodané klientem, kterou šlo limit obejít jinou hodnotou u každého požadavku: klíčem je adresa protistrany, pokud není uvedena v nové proměnné TRUSTED_PROXIES (IP adresy nebo CIDR oddělené čárkou; Helm ocsp.config.TRUSTED_PROXIES, Compose kit OCSP_TRUSTED_PROXIES), a pak první adresa zprava v hlavičce, která není důvěryhodnou proxy. Za reverzní proxy nebo load balancerem nastavte TRUSTED_PROXIES na její adresy, jinak sdílejí všichni klienti jeden bucket proxy. POST tělo větší než 64 KiB je odmítnuto s 413, POST Content-Type s parametry (application/ocsp-request; charset=binary) se přijímá a GET / odpovídá 400 Missing OCSP request.
• OCSP responder: kratší cache odpovědí (CACHE_TTL výchozí 1 minuta) a obnova registru CA — Responder ukáže revokaci nejpozději po CACHE_TTL, protože responder běží samostatně a o revokaci se nedozví: výchozí hodnota (i hodnota v Helm chartu a Compose souborech) klesá z 10 minut na 1 minutu; vyšší CACHE_TTL nastavujte jen tehdy, je-li delší okno přijatelné. Klienti si ale dřívější odpověď good mohou ponechat do jejího nextUpdate (RESPONSE_VALIDITY, výchozí 1 hodina). Responder nově načítá certifikační autority každých CA_REFRESH_INTERVAL (výchozí 5 minut, 0 vypíná), takže nová nebo obnovená CA se obsluhuje bez restartu a neúspěšné načtení ponechá dosavadní CA. Nepodepsaná odpověď unauthorized (neznámá CA) se už necachuje navždy.
• OCSP responder: kontrola klíče, vrácení nonce a hlášení HSM — Responder odmítne podepsat (odpoví internalError a chybu zaloguje), když soukromý klíč CA neodpovídá jejímu certifikátu, místo aby vracel odpověď s neplatným podpisem. Požadavek s rozšířením nonce (RFC 8954) dostane v odpovědi stejné nonce (takové odpovědi se necachují); nonce delší než 32 oktetů se odpoví malformedRequest. Certifikační autority s hsm_enabled se hlásí už při načtení (řádek logu OCSP: CA … is unavailable a gauge ocsp_unavailable_cas), dokud není nakonfigurován HSM signer; žádný HSM provider zatím není implementován, takže taková CA nadále odpovídá internalError.
• Go SDK a Terraform: nasazení nesou organizaci, nová ID importu, rotační workflow v celých dnech (vyžaduje akci u volajících SDK a importů) — Backend bere organizaci nasazení agenta z těla při vytvoření a z ?organization_id= při výpisu, ale Go SDK neposílalo ani jedno, takže vytvoření nasazení skončilo 403 a čtení 400; mazevault_deployment nasazení nevytvořil ani neobnovil. Nekompatibilní změny Go SDK: CreateDeploymentRequest má nové pole OrganizationID (vyplňte ho), ListDeployments(organizationID) a GetDeployment(id, organizationID) berou organizaci. CreateRotationWorkflowRequest má nové pole Environment: CreateRotationWorkflow ho uloží aktualizací hned po vytvoření (endpoint pro vytvoření ho nepřijímá) a RotationWorkflowDetail.Resource.EnvironmentScope ho vrací. Terraform: mazevault_rotation_workflow.environment se nově posílá a čte zpět (nikdy se neposílal, takže každý refresh ukázal změnu) a ttl_hours musí být kladný násobek 24, protože backend ukládá celé dny (24 h → 1 den). Dříve se ttl_hours = 36 bez upozornění uložilo jako 1 den; taková konfigurace nově selže v plánu, upravte ji na násobek 24. ID importu: mazevault_deployment se importuje jako <organization_id>/<deployment_id> a mazevault_certificate_template jako <project_id>/<template_id>; samotné ID, které se používalo dřív, se odmítne. Po importu obnoví mazevault_ca atributy name a valid_years, mazevault_certificate_template atributy type a validity_period (jako <n>d), mazevault_integration atributy project_id a environment a mazevault_rotation_workflow atributy environment a ttl_hours, takže další plán importovaný objekt nenahrazuje.
• SSO: zřizování uživatelů přes SCIM je odebráno — Nastavení organizace už nenabízí zřizování uživatelů přes SCIM a jeho záložka SSO & Provisioning se nyní jmenuje SSO. Endpointy SCIM 2.0 pod /api/v1/auth/scim/{providerID}/ (Users, Groups a ServiceProviderConfig) už neexistují, takže poskytovatel identit, který na ně stále odesílá data, dostane 404; odeberte zřizování přes SCIM ze své aplikace v Microsoft Entra ID nebo Okta. Migrace 000299 odebere tabulky external_identities a external_group_memberships, které obsahovaly uživatele a skupiny odeslané přes SCIM, a odstraní hash SCIM tokenu (scim_token_hash) z konfigurace poskytovatelů identit; zdrojem těchto dat zůstává poskytovatel identit a down migrace obnoví jen prázdné tabulky a sloupce. Uživatelé vytvoření přes SCIM si účty ponechají; přes Microsoft Entra ID se přihlásí, pokud je jejich uložené externí ID jejich ID objektu Entra nebo pokud se už dříve přihlásili přes Entra SSO, jinak potřebují jednorázové propojení popsané v položce Entra ID SSO: nonce vždy vynucený, žádné propojování podle e-mailu. Stejná migrace odebere sloupce users.deactivated_at a users.scim_provider_id, které přidává migrace 000223 této verze; na instalaci, na které běžela předběžná verze s deprovisioningem přes SCIM, se uživatelé deaktivovaní přes SCIM přesunou do Archivu a jejich API tokeny se vypnou.
• Přihlašovací stránka: tlačítko Google je odebráno — Přihlašovací stránka už nezobrazuje tlačítko Google; nebylo za ním žádné přihlášení (endpoint neexistoval). google už není uvedeno mezi hodnotami provider uživatele ve schématu API. Přihlaste se lokálním účtem, přes LDAP nebo Microsoft Entra ID.

Odstranění (vyžadují akci)

• Rotace: skripty a přímé URL agentů se už nespouštějí ze serveru MazeVault (zkontrolujte před upgradem) — Post-rotační akce shell_script nově běží jen na gateway: nastavte u akce gateway_id (přes API nebo Terraform). Bez něj server MazeVault akci odmítne (shell_script runs only on a gateway), místo aby skript spustil na vlastním hostu se svým prostředím; platí i pro rollback_script. Post-rotační akce certifikátů se na gateway nedelegují, takže certifikátová akce shell_script teď vždy selže: nahraďte ji akcí agent_command na registrovaném agentovi. Přímý cíl agent_url u kroků agent_secret_sync, agent_command a iis_recycle je odebrán: žádný agent MazeVault tato volání neobsluhoval a odcházela bez autentizace, proto server takovou akci odmítne (direct agent_url targets are no longer supported) dřív, než cokoli odešle, i když konfigurace integrace nese jen agent_url / gateway_url a žádného agenta. Použijte agent_id registrovaného agenta (nebo integraci navázanou na agenta). Preflight rotace zablokuje post-rotační akci s přímým agent_url (agent_url_unsupported), nastavení rotace Entra ji odmítne uložit a záložka rotace certifikátu už nenabízí Direct Agent URL. Stávající konfigurace se nemění; dotčené najde SELECT 'secret' AS kind, id FROM rotation_configs WHERE post_rotation_actions::text LIKE '%agent_url%' OR post_rotation_actions::text LIKE '%shell_script%' UNION ALL SELECT 'certificate', id FROM certificate_rotation_configs WHERE post_rotation_actions::text LIKE '%agent_url%' OR post_rotation_actions::text LIKE '%shell_script%' UNION ALL SELECT 'template', id FROM rotation_config_templates WHERE post_rotation_actions::text LIKE '%agent_url%' OR post_rotation_actions::text LIKE '%shell_script%' UNION ALL SELECT 'entra_credential', id FROM entra_credentials WHERE extended_rotation_config LIKE '%agent_url%'; a upravte je před další rotací. Přístup ke gateway zatím není omezený podle organizace: kdo smí upravit post-rotační akce rotace, může zadat libovolnou gateway, proto do opravy omezte, kdo má secret:rotate.
• SSH Management odstraněn — Stránka Enterprise Functions → SSH Management a vše, co sloužilo jen jí, je odstraněno: páry SSH klíčů, nasazení a revokace authorized-key, objevování SSH klíčů, SSH CA a konfigurace rotace SSH, záložka SSH Keys v Access Control, sekce SSH v Reportech a SSH řádky a odkazy v pohledech rotace. Endpointy /api/v1/ssh/* a /api/v1/users/{id}/ssh-keys, agentní endpointy /agents/me/ssh-discovery a /agents/me/authorized-keys/*, druh rotačního prostředku ssh_key_pair, licenční funkce ssh_management, oprávnění ssh:* a vestavěná role ssh_admin zanikají. Terraform provider již neuvádí ssh_key_pair / ssh_key jako druhy rotačních prostředků. Privátní SSH klíče, které ještě potřebujete, exportujte před upgradem: migrace 000218_remove_ssh_management smaže všechny páry SSH klíčů (včetně šifrovaných privátních klíčů), nasazení authorized-key, objevené klíče, vydané SSH certifikáty, konfigurace rotace SSH a historii rotací a schvalování ssh_key_pair a odebere ssh:* z rolí, oprávnění prostředí, API tokenů a OAuth klientů. Down migrace obnoví jen prázdné tabulky.
• Klíč SSH CA vyřazen a jeho privátní klíč smazán — Migrace 000218 vyřadí všechny verze systémového klíče SSH CA (ssh_ca) a smaže jeho privátní klíč; klíč zůstává v System Keys viditelný jako vyřazený a Rotate je u něj odmítnuto. Privátní klíč pak existuje jen v zálohách databáze pořízených před upgradem. Již podepsané SSH certifikáty platí až do své expirace. Odeberte TrustedUserCAKeys /etc/ssh/mazevault_ca.pub (nebo ekvivalent) ze sshd_config na svých serverech.
• Klíče již nasazené na servery tam zůstávají — MazeVault již nenasazuje ani nerevokuje záznamy v authorized_keys. Dříve nasazené klíče, včetně těch, které dosud čekají na revokaci, se ze serverů neodstraní; ukliďte je ručně. Upgradujte také agenty: starší agenti dál fungují, ale při každém cyklu discovery zalogují 404 pro volání SSH discovery a authorized-key.
• Co zůstává — Projekty typu ssh, typ certifikátu SSH u CA providerů (např. Smallstep), ukládání SSH klíčů jako běžných tajemství nebo klíčů, auditní logy a záznamy key custody o SSH klíčích. Stávající HSM zařízení se scope ssh_keys jej mají dál, pro nová zařízení se však tento scope již nenabízí.
• Governance Import odstraněn — Záložka Governance Import v Organization Settings → System Outputs je odstraněna, spolu s nahráváním reportů z auditních nástrojů, jejich načtenými požadavky na politiky, analýzou odchylek (drift) vůči nim a trendem odchylek. Endpointy /api/v1/governance/* (reporty, analýza, drift, trend driftu a JSON schéma reportu) vracejí 404. Migrace 000220 odstraní tabulky governance_reports a governance_drift_snapshots, nahrané reporty a historie odchylek se tedy smažou; poté existují jen v zálohách databáze pořízených před upgradem. Ostatní záložky System Outputs se nemění.
• Nepoužívané zástupné endpointy sync-config certifikátů odstraněny — GET/PUT /api/v1/organizations/{id}/sync-config, GET/PUT /api/v1/projects/{id}/sync-config a POST /api/v1/projects/{id}/sync-config/set-master jsou odstraněny a vrací 404. Hlásily úspěch, ale nic neukládaly ani nevracely, a nevolalo je webové rozhraní, SDK, CLI ani Terraform provider; nastavení synchronizace projektu zůstává na /api/v1/projects/{id}/sync-settings.

Nové funkce

• Balíčky agenta (.deb, .rpm, .msi) — Agenta lze instalovat vlastními nástroji z podepsaných systémových balíčků: .deb a .rpm pro Linux amd64 a arm64, .msi pro Windows x64. Stáhnete je v Nasazení → Nasadit → Instalace z balíčků nebo přes GET /api/v1/agent-packages (oprávnění deployment:read); agenta zapíšete příkazem mazevault-agent enroll nebo vlastnostmi MSI SERVER_URL a BOOTSTRAP_TOKEN. Po instalaci se agent dál aktualizuje sám podle politiky verzí. MSI zatím není podepsané Authenticode. Image backendu obsahuje balíčky své vlastní verze agenta; ostatní verze se stahují z MazeVault Harboru (agents/agent-packages). Viz Nasazení agenta → Instalace z balíčků.
• Platnost a limit použití tokenu deploymentu — Deployment může nastavit, jak dlouho platí jeho bootstrap token (expires_in_days: 1–3650, 0 = bez expirace; výchozích 30 dní jako dosud) a kolik agentů se s ním smí registrovat (max_uses, 0 = bez omezení), v UI, v API i v Terraform resource mazevault_deployment. UI upozorní na token bez expirace nebo bez limitu použití.
• systemd unita agenta — Unita, kterou zapisuje instalační skript a kterou obsahují balíčky, nyní spustí agenta jen tehdy, když existuje /etc/mazevault/agent.yaml nebo předvyplněný soubor /etc/mazevault/enroll.conf.
• Role pro service identity — Service identitě lze nově přidělit role: POST /api/v1/service-identities/{id}/roles, GET na stejné cestě a DELETE /api/v1/service-identities/{id}/roles/{assignmentId} (oprávnění role:assign / role:read nad identitou), nový dialog Role na stránce Service Identities, Go SDK (AssignServiceIdentityRole, GetServiceIdentityRoles, RemoveServiceIdentityRole) a Terraform resource mazevault_service_identity_role. Role platí jen v organizaci identity nebo v jednom z jejích projektů; globální rozsah nebo rozsah v jiné organizaci je odmítnut s 400 a identita bez organizace role nedostane. Stejně jako u uživatelů lze přidělit nebo odebrat jen roli, jejíž oprávnění v daném rozsahu máte sami (jinak 403). Odebrání platí od dalšího požadavku identity. Role, která se náhodou jmenuje service, už neplatí pro každou service identitu přes roli v tokenu: identita má jen role, které jí byly přiděleny. Migrace 000250 přidává do service_identity_roles sloupec organization_id; řádky zapsané tam mimo API před upgradem se omezí na organizaci identity: řádek bez projektu dostane organizaci identity, řádek identity bez organizace nebo s projektem či organizací jiné organizace se smaže a každý ponechaný i smazaný řádek je vypsán jako varování v logu PostgreSQL. Engine oprávnění navíc ignoruje každý řádek role identity mimo organizaci identity.
• Terraform Provider: onboarding čerstvé instalace — Provider nyní pokrývá nastavení organizace, které dosud vyžadovalo UI. mazevault_config_template odpovídá kontraktu Configuration Managementu (template_type + JSON definition, backend jej validuje už při plánu; dřívější argumenty content/format proti API nikdy nefungovaly). Nový mazevault_project_template spravuje Project Templates kategorií secrets/keys, mazevault_entra_integration_scope vybírá aplikace Entra ID, které projektová integrace spravuje (se synchronizací z Graphu po apply), a data source mazevault_entra_app_registration dohledá ID credentialů pro mazevault_entra_rotation_config. mazevault_ca_account získal write-only mapu credentials pro self-hosted CA (Smallstep, ADCS, Vault, EST) a odmítá klíče vypadající jako tajemství v plaintextových settings. mazevault_certificate získal key_storage_mode, key_integration_id a key_secret_name, takže privátní klíče generované na serveru lze odložit do secret manageru (v Orchestrator Mode povinné). Viz Terraform Provider pro MazeVault → Onboarding čerstvé instalace.
• Efektivní řetězec certifikátu: podřízené CA se exportují včetně rootu — Export podřízené CA (nebo jakéhokoliv certifikátu) importované bez řetězce vydavatelů nyní automaticky obsahuje vydávající CA i root, pokud je vydavatel přítomen v inventáři organizace. Nový CertificateChainResolver je jediným zdrojem pravdy pro efektivní řetězec: řetězec zachycený na záznamu při importu nebo vydání se vrací byte po bytu a nikdy se nerozšiřuje; pouze certifikáty bez uloženého řetězce se doplňují z CA certifikátů spravovaných v téže organizaci (včetně interní CA a explicitní vazby záznamu na CA) a kandidát je přijat výhradně tehdy, když kryptograficky ověří podpis certifikátu — shoda Distinguished Name sama o sobě dva certifikáty nikdy nepropojí. Root se zahrnuje, archivovaní kandidáti se ignorují, revokovaný vydavatel se použije jen tehdy, když nic jiného neověří, a je hlášen jako varování; vydavatelé s nebezpečným podpisovým algoritmem jsou odmítnuti s varováním. Tentýž řetězec používá export API (include_chain=true, všechny formáty), detail certifikátu (záložka Chain nově zobrazuje původ — Stored with certificate / Resolved from inventory / No chain — plus úplnost k rootu a varování), seznam certifikátů pro agenta i Terraform data source, takže všichni konzumenti vidí identický materiál. Čtení nikdy nezapisuje do databáze; řetězec se persistuje jen tehdy, když import nebo adopce zapisuje tělo certifikátu bez řetězce. Odpověď GET /certificates/{id} získává chain_source, chain_complete a chain_warnings; data source mazevault_certificate získává chain_pem, chain_source a chain_complete a jeho atribut certificate_pem — dříve mapovaný na pole, které API nikdy nevracelo — je nyní naplněn z public_chain_pem. Nová Prometheus metrika: mazevault_certificate_chain_resolution_total{source,complete}.
• Objevené certifikáty si uchovávají tělo; adopce dává nasaditelný certifikát — Discovery agentem nyní ukládá veřejný leaf certifikát a řetězec vydavatelů, který agent viděl (migrace 000199, sloupce certificate_pem / chain_pem v discovered_certificates; pouze veřejný materiál, nikdy klíč). Adopce objeveného certifikátu proto vytvoří spravovaný certifikát s tělem, které lze exportovat, nasadit a ověřit; spravované certifikáty adoptované před touto verzí dostanou tělo automaticky při příštím skenu agenta přes stávající auto-link podle otisku, a nahlášený řetězec se ukládá tak, jak je (z inventáře se doplňuje jen tehdy, když agent žádný nenahlásil). Detail objeveného certifikátu (GET /discovered-certificates/{id}) vrací certificate_pem, chain_pem a chain_certificates; seznamy tělo záměrně vynechávají, aby stránka Discovered Certificates zůstala rychlá. Identita (serial, otisky) se nyní odvozuje z DER certifikátu místo důvěry v hlášení agenta.
• Tělo certifikátu ze synchronizace s CA a z ručního importu — Tělo se nyní uchovává i u certifikátů synchronizovaných z výpisu CA (HashiCorp Vault, DigiCert, ADCS, SSLMarket a lokální inventář pro ACME / I.CA / PostSignum): ParseCertificateMetadata přenáší normalizované PEM do objeveného záznamu, opakovaná synchronizace s CA doplní tělo záznamům vytvořeným dříve bez něj a spravovaný certifikát navázaný podle otisku, který tělo nemá, ho dostane stejně jako u agentní cesty. Navíc import samotného veřejného certifikátu (CRT/PEM/DER nebo PFX) nyní doplní spravovaný certifikát bez těla místo odmítnutí jako „již existuje“: import se spáruje podle otisku (nebo přiváže přes expected_certificate_id z detailu certifikátu), tělo se uloží spolu s identitou a popisnými sloupci odvozenými z něj (kanonický serial, otisky, subjekt/vydavatel, platnost, algoritmy klíče a podpisu, key usage, SAN, typ certifikátu; stav active se aktualizuje, revokovaný či čekající se nikdy nemění) a záznam bez řetězce se doplní z inventáře. Privátní klíč se u takového záznamu řídí schváleným pravidlem: klíč dodaný spolu s certifikátem se připojí, pokud záznam custody nemá; klíč shodný s existující custody je idempotentní opakovaný import; klíč, který neodpovídá, je odmítnut s explicitní chybou až po uložení těla — záznam nikdy nezůstane bez těla kvůli špatnému klíči. Lokálně uložený klíč, který při svém importu nešlo ověřit (záznam neměl tělo), se ověří při doplnění těla a pokud k certifikátu nepatří, je označen (metadata.private_key_mismatch, auditní událost certificate.private_key_mismatch), ale nikdy nesmazán. Položky hromadného/souborového importu v tomto případě vrací message: "existing certificate record completed with the uploaded certificate body"; detail certifikátu zobrazuje akci Complete certificate u záznamů bez těla a detail objeveného certifikátu vysvětluje ruční cestu. Discovery ingest, synchronizaci s CA, adopci i import nyní obsluhuje jedna sdílená implementace (applyCertificateBodyToManaged), takže každá cesta dává stejně kompletní záznam (dřívější cesta re-skenu nastavovala key usage jen v paměti a neukládala ho).
• Nasazení do souborů přes agenta a allowlistované příkazy — Rotace certifikátu nyní umí nasazovat do souborů na hostiteli agenta (cíl Agent File (PEM), krok agent_file_sync): agent zapíše leaf, řetězec, klíč a volitelný sloučený bundle (PEM nebo PKCS#12) podle content mode cíle (public_only, public_chain, full_chain_with_key, key_only), nastaví práva a vlastníka, původní soubory ponechá jako .BAK, nainstaluje řetězec do trust store platformy (je-li zapnuto) a spustí volitelný post-install příkaz. Kroky rotace, které potřebují příkaz na hostiteli (restart služby, WLST restart skript, Oracle orapki), nyní běží přes nový požadavek agenta agent_command, který spouští pouze příkazy odpovídající vestavěnému allowlistu agenta nebo regulárnímu výrazu v allowed_commands konfigurace operátora. Cíle Oracle database wallet se nyní nasazují skutečně: PKCS#12 s jednorázovým heslem se připraví pod <wallet>/mazevault/, importuje přes orapki wallet import_pkcs12 (auto-login nebo heslem chráněné wallety přes wallet_password_ref) a vždy se následně odstraní; heslo walletu i PKCS#12 jsou označena jako citlivá, takže je agent v auditním logu, odpovědi i případné chybě odmítnutí rediguje, a staging krok nenese idempotency klíč, aby opakovaná rotace soubor znovu připravila místo přehrání zastaralého výsledku. update_tns_names a rac_nodes jsou explicitně odmítnuty místo ignorování. Cíle WebLogic se nyní nasazují přes skutečný krok weblogic_deploy: leaf a klíč se nainstalují do custom identity keystore (JKS nebo PKCS#12, záloha přes backup_enabled), řetězec vydavatelů se volitelně importuje do custom trust keystore (trust_store_path + nové trust_store_type / trust_store_password_ref; každý vydavatel se připraví jako samostatný PEM pod <adresář-trust-store>/mazevault/, importuje přes keytool -importcert -trustcacerts, již existující alias se počítá jako úspěch a připravený soubor se vždy odstraní) a managed server nebo cluster se volitelně restartuje přes wlst_script_path operátora (restart_mode graceful / force / rolling). Heslo trust store je označeno jako citlivé, takže ho agent všude rediguje, a administrátorské přihlašovací údaje se nikdy nedostanou na příkazový řádek — WLST skript musí používat uložené přihlašovací údaje; admin_url, server_name a cluster_name jsou odmítnuty, pokud obsahují shellové metaznaky, a režim restartu vyžaduje admin_url. Strukturované požadavky agent_command (keytool, orapki, WLST skript) agent spouští přímo s vektorem argumentů, bez shellu, takže heslo obsahující shellové metaznaky nemůže být shellem ani reinterpretováno, ani vypsáno zpět; citlivé hodnoty jsou navíc před odesláním z agenta vyčištěny z výstupu příkazu i textu chyby. Operátorem zadané post-install příkazy si zachovávají shellovou sémantiku.
• Cíle nasazení se validují při uložení — Vytvoření nebo úprava cíle nasazení certifikátu se nyní validuje proti tomu, co systém skutečně umí provést, a vrací 400 s důvodem místo přijetí konfigurace, která by později selhala nebo byla přeskočena: cíle přes agenta (agent_keystore, agent_file, database, weblogic) vyžadují agenta; cíl database wallet vyžaduje wallet_path, provider Oracle (SQL Server, PostgreSQL, MySQL a MongoDB žádný wallet nemají — chyba uvede cíl Agent Keystore / Agent File, který se má použít místo něj) a update_tns_names=false; cíl WebLogic vyžaduje keystore_path, referenci na heslo pro svůj trust store a WLST skript pro jakýkoliv režim restartu; cíle web_server a load_balancer jsou odmítnuty s podporovanou alternativou, protože pro ně zatím neexistuje mechanismus nasazení. Stejnou validaci aplikuje builder workflow, takže zapnutý cíl, který nelze provést, rotaci ukončí chybou s ID cíle a důvodem místo tichého přeskočení. Vypnutí nebo změna priority existujícího cíle s neplatnou starší konfigurací je vždy povoleno, aby ho operátor mohl z rotace vyřadit; opětovné zapnutí vyžaduje opravu konfigurace. Editor cílů rotace v UI tato pravidla zrcadlí: Database Wallet vyžaduje agenta a je označen Oracle, ne-Oracle providery a přepínač Update TNS Names jsou zakázány s vysvětlujícím textem, Web Server se zobrazuje jako zatím nedostupné a Load Balancer je pro nové cíle z výběru skrytý (existující se stále otevře v režimu úprav s vysvětlením, aby šel vypnout nebo smazat — z API ani z kódu nebylo nic odstraněno), při odmítnutém uložení se zobrazí důvod z backendu a seznam cílů získal akci Zapnout / Vypnout, která mění pouze příznak enabled — cesta, jak starší cíl z rotace vyřadit bez smazání.
• Zálohy rotace tajemství: retence, úklid a ruční obnova — Každá rotace tajemství pořizuje šifrovanou zálohu stavu před rotací a nyní ji sleduje explicitním životním cyklem (pending → released / restored / recovery_required → acknowledged). Denní úklidová úloha maže pouze zálohy v terminálním stavu po vypršení retenčního okna, zatímco zálohy, u nichž selhal automatický rollback, jsou označeny recovery_required a nikdy se automaticky nemažou. Operátoři mohou zálohy vypsat, obnovit nebo odhalit hodnotu před rotací a potvrdit vyřešenou zálohu přes nové rotation API endpointy: GET /rotation/backups, POST /rotation/backups/{id}/restore, POST /rotation/backups/{id}/reveal a POST /rotation/backups/{id}/acknowledge. Reveal a restore navíc v handleru vynucují secret:read na prostředí daného tajemství a pro externě spravovaná (orchestrator mód / names_only) tajemství se lokálně žádná hodnota neukládá ani nevrací — operátor je odkázán na získání hodnoty z externího provideru pod vlastní identitou, takže API nemůže obejít řízení přístupu ke Key Vaultu. Retence je konfigurovatelná novou proměnnou MAZEVAULT_ROTATION_BACKUP_RETENTION_DAYS (výchozí 7). Byly přidány dvě metriky Prometheus: mazevault_rotation_backups_purged_total a mazevault_rotation_backups_recovery_required.
• Preflight rotace nyní před spuštěním ověřuje připravenost gateway a agentů — Preflight engine rotace i orchestrátor nyní před povolením startu rotace vyhodnocují živou připravenost každého požadovaného cíle exekuce — gateway a post-action agentů — namísto pouhé kontroly konfigurace. Nová metoda ProbeGatewayByID prověří konkrétní gateway podle ID a nemutující cesta EvaluateReadiness posoudí, zda je rotační zdroj připraven, aniž by měnila jakýkoli stav. Preflight engine rozlišuje povinné a volitelné post-action agenty, takže rotace závislá na nedostupné gateway nebo nedostupném povinném agentovi je klasifikována a nahlášena předem (napájí výsledky ready / deferred / blocked / manual-review-required) místo selhání uprostřed běhu. Rotační plánovač v rámci této práce efektivněji klasifikuje chyby brány (gate).
• Revoker milostivé lhůty pro service identity — Nová úloha na pozadí tvrdě revokuje tajemství klientů (service identit), jejichž lhůta milostivé doby (grace period) vypršela, a dokončuje tak cestu „soft revokace“, kterou RotateClientSecret zahajuje při nakonfigurované grace period. Dříve se zrotované tajemství s grace oknem spoléhalo na to, že staré přihlašovací údaje zůstanou platné, ale nic je po vypršení okna durabilně nevyřadilo. Revoker běží periodicky z plánovače (výchozí jednou za minutu), materializuje vypršelé grace periody a pro každou tvrdou revokaci zapíše auditní záznam.
• Správa životního cyklu agentů a evidence deployment záznamů — Registrované agenty lze nyní spravovat v celém životním cyklu řídicí roviny přímo v sekci Nasazení → Agenti a autentizace agentů je od začátku do konce lifecycle-aware. Nový route guard RequireActiveAgent při každém JWT-autentizovaném požadavku agenta znovu ověří aktuální stav agenta v databázi, takže agent, který byl odregistrován, revokován nebo smazán, už nemůže volat agentní routy s neexpirovaným tokenem; registrace ani legacy hostname-discovery cesta už neaktivují neaktivního ani revokovaného agenta a runtime konzumenti (resolvování rotačního sync-targetu, SSH deploy/revoke, keytab rotace) odmítnou směrovat práci přes neaktivního agenta. Konzoli obsluhují čtyři nové agent:admin endpointy: GET /api/v1/agents/:id/lifecycle-impact vrací orientační přehled závislostí (spravované certifikáty, vazby na projekty, rotační cíle, SSH klíče, čekající keytab práce, discovery/config/token reference) s best-effort varováními; POST /api/v1/agents/:id/unregister vyřadí agenta — zneplatní jeho mTLS identitu a recovery tokeny, deaktivuje vazby na projekty a označí čekající keytab práci jako selhanou — nebo povýší na bezpečnostní revokaci, pokud je kategorie důvodu compromised / lost_credential / stolen_host, přičemž nevyřešené blockery vyžadují force; POST /api/v1/agents/:id/reregister vyřadí starou identitu a vydá jednorázový 24hodinový náhradní bootstrap token; a POST /api/v1/agents/:id/uninstall požádá připojeného schopného agenta, aby se sám odinstaloval. Vzdálená odinstalace se vyjednává podle schopností v době požadavku a je podporována pro Linux balíčkové (systemd) instalace běžící jako root a Windows MSI service instalace: agent nejprve potvrdí přijetí, poté odpojená kopie agentní binárky (uniká z cgroup služby přes systemd-run na Linuxu, DETACHED_PROCESS na Windows) provede odstranění a před sebe-zničením nahlásí skutečný výsledek zpět přes health kanál — na Windows se per-build MSI ProductCode zjistí za běhu ze stabilního WiX UpgradeCode a odebere přes msiexec, s fallbackem sc delete pro ne-MSI service rozložení. Vyřazení agenta se dokončí až po nahlášeném úspěchu; nahlášené selhání nechá agenta aktivního (uninstall_status = failed) pro opakování a chybějící report je zobrazen jako čekající na potvrzení. Nepodporovaná rozložení (nebalíčkové/ruční instalace, macOS, offline) vrátí jasný fallback na odregistraci s ručním odstraněním. Deployment (bootstrap) záznamy získaly soft-delete životní cyklus — DELETE /api/v1/deployments/:id (chráněno deployment:write, scoped na organizaci) zneplatní enrollment token a instalační script bez dopadu na již registrované agenty a veřejné script/config endpointy pak vrací 404. Odpovědi list deploymentů používají dedikované DTO DeploymentResponse bez tokenu s vypočteným příznakem usable, zatímco odpověď create vrací bootstrap token právě jednou přes DeploymentCreatedResponse (závisí na něm UI, Go SDK i Terraform provider). Záložka Nasazení → Agenti se stává operační konzolí (odregistrace s náhledem dopadu a důvodem, vzdálená odinstalace, přeregistrace s jednorázovým tokenem, viditelné chybové stavy) a Nasazení → Nasadit získává akce smazat, zobrazit script a fallback kopírování. Nakonec go test sada modulu agenta nyní běží v PR, dev i release CI (dříve pouze cross-kompilace) a test invalidace filesystem-discovery politiky, který byl citlivý na běh pod rootem, byl zdeterminován.
• Rotační šablony získávají políčka politiky a režim úschovy tajemství — Šablony konfigurace rotace nyní nesou lead_time_days (dní před expirací pro zahájení obnovy certifikátu), grace_period_days (dní, po které zůstává předchozí hodnota platná pro rollback) a secret_custody_mode (local, transient nebo delegated). Tato pole jsou vystavena přes API rotačních šablon, Go SDK i Terraform resource mazevault_rotation_template a jsou end-to-end sladěna s perzistovaným katalogem (migrace 000195). Schéma API rotačních šablon a jeho dokumentace Swagger byly aktualizovány, aby nová pole popisovaly. Šablona navíc vystavuje project_id (volitelné omezení na projekt) a retry_delay_seconds a na Terraform resource je organization_id nyní Optional+Computed (rozřešeno serverem) s jednou sdílenou flatten cestou, takže create, read a update se nemohou rozejít; tyto přírůstky mapují již perzistované sloupce a nevyžadují novou migraci.
• Objevené certifikáty: vyhledávání a režimy přiřazení — Stránka Objevené certifikáty přidává serverový filtr search a explicitní režimy přiřazení pro adopci objevených certifikátů do správy, včetně endpointu hromadné adopce (POST /discovered-certificates/bulk/adopt, chráněno discovered_cert:bulk) vedle single-item cesty adopce. Samostatná routa Certificate Discovery byla odstraněna a nyní přesměrovává na Objevené certifikáty.
• Akční stav rotace na Dashboardu — Dashboard nyní pomocí nového navigačního resolveru rozřeší rotační položky na jejich akční cíl, takže záznamy stavu rotace odkazují přímo na plochu, kde s nimi lze pracovat.
• Nasazení sloučeno pod Enterprise Functions (chráněno PoC / Enterprise) — Configuration Management, SSH Management, KeyTab Management a Deployment nyní sídlí společně se Správou tokenů pod jednou navigační skupinou Enterprise Functions, která je čistě seskupovací hlavičkou — pouze se rozbaluje/sbaluje a sama nikam nenaviguje. Configuration, SSH a KeyTab už byly chráněny svými license featurami config_management / ssh_management / keytab_management; Deployment je nyní chráněn stejně novou featurou deployment_management udělovanou licencím PoC a Enterprise (stav active, grace nebo expiring). Skupina správy /api/v1/deployments (create / list / delete) je vynucena na straně serveru přes FeatureLicenseMiddleware a pro Small Business či nelicencované tenanty vrací HTTP 403; stránka Deployment místo záložek zobrazí upgrade banner. Uživatelé položku v menu stále vidí, pokud drží odpovídající RBAC oprávnění. Neautentizované, UUID-chráněné bootstrap endpointy agenta (/deployments/:id/script, /config, /agent-binary) zůstávají záměrně nechráněné, aby bezobslužné instalace agentů dál fungovaly, a endpointy správy agentů/gateway se nemění.
• Příkaz mazevault-agent enroll a předvyplněný soubor — mazevault-agent enroll --server <https-url> --token <token> [--ca-file <cesta>] [--force] [--no-start] jedním krokem zapíše konfiguraci, zkopíruje soubor privátní CA a povolí službu; --force dá agentovi novou identitu (certifikát, klíč a recovery token) — server ponechá stejný záznam agenta, pokud se shoduje hostname a ID stroje — a nemaže ca.crt ani předvyplněný soubor. Pro automatizované instalace agent při startu načte /etc/mazevault/enroll.conf (Windows: C:\ProgramData\MazeVault\enroll.ini), pokud neexistuje agent.yaml. Viz Průvodce nasazením agenta.
• Import certifikátu: odkaz na dokumentaci a poznámka už při importu — Dialog importu certifikátu (krok Review & Configure) nyní vedle stávajícího pole Tags přijímá volitelnou URL Documentation a volný text Note, takže tato metadata lze zadat už při importu, nikoli až dodatečně v detailu certifikátu. Hodnoty se validují stejnými pravidly jako v editoru detailu (odkaz na dokumentaci musí být http(s) URL do 500 znaků, poznámka je omezena na 256 znaků) a aplikují se na každý certifikát vytvořený z nahraného souboru — včetně každého certifikátu importovaného řetězce a každého souboru při hromadném importu, shodně se stávajícím chováním tagů.

Vylepšení

• Secret manager integrace podporují pouze Azure Key Vault — Providery AWS Secrets Manager, HashiCorp Vault a GCP Secret Manager byly odebrány; jediným podporovaným secret managerem je Azure Key Vault. Vytvoření, test připojení nebo synchronizace odebraných providerů jsou odmítnuty a jejich key/secret offload a rotační cíle se již nenabízejí. Existující integrace a rotační cíle odebraných typů jsou vypnuty migrací (jejich řádky zůstávají, aby je vlastníci mohli zkontrolovat a smazat) a lze je dál číst, upravovat a mazat. — Certifikáty podepsané z nahraného CSR jsou uloženy s custody klíče none; operátor nyní může klíč MazeVaultu dodat dodatečně z Detail certifikátu → Overview → Import private key (PEM klíč, šifrovaný PEM klíč, PFX/P12 nebo vložený PEM) s lokální nebo secret-manager custody při respektování Orchestrator Mode. Nebyl zaveden žádný nový endpoint: dialog využívá POST /certificates/import/file a nový volitelný parametr expected_certificate_id (dostupný i na POST /certificates/import) přiváže požadavek k jedinému certifikátu, takže cizí materiál je odmítnut místo vytvoření či změny jiného záznamu. Import více souborů nyní páruje samostatné .key soubory s certifikátem přes backendové párování preview-multi (nové pole key_source_file v odpovědi náhledu) a odesílá certifikát s klíčem v jednom požadavku, takže zvlášť nahraný klíč dorazí k již spravovanému certifikátu. Vyhledání duplicity/cíle je nyní primárně podle SHA-256 otisku (serial + issuer zůstává jako legacy fallback, který odmítne řádky s odlišným uloženým otiskem), kontrola custody respektuje externí úložiště (externě uložený klíč není nikdy tiše nahrazen lokální kopií), import v rámci projektu už nemůže změnit certifikát patřící jinému projektu, doplnění klíče nikdy nemění nastavení obnovy certifikátu ani nedegraduje bohatší uložený řetězec a chyba „already exists“ nyní vysvětluje, jak klíč doplnit.
• Integrace GitOps a HSM skryty pro 1.0 — Typ integrace GitOps (GitHub, GitLab, Azure DevOps) a typ integrace HSM (AWS CloudHSM, Azure Managed HSM) spolu s rotačním cílem DevOps Variable se již nenabízejí. Vytvoření, test připojení nebo synchronizace jsou odmítnuty a jsou odstraněny z průvodce integrací i z výběru rotačních cílů. Existující integrace a cíle těchto typů jsou vypnuty migrací (jejich řádky zůstávají, aby je vlastníci mohli zkontrolovat a smazat) a lze je dál číst, upravovat a mazat. HSM Devices (Nastavení organizace) a GitHub / GitLab SSO zůstávají vlastními funkcemi a nejsou dotčeny. GitOps a HSM se mají v pozdější verzi vrátit jako rozšíření. — Certifikáty podepsané z nahraného CSR jsou uloženy s custody klíče none; operátor nyní může klíč MazeVaultu dodat dodatečně z Detail certifikátu → Overview → Import private key (PEM klíč, šifrovaný PEM klíč, PFX/P12 nebo vložený PEM) s lokální nebo secret-manager custody při respektování Orchestrator Mode. Nebyl zaveden žádný nový endpoint: dialog využívá POST /certificates/import/file a nový volitelný parametr expected_certificate_id (dostupný i na POST /certificates/import) přiváže požadavek k jedinému certifikátu, takže cizí materiál je odmítnut místo vytvoření či změny jiného záznamu. Import více souborů nyní páruje samostatné .key soubory s certifikátem přes backendové párování preview-multi (nové pole key_source_file v odpovědi náhledu) a odesílá certifikát s klíčem v jednom požadavku, takže zvlášť nahraný klíč dorazí k již spravovanému certifikátu. Vyhledání duplicity/cíle je nyní primárně podle SHA-256 otisku (serial + issuer zůstává jako legacy fallback, který odmítne řádky s odlišným uloženým otiskem), kontrola custody respektuje externí úložiště (externě uložený klíč není nikdy tiše nahrazen lokální kopií), import v rámci projektu už nemůže změnit certifikát patřící jinému projektu, doplnění klíče nikdy nemění nastavení obnovy certifikátu ani nedegraduje bohatší uložený řetězec a chyba „already exists“ nyní vysvětluje, jak klíč doplnit.
• Z konfigurace nasazení zmizel nepoužívaný session secret — MAZEVAULT_SESSION_SECRET (SESSION_SECRET v .env Compose kitu, global.keyVault.secretKeys.sessionSecret a Key Vault secret mazevault-session-secret v Helm chartu) vyžadovaly instalátory i chart, backend ho ale nikdy nečetl. Nové instalace ho už negenerují a chart ho z Key Vaultu nečte. Stávající instalace nemusí nic dělat: zbylá hodnota v .env, Helm values nebo Key Vaultu se ignoruje a lze ji smazat.
• Odstraněny nepoužívané URL konzole a API výsledků discovery agenta — Webové rozhraní už nemá zástupnou stránku /settings („This feature is currently under development“) ani staré URL, které jen přesměrovávaly na stránky v menu: /certificates a /certificates/{id} (Certificate Dashboard), /password-requests (Password Requests), /notifications a /conflicts (Synchronization Problems) a /discovery/certificates (Discovered Certificates). Žádný odkaz aplikace na ně nevedl; stará záložka nyní otevře dashboard. Odstraněna je také stránka Discovery Results agenta (/agents/{id}/discovery), na kterou rovněž nevedl žádný odkaz, a její API GET /api/v1/agents/{id}/discovery (volání nyní vrací HTTP 404): certifikáty nalezené agentem vrací GET /api/v1/discovered-certificates?agent_id={id} (vyžaduje discovered_cert:read). Agent, CLI, Terraform provider ani Kubernetes operátor odstraněné API nevolaly. Neplatné agent_id, project_id nebo managed_certificate_id u GET /api/v1/discovered-certificates nyní vrací HTTP 400; dříve se ignorovalo a volání vrátilo všechny nalezené certifikáty.
• Odebrány archivní destinace auditních logů — Záložka Organization Settings → System Outputs se nyní jmenuje Audit Log Streams a nastavuje pouze streamování v reálném čase do Splunku, Elasticsearch a Syslogu. Archivní destinace (AWS S3, Azure Blob Storage, File Share), dávkové nahrávání do nich, endpoint POST /organizations/{id}/integrations/test-archive a Prometheus metriky mazevault_archive_events_dropped_total a mazevault_archive_upload_errors_total byly odebrány. Migrace 000219_remove_audit_archive_destinations smaže uložené konfigurace archivních destinací, jejichž přihlašovací údaje byly uloženy nešifrovaně. Pro uchování auditní historie déle než lokální retence ji streamujte do SIEM. Alerty nebo dashboardy, které používají obě metriky, odstraňte. Vytvoření integrace organizace nově přijme jen kategorie notification a log_stream a pro jakoukoli jinou, včetně archive, vrací 400.
• Doplnění privátního klíče k existujícímu certifikátu (vydanému z CSR nebo importovanému bez klíče) — Certifikáty podepsané z nahraného CSR jsou uloženy s custody klíče none; operátor nyní může klíč MazeVaultu dodat dodatečně z Detail certifikátu → Overview → Import private key (PEM klíč, šifrovaný PEM klíč, PFX/P12 nebo vložený PEM) s lokální nebo secret-manager custody při respektování Orchestrator Mode. Nebyl zaveden žádný nový endpoint: dialog využívá POST /certificates/import/file a nový volitelný parametr expected_certificate_id (dostupný i na POST /certificates/import) přiváže požadavek k jedinému certifikátu, takže cizí materiál je odmítnut místo vytvoření či změny jiného záznamu. Import více souborů nyní páruje samostatné .key soubory s certifikátem přes backendové párování preview-multi (nové pole key_source_file v odpovědi náhledu) a odesílá certifikát s klíčem v jednom požadavku, takže zvlášť nahraný klíč dorazí k již spravovanému certifikátu. Vyhledání duplicity/cíle je nyní primárně podle SHA-256 otisku (serial + issuer zůstává jako legacy fallback, který odmítne řádky s odlišným uloženým otiskem), kontrola custody respektuje externí úložiště (externě uložený klíč není nikdy tiše nahrazen lokální kopií), import v rámci projektu už nemůže změnit certifikát patřící jinému projektu, doplnění klíče nikdy nemění nastavení obnovy certifikátu ani nedegraduje bohatší uložený řetězec a chyba „already exists“ nyní vysvětluje, jak klíč doplnit.
• Nahraná CSR se validují vůči šabloně před kontaktováním CA — Nahraná CSR nyní selžou okamžitě při odeslání, pokud porušují explicitní politiku šablony: vlastní podpis musí být platný, velikost klíče musí být v allowed_key_sizes, je-li nastaveno (dříve vynucováno jen interní CA, nikdy ADCS ani externími CA), a SAN položky musí vyhovět explicitní san_config (allowed_san_types, san_validation_pattern, max_san_count a nový příznak require_san, který odmítne CSR pouze s CN). Výchozí chování je záměrně permisivní — šablony bez san_config přijímají každé CSR jako dosud — a systémové šablony (mTLS agentů/gateway) jsou vyjmuty. Požadované SAN a parametry klíče nahraného CSR se nyní zaznamenávají na požadavku pro auditovatelnost.
• Požadavky vyžadující schválení správcem ADCS se sledují místo selhání — Vydání nového certifikátu přes ADCS CA vyžadující manager approval už nevrací HTTP 500, zatímco CA drží enrollment: požadavek přejde do submitted_to_ca a po schválení v CA jej automaticky dokončí poller externích objednávek. CA providery mohou implementovat nové volitelné rozhraní IssuedCertificateFetcher vracející vydaný leaf podle ID objednávky; ADCS jej implementuje, čímž je opraven latentní defekt, kdy by poller uložil CA řetězec jako leaf.
• Životní cyklus požadavku po selhání vydání — Automaticky schválený požadavek, jehož vydání selže, je nyní označen failed se zaznamenanou chybou (místo setrvání v approved bez certifikátu) a ručně schválený požadavek se při selhání vrátí do pending, aby jej schvalovatel mohl zopakovat; pozdější úspěšné vydání zaznamenanou chybu vymaže. Enum stavu požadavku dokumentuje stav failed a UI jej zobrazuje.
• Kanonické kódování sériového čísla certifikátu — certificates.serial_number se konzistentně ukládá jako decimální řetězec big-integeru, který už používají OCSP, revokace a import. Vydání přes ACME a HashiCorp Vault, finalizace externích objednávek a rychlá cesta vestavěného ACME serveru dříve zapisovaly či dotazovaly hexadecimální serialy, což u těchto certifikátů rozbíjelo deduplikaci importu a indexované vyhledávání ACME serveru. Revokace a dotazy stavu ve Vaultu překládají kanonický serial zpět do Vaultem očekávaného colon-hex formátu, takže fungují legacy i normalizované řádky. Idempotentní backfill identity (BackfillCertificateIdentity) znovu odvodí serial a otisky z uloženého DER; běží na pozadí při startu primary a je součástí POST /admin/certificates/backfill, který nyní vrací identity_normalized.
• Editor šablon už nepřepíná „Allow Additional SANs“ — allow_additional_sans v API pro vytvoření/úpravu šablony certifikátu nyní rozlišuje přítomnost (vynechané zachová uloženou hodnotu; explicitní false je respektováno). Dříve update bez tohoto pole — které editor šablon nikdy neposílá — hodnotu resetoval na false.
• Rozřešení scope integračních skupin pro RBAC — Nový IntegrationGroupScopeMiddleware rozřeší samostatné ID integrační skupiny na její vlastnící aktivní projekt ještě před vyhodnocením projektového RBAC a odmítne požadavky na skupiny, jejichž projekt je archivovaný nebo chybí. Díky tomu lze endpointy integračních skupin autorizovat konzistentně se zbytkem projektového RBAC modelu.
• Životní cyklus revokace SSH authorized-key — Agenti mohou dotazovat čekající revokace authorized-key (GET /agent/authorized-keys/pending-revocations) a potvrdit jejich dokončení (POST /agent/authorized-keys/:id/confirm-revocation) a operátoři mohou authorized-key revokovat (POST .../authorized-keys/:id/revoke) i opakovat selhané nasazení SSH klíče (PUT /ssh-keys/:id/deploy). Zastavenou nebo částečně selhanou exekuci rotace lze obnovit přes POST /rotation/executions/:id/resume. Potvrzovací zpráva u rotace SSH klíče byla rovněž zpřesněna.
• Runtime cíle rotace směrují jen přes aktivní agenty — Když rotace deleguje práci na agenta (například nasazení keytab nebo SSH), runtime nyní rozřeší navázaného agenta a odmítne směrovat přes agenta, který je neaktivní, revokovaný nebo soft-smazaný, a vrátí jasnou chybu místo proxování na mrtvý cíl.
• Validace číselných polí rotačních šablon — Číselná pole rotačních šablon (rotation_interval_days, lead_time_days, grace_period_days, max_retry_attempts, retry_delay_seconds, timeout_minutes) jsou nyní validována jako nezáporná celá čísla napříč backend API, frontendem i Terraform providerem, se strukturovanými aplikačními chybami místo nesrozumitelných selhání. Pole retry_delay_seconds — již perzistované a vystavené přes API, SDK i Terraform resource — je nyní editovatelné i ve formuláři rotační šablony v UI, takže jej lze nastavit a zobrazit z konzole. Hromadná adopce certifikátů zobrazuje uživatelsky přívětivé zprávy pro částečná selhání.
• Elegantní vypnutí backendu při SIGTERM — API server nyní při obdržení SIGTERM vyprázdní probíhající požadavky přes http.Server.Shutdown — s lhůtou pro vyprázdnění drženou pod terminační grace period Kubernetes — a poté před ukončením zastaví služby log-stream a audit-archive na pozadí, místo aby byl při rolloutech tvrdě zabit uprostřed požadavku. http.ErrServerClosed je považován za normální ukončení.
• Vynucení vlastnictví SSH authorized-key — Výpis, nasazení, revokace a odstranění SSH authorized-key (a výpis párů klíčů) nyní konzistentně vynucují vlastnictví páru klíčů — jednající uživatel musí pár klíčů vlastnit nebo mít ssh:admin — v souladu s kontrolami vlastnictví již uplatňovanými u get, export a delete. Neadmin už nemůže vypsat inventář klíčů jiného uživatele ani nasazovat/revokovat/odstraňovat klíče, které nevlastní; producentská revokace a odstranění plus agentní potvrzení revokace nyní zapisují auditní záznamy s kontextem request-ID.
• Obnova rotace vyžaduje autentizovaného aktéra — POST /rotation/executions/:id/resume nyní odmítne požadavek bez autentizovaného principalu s HTTP 401 ještě před během orchestrátoru a zaznamenává úspěšné i neúspěšné obnovy s plným auditním kontextem request-ID.
• Stabilita recovery tokenu agenta (bez zamčení při re-registraci) — Re-registrace agenta již při každém volání nerotuje stále platný recovery token. Nový recovery token se razí pouze tehdy, když se agent bootstrapuje/přeinstaluje deployment tokenem nebo nemá použitelný token v evidenci; agent, který se autentizuje svým aktuálním recovery tokenem, si jej ponechává. Ve spojení s atomickou, pádu-odolnou perzistencí stavu agenta — zrotovaný token i identita se připraví a do paměti potvrdí až po úspěšném durabilním zápisu a nahrazení dočasného souboru je nyní atomické i na Windows (MoveFileEx s nahrazením existujícího), nejen na POSIX — už agent, který spadne nebo neuloží zrotovaný token, nemůže být trvale zamčen. Jde pouze o behaviorální zpevnění — žádná změna schématu ani API kontraktu.
• Zpřísněná registrace agentů (změna chování) — Agenti nově odesílají hashované ID stroje. Nasazovací token už nemůže znovu zaregistrovat agenta, který patří jiné organizaci (požadavek je zamítnut). Dva stroje se stejným hostname, ale různým ID stroje se nově stávají samostatnými agenty a nepřepisují se navzájem (agenti této verze; starší agenti fungují beze změny). Agent, který ztratil lokální stav, se může znovu zaregistrovat původním nasazovacím tokenem i po jeho vypršení, ale pouze na stejném stroji a ve stejné organizaci. Recovery token agenta ho identifikuje i tehdy, když se změnilo jeho ID stroje (například po návratu ke starší verzi agenta), a záznam staršího agenta bez ID stroje v jiné organizaci už neblokuje hostname pro agenta této verze.

Opravy chyb

• Zničení mazevault_shared_secret odvolá sdílecí odkaz; sdílená tajemství lze importovat — Nové DELETE /api/v1/share/{id} sdílení smaže (jen uživatel, který ho vytvořil; ostatní dostanou 404). Terraform provider ho volá při zničení i nahrazení, takže starý odkaz přestane fungovat. Import ID je nově <share_id>/<secret_id>.
• Číselná a seznamová pole drží, co napíšete; popisky formulářů jsou čtečkám přístupné; název šablony a projektu je povinný — Číselná pole (např. priorita, dny předstihu, platnost, intervaly, délky hesla) se po vymazání už nevracejí na výchozí hodnotu, takže napsání 14 uloží 14 místo 3014; vymazané pole ponechá poslední platnou hodnotu místo uložení null. Pole se seznamem odděleným čárkou (endpointy Elasticsearch a Actuatoru, OID politik, rozsahy pravidel viditelnosti) zachovají napsané čárky a mezery a psaní ID pravidla viditelnosti už neztrácí fokus. Popisky formulářů, filtry auditního logu a výběry při porovnání prostředí mají přístupný název. Průvodce šablonou projektu a Create Project odmítnou prázdný název a krok Environments šablony má výslovnou volbu „All environments (including future ones)“: šablony uložené pro všechna prostředí si ji při uložení ponechají, výběr konkrétních prostředí uloží jen je a žádné vybrané prostředí nyní znamená žádné místo všech.
• Agent hlásí selhané kroky instalace, znovu posílá ztracené odpovědi a zastaví se hned — Synchronizace certifikátu, jejíž post_install_command selhal, už krok nezapíše jako dokončený (odpověď nese post_install_error), a linuxový adresář důvěry, do kterého nejde zapsat žádný CA certifikát, se hlásí jako selhaná instalace do úložiště důvěry místo úspěchu. Odpověď na úlohu, kterou agent kvůli výpadku spojení nemohl poslat, si ponechá a po novém připojení ji pošle znovu; účinné to bude, až backend začne párovat odpovědi napříč spojeními, což přinese pozdější aktualizace backendu. Zastavení nebo restart agenta už nečeká 10 sekund na spojení úloh, agent, jehož klientský klíč pro mTLS nejde načíst, se zastaví s chybou konfigurace místo pozdějšího pádu, a hesla keystorů dostávají keytool a openssl přes proměnné prostředí místo příkazové řádky, kde je viděl každý lokální uživatel.
• UI nabízí jen akce, které vaše role smí; chyby přihlášení a jednorázová tajemství se zpracují správně — Tlačítka a stránky se řídí stejným oprávněním jako server: Password Requests vyžaduje agent:admin (menu i stránka), aktivace a obnova licence billing:write, úprava a mazání šablon rotace rotation:write, Add User v projektu role:assign, přiřazení šablon a nastavení projektu project:write (bez něj je nastavení jen pro čtení), změny integrací integration:write a dashboard Entra ID integration:read a entra:read (Sync entra:write). Stránky už nenačítají data před kontrolou přístupu. Bez agent:admin nabídne editor cíle nasazení certifikátu agenty navázané na projekt certifikátu. Chyba šifrování po MFA se už nehlásí jako neplatný MFA kód a neúspěšné přihlášení přes LDAP nebo MFA ukáže vlastní chybu. Zrušené schválení žádosti o heslo si už nepamatuje napsané heslo, odhalená hodnota spravovaného tokenu je maskovaná, dokud nekliknete na Show, a nově vytvořený client secret nebo API token se při zavření dialogu zahodí.
• Dialogy si při chybě ponechají zadaná data; uložení už nemaže štítky, webhooky a popisy projektu ani URL certifikační autority — Dialog kontaktu pro incidenty a formulář nového prostředí zůstanou vyplněné, když uložení selže, neúspěšné ignorování nalezeného certifikátu a neúspěšné první načtení validace domény se zobrazí a chyby spravovaných tokenů bez zprávy serveru pojmenují neúspěšnou akci. Uložení nastavení projektu ponechá štítky a notifikační webhooky projektu, úprava servisní identity ponechá její popis a vymazání OCSP nebo CRL URL certifikační autority ji odstraní. Tlačítko historie rotací u credentialu Entra ukáže historii tohoto credentialu, Bind Agent ukáže OS agenta, spravované tokeny jde nasadit do AWS Secrets Manager a mapování skupiny prostředí se vytvoří pro zvoleného poskytovatele identit (pole Identity Provider). Nahrání systémového certifikátu už nenabízí volby zálohy a reloadu, které server nikdy neprováděl. Přesun cíle rotace dřív nebo později funguje i u cílů se stejnou prioritou, certifikát se dvěma akcemi po rotaci stejného typu už upravenou akci neuloží dvakrát a změna typu cíle rotace secretu už neposílá nastavení původního typu. Usage and Billing ukazuje skutečné využití projektů a secretů (vyžaduje org:read) a zavřené upozornění na expiraci licence zůstane po znovunačtení zavřené. Šablony rotace a keytaby se mažou až po potvrzení v aplikaci, nastavení MFA sleduje úpravy surového JSONu, bránu jde přiřadit jako DR standby k prostředí, kde je primární jiná brána, seznam agentů je anglicky a u agenta, který se ještě nehlásil, ukáže „Never“, a detail certifikátu už nezůstane na „Loading...“.
• Vytvoření záznamů bez volitelných polí už neselže — Šablona rotace nebo skupina integrací založená bez volitelných seznamů (např. notify_before_days, mappings) a schvalovací politika bez conditions vracely 500; nyní se uloží s prázdnými hodnotami (existující schvalovací politiky s conditions [] se převedou na {}). Přepnutí organizace do PKI režimu intermediate nebo proxy teď opravdu zaregistruje účet upstream CA (čeká na ověření) a replay metadata rotace bez pole metadata se už neztratí.
• Výpis a ukončení session PostgreSQL fungují; selhání rotací ukazují pozdější úspěšný běh a navázaný incident — Výpis a řízené ukončení (drain) session PostgreSQL integrace vracely 500 pro každou TCP session, takže rotace hesla s ukončením session nemohla doběhnout. Na dashboardu se selhání rotace, po kterém následoval úspěšný běh, nikdy neoznačilo jako překonané a nenavázalo se na otevřený incident selhání rotace.
• Dočasný přístup a vazby agent–projekt fungují i po prvním záznamu — Dočasná oprávnění (včetně break-glass) a vazby agenta na projekt se ukládaly bez vlastního ID, takže v celém systému šel vytvořit jen první z nich: druhé oprávnění i druhá vazba skončily chybou a odebrání oprávnění také selhalo. Každý záznam teď dostane vlastní ID; dříve vytvořený záznam funguje dál.
• Kroky doručení a úklidu při rotaci selžou místo hlášení úspěchu (před upgradem zkontrolujte konfigurace rotací) — Několik kroků rotace hlásilo úspěch, aniž by svou práci udělaly; nyní krok selže, takže rotace viditelně selže (a provede se kompenzace), místo aby se publikovala, zatímco cíl dál drží starou hodnotu. post_rotation_sync dál aktualizuje každý dostupný Key Vault, ale selže, když nastavenou integraci nelze načíst (smazaná nebo vypnutá, chyba rozlišení přes gateway), nemá vault_url nebo použitelné přihlašovací údaje; rollback rotace běžící na serveru MazeVault pak obnoví předchozí hodnotu i ve vaultech, které neúspěšný krok už aktualizoval, i když selhal sám zápis do vaultu (krok delegovaný na gateway zatím ne; dříve se neúspěšný krok nikdy nekompenzoval a kompenzace post_rotation_sync v rotacích běžících na serveru MazeVault nenašla klíč secretu, takže neobnovila nic). certificate_to_keyvault u poskytovatele, kterého nepodporuje (např. gcp_secret_manager), selže místo „simulovaného“ zápisu. spring_actuator selže, když se kterýkoli nastavený endpoint neobnovil (chyba HTTP, nedostupnost, TLS). Kubernetes pod trigger nyní respektuje label_selector: restartuje všechny deploymenty, statefulsety a daemonsety odpovídající selektoru a selže, když neodpovídá nic; jeho service account potřebuje v namespace list a patch na deployments, statefulsets a daemonsets (API skupina apps), i když odpovídají jen deploymenty. Krok cleanup nemá žádnou implementaci úklidu, proto nastavený target nyní odmítne jako nepodporovaný místo hlášení cleaned: true. Synchronizovat nyní u cíle nasazení secretu (POST /api/v1/secrets/{id}/rotation/targets/{targetId}/sync) nyní hned doručí aktuální hodnotu secretu do cíle a odpoví 200 s cílem, který nese skutečný výsledek (last_delivery_status success, nebo failed s last_delivery_error); dříve jen nastavil stav pending, který se už nikdy nezměnil. Databázové cíle dostanou administrátorské údaje své integrace jako při rotaci a doručení má stejný časový limit jako krok rotace (timeout_seconds, výchozí 5 minut). Cíl, který synchronizovat nelze (jiná role než distribution nebo typ cíle bez kroku doručení), se odmítne s 409 a jeho stav doručení se nezmění; stejně tak cíl, jehož integrace, agent nebo cílový projekt leží mimo projekt či organizaci secretu (kontrola jako u kroku rotace). Webové rozhraní zobrazí neúspěšnou synchronizaci i s chybou. Ruční synchronizace běží na serveru MazeVault, ne na gateway: u cíle dostupného jen přes gateway selže a v prostředí, které rotace směruje přes gateway, cíl dostupný ze serveru zapíše server.
• Doručení po rotaci Entra se dokončí — Doručení rotovaného client secretu Entra na cíle po rotaci už nekončí neúspěšnou exekucí (s rollbackem a notifikací o selhání propagace), když všechny cíle uspěly, a cíl s dlouhým názvem (např. webhook s dlouhou URL) už z doručení tiše nevypadne: když krok doručení nejde uložit, doručení selže a odejde notifikace o selhání.
• Konvence pojmenování: parsování a provisioning funguje s výchozí konvencí — POST /api/v1/naming-conventions/{id}/parse a /provision vracely 500 pro každý název výchozí konvence (proměnné prostředí, číslo) a /cross-validate hlásil každý platný výchozí název jako porušení povolených znaků. Obojí nyní funguje; prázdný non_prod_prefix už nepovažuje každé prostředí za neprodukční.
• Failover gateway drží jednu aktivní gateway na prostředí — Když selhaná primární gateway znovu posílala heartbeat a prostředí už obsluhovala DR gateway, monitor zdraví primární gateway znovu aktivoval a aktivní byly dvě (kontrola hledala špatnou roli DR); primární gateway teď zůstane failed až do failbacku, i když DR gateway obsluhuje prostředí přes seznam podporovaných prostředí. Endpoint zdraví gateway teď databázi opravdu dotazuje, takže gateway s nedostupnou databází hlásí degraded místo healthy. Směrování teď vybere gateway s nejnižší failover_priority napříč gateway pro jedno i více prostředí (dřív vyhrála gateway pro jedno prostředí bez ohledu na prioritu). Runbook DR failoveru teď uvádí skutečné prahy: gateway bez heartbeatu 2 minuty přestane dostávat práci po rychlých opakováních (asi 5 minut) a jako failed se označí až po 7 dnech; pro dřívější failover nejdřív deaktivujte primární gateway.
• Synchronizace souborů agentem drží zálohy soukromé a upravuje soubory bezpečně — Než synchronizace tajemství přepsala konfigurační soubor, agent uložil jeho zálohu (.bak.<čas>) čitelnou pro všechny lokální uživatele, i když byl soubor sám soukromý; zálohy se nyní vytvářejí s přístupem jen pro vlastníka a aktualizované i obnovené soubory si zachovávají původní práva a nahrazují se atomicky přes dočasný soubor. Synchronizace do prázdného souboru YAML nebo JSON s hodnotou null už agenta neshodí. U souborů .env se hodnota tajemství se zalomením řádku odmítne místo vložení další proměnné a řádky export KEY= se přepíší na místě (staré tajemství v souboru nezůstane). Na Windows soubory dědí práva svého adresáře.
• Výsledky objevování lze převzít či ignorovat a varování konzistence vyřešit — POST /api/v1/discovery-results/{id}/adopt a /ignore končily při každém požadavku chybou a POST /api/v1/consistency-warnings/{id}/resolve vždy vracelo 500. Nyní fungují a jako aktéra zaznamenají přihlášeného uživatele; stejná oprava způsobí, že změny prostředí projektu zaznamenají, kdo je provedl.
• Post-rotační akce běží i u rotací certifikátů přes gateway a selhání s abort se zaznamená — Rotace certifikátu delegovaná na gateway prostředí nově po úspěšném workflow spustí post-rotační akce konfigurace (webhook, reload aplikace, notifikace) stejně jako lokální cesta; dřív se nespustily nikdy. Při obnově certifikátu běží post-rotační akce právě jednou, v dokončení obnovy; nasazení po obnově je už nespouští podruhé. Post-rotační akce tajemství s on_failure: abort, která selže, nově zastaví zbývající akce, označí exekuci jako neověřenou s nutným zásahem operátora, uloží post_actions_completed, označí konfiguraci rotace jako selhanou a otevře incident selhání rotace, stejně jako už continue a warn; dřív rotace vypadala plně úspěšná.
• Obnovení rotace čeká na běžící rotaci, dokončená exekuce se znovu nespouští, částečný rollback zůstává vidět — Obnovení selhané exekuce rotace (POST /api/v1/rotation/executions/{id}/resume) nyní bere i zámek rotace své konfigurace a je odmítnuto, dokud běží jiná rotace téhož tajemství nebo certifikátu, takže obě už nemohou vygenerovat a zapsat dvě různé nové hodnoty. Předpřipravená exekuce (doručení po rotaci Entra ID) se spustí jen ve stavu pending; druhé spuštění dokončené nebo selhané exekuce je odmítnuto, místo aby znovu provedlo všechny kroky (u Entra ID další credential). Když krok selže a selžou i některé kompenzace, exekuce si ponechá stav partially_rolled_back a nepřepíše se na failed, takže exekuce vyžadující ruční opravu jsou vidět a lze je obnovit; Rotation Problems je zobrazí (a lze je tam potvrdit) a dashboard i compliance report je počítají mezi selhané rotace.
• ACME server obslouží skutečné klienty a odvolání dojde k CA i do inventáře — Vestavěný ACME server (/api/acme/*) už neodpovídá na každý POST 403 CSRF token mismatch: jeho protokolové cesty jsou vyjmuté z prohlížečové double-submit kontroly, protože každý požadavek je podepsaný JWS (new-nonce nic nemění), takže cert-manager, certbot a další klienti bez cookies jsou obslouženi. Certifikáty vydané přes účet interní CA se nově ukládají s touto CA (ca_id), takže revoke-cert je u interní CA odvolá místo chyby 500 certificate not found; migrace 000260 doplní ca_id certifikátům vydaným takto dříve. Po odvolání u CA se jako revoked (s datem a důvodem odvolání) označí i certifikát v inventáři, nejen ACME objednávka. Když nejde CA účet objednávky načíst, revoke-cert nově skončí 500 serverInternal a objednávku nechá platnou, místo aby hlásil odvolání, které se k CA nedostalo.
• RBAC přístup ke Key Vaultu ukazuje jen vlastní role přihlášeného uživatele — GET /api/v1/azure/keyvaults/discover, POST /api/v1/azure/keyvaults/check-access a kontrola zápisu do Key Vaultu v preflightu rotace počítaly přiřazení rolí všech principalů na vaultu jako role přihlášeného uživatele, takže uživatel s rolí Key Vault Secrets User „směl“ zapisovat a mazat secrety, kdykoli měla na stejném vaultu např. managed identity MazeVaultu roli Secrets Officer. Efektivní přístup a vrácené role_assignments teď obsahují jen vlastní přiřazení uživatele na vaultu a na scopech nad ním (resource group, subskripce, management group), včetně přiřazení přes skupiny Entra; přiřazení na jednom secretu pod vaultem se už nepočítá jako přístup k celému vaultu a přiřazení jiných principalů se už nevracejí.
• Service identity projdou kontrolou zařízení — Zero trust kontrola zařízení na /api/v1/secrets, /api/v1/rbac a /api/v2 odmítala každý požadavek service identity (pokoušela se identitu zapsat jako zařízení uživatele). Service identita nyní kontrolou zařízení projde; co smí, rozhodují její přidělené role a kontrola anomálií platí dál.
• ACME: External Account Binding, wildcardy a kontrola stavu — ACME účty s eab_kid / eab_hmac_key nyní při registraci posílají external account binding podle RFC 8555 §7.3.4, takže CA, které ho vyžadují (ZeroSSL, Sectigo, Google Trust Services), účet přijmou místo odpovědi externalAccountRequired; neúplný binding nebo klíč, který není base64url, selže ještě před prvním požadavkem. Wildcard autorizace se poznají podle příznaku wildcard, který CA posílá (RFC 8555 §7.1.4), takže výchozí politika auto je ověří přes DNS-01 na základní doméně místo chyby „no http-01 challenge found“. Kontrola stavu CA účtu kontaktuje ACME directory při každé kontrole a při výpadku už nehlásí výsledek z cache.
• Terraform zachází s objekty smazanými mimo Terraform u všech zdrojů stejně (zkontrolujte volání SDK) — Když byl objekt spravovaný Terraformem smazán v MazeVaultu, terraform plan u většiny zdrojů skončil chybou „not found“ místo plánu na znovuvytvoření a terraform destroy u většiny zdrojů neskončil. Nově platí pro všechny zdroje jedno pravidlo: 404 při refreshi odebere zdroj ze state (další plán ho vytvoří znovu), 404 při destroy se bere jako už smazaný objekt a každá jiná chyba (401, 403, 5xx, síť) se ohlásí a zdroj ve state zůstane. mazevault_hsm_device a mazevault_shared_secret dřív odebraly zdroj ze state při jakékoli chybě čtení, takže přechodný výpadek backendu naplánoval nové HSM zařízení; nově chybu ohlásí. V Go SDK vracejí GetApprovalPolicy, GetDeployment, GetConfigTemplate, GetGroupMapping, GetRole, GetOrgProjectTemplate a GetSyncRule pro neexistující id 404 *APIError (IsNotFoundError(err) je true) místo (nil, nil); kód, který kontroloval výsledek na nil, musí nově kontrolovat IsNotFoundError(err).
• Terraform po refreshi nic neplánuje, když volitelné atributy nejsou nastavené nebo jsou prázdné — Když volitelný atribut v konfiguraci chyběl, Read uložil prázdnou hodnotu backendu nebo jeho výchozí hodnotu ("", false, viewer, daemon, agent, pull, incremental, manual_resolution, continue) a další terraform plan po každém refreshi ukázal změnu. U mazevault_user (role a email psaný velkými písmeny, který backend ukládá malými), mazevault_user_role (project_id, environment) a mazevault_deployment (agent_mode, deployment_type, gateway_url) tato změna objekt při každém běhu nahradila (nahrazení deploymentu vydá nový token agenta). Read nově nechá nenastavený atribut nenastavený a nastavené "" jako "", hodnota, kterou backend doplní jako výchozí, se nepočítá jako změna a "" ani nenastavená hodnota už nahrazení nevynutí. Totéž platí pro config_template, consistency_group, identity_provider, integration_group, keytab, rotation_config, secret_rotation_target a sync_rule a pro volitelná pole post-rotačních akcí (včetně on_failure, které backend nastaví na continue). mazevault_user.role, mazevault_deployment.agent_mode/deployment_type a mazevault_sync_rule sync_direction/sync_mode/conflict_strategy nově bez konfigurace ukazují hodnotu ze serveru; když je z konfigurace odeberete, zůstane současná hodnota. Úprava integration group nebo consistency group bez description a rotation workflow bez target_environment už nekončí chybou „Provider produced inconsistent result after apply“. První apply mazevault_ca a mazevault_rotation_config už neselže na „unknown value after apply“, když server nechá account_id, key_algorithm, last_error nebo target_environment prázdné, a last_error, který backend vymazal, ze state zmizí. Post-rotační akce odstraněné v MazeVaultu nově při refreshi zmizí i ze state (rotation_config, rotation_workflow, certificate_rotation_config, entra_rotation_config), takže terraform plan drift ukáže a akce vrátí. Změna auto_update existujícího mazevault_deployment nově skončí chybou s vysvětlením už při plánu (API ji neumí) místo nekonzistentního výsledku po apply. Po upgradu může state zapsaný starší verzí provideru jednou ukázat změnu na místě z "", false (auto_update) nebo 0 (order post-akce) na nenastaveno; nic nenahradí a po jednom apply se už neobjeví.
• Certifikátové credentials Entra ID jdou rotovat — Přidání a odebrání certifikátového credentialu aplikace Entra (rotace certifikátu, staged secondary, smazání credentialu) volalo Microsoft Graph addKey/removeKey bez povinného důkazu vlastnictví klíče (proof), takže Graph každé volání odmítl. MazeVault teď důkaz podepisuje privátním klíčem, který ukládá k některému z aktuálně platných certifikátů aplikace; když žádný takový nemá (např. certifikát nahraný mimo MazeVault nebo prošlý), změní místo toho keyCredentials aplikace, k čemuž nepotřebuje žádné oprávnění navíc (Application.ReadWrite.OwnedBy pro vlastněné aplikace, nebo Application.ReadWrite.All). Tyto změny MazeVault serializuje pro každou aplikaci, i mezi replikami, a výsledek pak ověří. Změnu certifikátů téže aplikace, kterou někdo ve stejné chvíli udělá v portálu Entra, to nechrání a může se ztratit; certifikáty aplikace proto v portálu neupravujte, když je MazeVault rotuje. Chyby Graphu si také ponechávají HTTP status: odpovědi 429/502/503/504 opakuje vlastní backoff MazeVault a 401/403/404 se hlásí jako chyba autentizace, oprávnění a nenalezeno místo unknown.
• Životní cyklus credentials Entra ID hlásí chyby Microsoft Graph — Když Graph po skončení grace period odmítl odebrat starý credential (např. 403), MazeVault ho přesto označil jako uklizený a expirovaný, přestože v Entra dál platil, a odebrání už nezopakoval; teď credential zůstane v grace period, odebrání se zopakuje v dalším hodinovém běhu a kritická notifikace entra.credential.cleanup_failed uvede kategorii chyby (auth, permission, …); odejde při první chybě a pak nejvýš jednou za 24 hodin pro každý credential (migrace 000249 přidává entra_credentials.cleanup_failure_notified_at). Jako uklizený se credential bez notifikace označí jen tehdy, když Graph aplikaci vrátí a klíč na ní už není (např. odebraný v portálu); aplikace, kterou integrace už nevidí (smazaná, odebrané vlastnictví, jiný tenant), credential nechá v grace period a notifikace to uvede. Kontrola entra_connectivity v dry runu rotace teď aplikaci přečte přes Graph místo pouhého sestavení klienta, takže odvolaný secret integrace nebo chybějící oprávnění dry run shodí (u integrací delegovaných na gateway je kontrola beze změny). Sourozenecký credential zaseknutý v rotating déle než 30 minut bez otevřeného běhu zase uvolní další rotace (kontrola používala updated_at, které každá synchronizace obnoví; teď používá rotation_started_at jako watchdog; credentials zaseknuté už před migrací 000175 dál uvolňuje watchdog). Monitor expirace teď posílá kritické upozornění 7 dní předem: credentialu, který poprvé uvidí s méně než 7 dny, a jednou credentialu už varovanému 30 dní předem, když hranici 7 dnů překročí (běh monitoru vynechaný právě v tu chvíli ho přeskočí). Test spojení metod managed_identity a workload_identity teď žádá o token pro Graph (do 5 sekund) místo pouhého sestavení credentialu, takže mimo Azure nebo s chybným client ID selže.
• Agent už nespadne na certifikátu bez jména s krátkým sériovým číslem — Certifikát bez CN a SAN se sériovým číslem kratším než 8 číslic shodil agenta v synchronizační smyčce při skládání názvu souboru; nyní se použije celé sériové číslo.
• Kubernetes operátor přepisoval Secrety, které mu nepatřily — Když už Kubernetes Secret se jménem MazeVaultSecret existoval, operátor do něj zapsal hodnotu z MazeVault, i když patřil někomu jinému. Teď zapisuje jen do Secretu, který nese jeho controller owner reference na daný MazeVaultSecret (nastavuje ji na každý Secret, který vytvořil, takže Secrety vytvořené před upgradem se dál synchronizují); jakýkoli jiný Secret, i takový, který má jen label app.kubernetes.io/managed-by: mazevault-operator, nechá beze změny a resource dostane podmínku Synced=False s důvodem SecretConflict. Konflikt se zjistí dřív, než se hodnota stáhne z MazeVault. Vyřešíte ho přejmenováním nebo smazáním kolidujícího Secretu; synchronizace pak pokračuje při dalším pokusu operátoru (intervaly mezi pokusy rostou až na zhruba 17 minut), nebo hned po změně MazeVaultSecret. Po změně spec.secretKey obsahuje Secret jen nový klíč; hodnota pod předchozím klíčem se odstraní.
• Kubernetes operátor: MAZEVAULT_URL, zpracování chyb a status — MAZEVAULT_URL může být nově prostá adresa serveru (https://mazevault.example.com); operátor /api/v1 doplní sám (adresa, která už končí /api/v1, funguje dál; dříve fungovala jen úplná adresa API a prostá adresa končila 404). Odpověď backendu 404 nebo 403 (backend odpovídá 404 na jakoukoli chybu vyhledání a 403 na odepření politikou) nastaví Synced=False s důvodem FetchFailed a opakuje se v intervalu refreshInterval, ne podle zpětného odstupu chyb; ostatní chyby se dál opakují se zpětným odstupem. Tělo odpovědi backendu se už nekopíruje do zprávy podmínky Synced ani do logu operátoru, jen HTTP status. Status MazeVaultSecret má nové pole observedGeneration (i u podmínky); neúspěšná synchronizace nikdy neposune lastSyncTime.
• OCSP responder neodpovídal standardním klientům ani na certifikáty z backendu — Samostatný OCSP responder (mazevault-ocsp) indexoval CA podle hashe celé struktury veřejného klíče místo issuerKeyHash podle RFC 6960 (hash bitového řetězce veřejného klíče), takže požadavky standardních klientů (OpenSSL, prohlížeče, Go x/crypto/ocsp) dostaly unauthorized; a sloupec certificates.revocation_reason, do kterého backend zapisuje název důvodu nebo prázdný řetězec, četl jako číslo, takže každý certifikát vytvořený backendem dostal internalError. Nyní standardní požadavky najde, stav good/revoked určí z data zneplatnění, kód důvodu podle RFC 5280 vezme ze záznamu o zneplatnění certifikátu, neobsluhuje měkce smazané CA, nepodepíše odpověď certifikátem CA mimo jeho platnost (internalError, zalogováno) a zaloguje každý řádek CA, který nedokáže načíst.
• Přiřazení rolí vytvořená přes Go SDK nebo Terraform byla globální (zkontrolujte je) — Go SDK (a tedy i Terraform resource mazevault_user_role, který ho používá) posílal project_id a environment na nejvyšší úrovni požadavku na přiřazení role, ale backend je čte z vnořeného objektu scope, takže každá takto přidělená role platila globálně místo omezení na projekt nebo prostředí. SDK nyní posílá rozsah v objektu scope (AssignRoleRequest.Scope, který nahrazuje pole ProjectID a Environment na nejvyšší úrovni: uživatelé SDK musí kód upravit). Přiřazení vytvořená přes SDK nebo Terraform před tímto releasem jsou globální: zkontrolujte je (Uživatelé → role, nebo GET /api/v1/rbac/users/{id}/roles) a omezená přiřazení vytvořte znovu.
• Přihlášení a obnova tokenu v Go SDK nefungovaly — Login a RefreshToken volaly /auth/login a /auth/refresh, backend ale obsluhuje /api/v1/auth/login a /api/v1/auth/refresh, takže obě volání skončila 404. Klient SDK navíc neměl cookie jar, cookie refresh_token z přihlášení se proto nikdy neposlala zpět a RefreshToken nemohl uspět. Obě volání teď míří na skutečné routy, NewClient cookie uchovává (klient, který nahradí HTTPClient, si pro obnovu musí nastavit vlastní Jar) a LoginResponse.User.MustChangePasswd se čte z must_change_password, takže vynucená změna hesla se hlásí.
• Go SDK volá jen routy, které backend obsluhuje — ListProjectCSRs volal neexistující /api/v1/projects/{id}/certificate-requests a nově volá /api/v1/projects/{id}/csr, takže funguje Terraform datasource mazevault_project_csrs. Backend nemá routu pro vytvoření šablony certifikátu v projektu ani pro smazání organizace, proto CreateProjectCertificateTemplate (nově zastaralá: šablonu vytvořte přes CreateOrgCertificateTemplate a přiřaďte přes AssignCertificateTemplateToProject) a DeleteOrganization hned selžou: nic neposílají a vracejí chybu obalující nové ErrNotSupported (ověřte přes errors.Is); terraform destroy zdroje mazevault_organization ji rozpozná a zdroj s varováním odebere jen ze stavu, organizace v MazeVault zůstane.
• Go SDK čte seznamy tak, jak je backend vrací — ListKeytabs končil chybou JSON (čekal holé pole, backend vrací stránkovanou obálku {"data": [...], "total", "page", "limit"}), GetRotationResourceHistory a ListSyncRules naopak (čekaly {"executions": [...]} a {"rules": [...]}, backend vrací holé pole); GetSyncRule je postavený na ListSyncRules a selhával s ním. Všechny tři nově dekódují to, co backend posílá, takže Terraform resource mazevault_sync_rule jde znovu načíst, importovat a obnovit a data source mazevault_rotation_resource_history vrací historii. ListKeytabs a ListManagedTokens (a tím i data source mazevault_tokens) nově čtou všechny stránky místo jen první (25 keytabů, 50 tokenů). ListAuditLogsResponse.Total obsahoval délku vrácené stránky, ne celkový počet; endpointy auditního logu celkový počet nevracejí, takže je nově vždy 0 a je označený jako zastaralý — stránkujte přes limit/offset, dokud stránka nemá méně než limit záznamů. Nepoužívané typy ListRotationResourceHistoryResponse a ListSyncRulesResponse jsou označené jako zastaralé.
• Go SDK posílá a čte názvy polí backendu (zkontrolujte volající SDK a první plán Terraformu) — Řada modelů Go SDK používala názvy JSON, které backend nezná, takže hodnoty se tiše zahodily nebo nikdy nevyplnily. Nově odpovídají DTO backendu: schvalovací politiky (required_approvers a dále trigger_type, conditions, allowed_approver_roles/users, auto_expire_hours), šablony konfigurace (template_type a definition jako objekt JSON místo format/template/variables), keytaby (keytab_data a notes místo keytab_base64/description, takže ImportKeytab už nekončí 400), šablony certifikátů (cert_type, validity_days), mapování skupin (provider_id, group_external_id, group_display_name, source, …), workflow rotace (čte rotationIntervalDays/postActions, posílá post_actions), exekuce a historie rotace (error_message), metadata sdíleného secretu (has_password, source_type) a odpověď na vytvoření (link), nastavení projektu (id), expirace CA projektu (not_after), fronta obnovy (scheduled_for, created_at), sync pravidla (objekt key_transform), CA účty (auto_discover, auto_renew, renewal_lead_days, sync_interval_minutes) a spravované tokeny (metadata). UpdateRotationConfigRequest má nově Environment (bez něj ruční spuštění neprojde preflightem), UpdateRenewalPolicy umí vypnout auto_approve a key_reuse_enabled (posílají se vždy) a GetRotationResourceHistoryWithLimit načte víc než výchozích 20 exekucí backendu. Kód v Go se dál přeloží: pole bez protějšku v backendu zůstávají jako zastaralá (deprecated) a většina se už neposílá. Kód, který spoléhal na staré (chybné) názvy na drátě, např. vlastní falešný server, musí použít názvy backendu. CreateRenewalPolicyRequest nově posílá auto_approve a key_reuse_enabled vždy: částečný UpdateRenewalPolicy, který strukturu použije bez jejich nastavení, obě volby vypne, proto nejdřív vyplňte aktuální hodnoty. Stejně tak CreateSyncRuleRequest posílá key_transform vždy: UpdateSyncRule, který strukturu použije bez KeyTransform, transformaci klíčů pravidla zruší. Terraform: mazevault_approval_policy označuje environments a approvers_group_id jako zastaralé (zůstávají ve state, neposílají se); mazevault_config_template posílá format jako template_type a content jako definition (objekt JSON, použijte jsonencode); mazevault_group_mapping posílá group_name jako group_external_id; mazevault_sync_rule posílá key_transform_template jako key_transform.template; data sources mazevault_project_cas, mazevault_project_certificate_templates, mazevault_renewal_queue, mazevault_rotation_executions a mazevault_rotation_resource_history nově vracejí expiraci CA, typ a platnost šablony, čas zařazení do fronty a důvody selhání a mazevault_rotation_resource_history má volitelný limit. Vyžaduje akci při upgradu: hodnoty, které se dosud tiše zahazovaly, se při prvním terraform apply projeví — mazevault_approval_policy.required_approvals (dosud platila výchozí hodnota backendu), mazevault_sync_rule.key_transform_template (při další synchronizaci se klíče v cíli přejmenují podle šablony; odebrání atributu transformaci nově zruší), mazevault_rotation_workflow.post_rotation_actions (akce se nově po každé rotaci spustí) a mazevault_keytab.description (uloží se jako poznámka keytabu). Před apply zkontrolujte plán. mazevault_group_mapping má nový povinný atribut provider_id (backend mapování bez něj odmítne); doplňte ho ke každému mapování — její nastavení u existujícího mapování ho znovu nevytvoří jen tehdy, když se shoduje s aktuálním providerem mapování (načteným z backendu); jiná hodnota mapování znovu vytvoří. mazevault_config_template kontroluje už při plánu format a že content je objekt JSON.
• Go SDK escapuje hodnoty query, volá registrované cesty kolekcí a hlásí skutečný stav konzistence (zkontrolujte volající GetConsistencyStatus) — GetSecret a ListRotationResources vkládaly klíč, druh a scope prostředí do query bez escapování, takže hodnota s &, #, + nebo mezerou poslala jiný požadavek (jiný klíč, useknutou hodnotu); nově se escapuje každá hodnota query. Volání kolekcí (/api/v1/secrets/, /projects/, /organizations/, /users/tokens/, /certificate-templates/) používají cestu, kterou backend registruje, s koncovým lomítkem, místo spoléhání na jeho redirect (dva požadavky na volání a proxy, která 307 změní na 301, by z POST udělala GET). GetConsistencyStatus hlásil warning s MissingCount = počet skupin u každého projektu, který měl nějakou skupinu konzistence; nově hlásí nejhorší stav poslední kontroly skupin (healthy, warning, error), jeden problém na každé nevyřešené varování (<skupina>: <klíč> in <prostředí>: <issue>) a MissingCount = počet varování typu secret_missing. Datový zdroj Terraformu mazevault_consistency_status vrací stejné hodnoty, takže projekt, jehož skupiny nemají nálezy, je nově healthy.
• Terraform: share_url je citlivý, převzetí prostředí respektuje plán, validity_period se validuje (zkontrolujte terraform plan) — mazevault_shared_secret.share_url je nově citlivý: odkaz dává přístup k tajné hodnotě a vypisoval se v plánu a v logu CI; výstupy, které ho zveřejňují, musí mít sensitive = true (nebo použijte nonsensitive()). mazevault_environment převezme existující prostředí se stejným názvem nebo slugem (backend duplicitu odmítne) jen tehdy, když se nakonfigurované is_production a incident_auto_escalation shodují; dříve převzal existující příznaky a hlásil úspěch, takže produkční prostředí zůstalo produkční, i když konfigurace říkala jinak. Apply nově skončí chybou, která rozdílné příznaky vyjmenuje: prostředí importujte nebo upravte konfiguraci. mazevault_certificate_template.validity_period musí být celý počet dní, zapsaný jako <n>d (např. 90d, nově přijímáno) nebo v hodinách (např. 2160h); hodnota, kterou provider neuměl přečíst (dříve např. 90d, 1y), se tiše vynechala a šablona dostala výchozí platnost backendu, a doba, která není celý počet dní (např. 36h), se uřízla na celé dny (1 den); obojí nově odmítne plán (90d se přijímá). mazevault_integration při refreshi obnoví project_id a environment ze serveru.
• Terraform Provider: drift a destroy — mazevault_secret, mazevault_project, mazevault_certificate a mazevault_renewal_policy smazané mimo Terraform se naplánují k opětovnému vytvoření místo selhání refreshe s 404. mazevault_rotation_config už nepadá na „unknown value after apply“ (status, last_error, target_environment) a nehlásí trvalý diff u vynechaného notification_emails nebo schedule. Destroy mazevault_certificate vydaného přes externí CA účet, který MazeVault neumí revokovat, záznam archivuje (s varováním) místo selhání.
• Onboarding: stav master key se po nastavení organizace ztratil — Vygenerování self-signed TLS certifikátu při nastavení organizace uložilo organizaci ze zastaralé kopie v paměti a vymazalo master_key_encrypted, takže stav bootstrapu hlásil master key jako nevygenerovaný. Organizace se před TLS krokem znovu načte.
• Změny licence se při validaci nepropsaly do primary — Primary četl odpověď /api/v1/validate licenčního serveru pod názvy polí, které server neposílá (licenseType, expiresAt místo license_type, expiration_date), takže validace při startu a pak denně uloženou licenci nikdy neaktualizovala. Typ licence změněný na licenčním serveru (např. z POC na Enterprise) nebo prodloužená platnost se nyní do primary propíše při příští validaci; okamžitě ji projeví restart backendu.
• Schvalování CSR v projektu ukazovalo prázdný subjekt a ignorovalo filtr stavu — Záložka CSR projektu nyní u každé žádosti zobrazuje požadovaný common name, organizaci, organizační jednotku a zemi (četla pole, která API neposílá, takže schvalovatel viděl jen PEM). GET /api/v1/projects/{id}/csr nově respektuje volitelný parametr status (např. ?status=pending); bez něj vrací jako dosud všechny nearchivované žádosti. Schválit a Zamítnout se nabízí jen u čekajících žádostí.
• DigiCert: vydané certifikáty se nikdy nepřevzaly, DNS validace byla odmítnuta — Konektor DigiCert CertCentral četl ID certifikátu objednávky z certificate_id na nejvyšší úrovni, CertCentral ho ale vrací jako certificate.id, takže asynchronně vydaná objednávka DigiCert se nikdy nestala dostupnou ke stažení a discovery nenašlo žádné certifikáty DigiCert. Nyní čte vnořené ID. Šablona certifikátu s DCV metodou dns se nově posílá jako dns-txt-token místo dns-txt, kterou CertCentral odmítal.
• ADCS: webový enrollment a enrollment přes CES (WCCE) fungují proti reálným serverům — Webový enrollment posílal požadavek na certrqxt.asp, která jen zobrazí formulář, takže ho ADCS nikdy nezpracovala; nyní ho posílá na certfnsh.asp a požadavek čekající na schválení manažerem si ponechá ID požadavku („Your Request Id is 77.“), takže ho poller schválení dokončí. Enrollment přes CES (WCCE) nyní čte vydaný certifikát z RequestedSecurityToken/BinarySecurityToken a ID požadavku CA z RequestID, jak je definuje MS-WSTEP, a čekající požadavek se dotazuje přes QueryTokenStatus místo Renew; dříve přijímaný tvar odpovědi funguje dál. Uživatelské jméno, heslo i název šablony se v SOAP požadavku XML-escapují, takže heslo s & nebo < už enrollment nerozbije, a CSR se posílá jako DER, jak MS-WSTEP vyžaduje (dříve se posílal PEM text). Stažení CA certifikátu a řetězce přijímá PEM, které certsrv posílá pro Enc=b64.
• Linuxový agent neběžel na hardened hostitelích ani na RHEL 8 — Linuxového agenta na zákaznických hostitelích zastavovaly dvě nezávislé chyby. (1) Binárka agenta v release byla sestavená se zapnutým cgo, byla tedy dynamicky linkovaná proti glibc sestavovacího stroje a na RHEL/Rocky/AlmaLinux 8 selhala s /lib64/libc.so.6: version `GLIBC_2.34' not found; agent se nyní sestavuje s CGO_ENABLED=0 -trimpath, je linkován staticky a běží s libovolnou verzí glibc. (2) Nasazovací instalační skript ukládal binárku do /var/lib/mazevault/bin; na hostitelích s /var připojeným noexec (CIS/STIG baseline) systemd selhal se status=203/EXEC v nekonečné restartovací smyčce. Instalátor i balíček rpm/deb nyní instalují binárku do /opt/mazevault-agent/bin (vlastník uživatel agenta, adresář v ReadWritePaths, aby dál fungoval self-update, SELinux bin_t). Instalátor byl přepracován pro hardened hostitele: set -euo pipefail, preflight (kontrola noexec adresáře binárky přes findmnt, detekce SELinuxu, potřebné nástroje), už žádný fallback curl -k (s CA MazeVault ji stažení použije a při neúspěchu přejde na systémové úložiště důvěryhodných certifikátů, nikdy na nezabezpečený režim), při neúspěšném stažení se vypíše HTTP stav a tělo chybové odpovědi serveru (např. 503 agent binary downloads not configured), selhání curl po HTTP 200 (useknutý přenos) se počítá jako neúspěšné stažení a podepsaná binárka se připraví jako mazevault-agent.new a spustí jako mazevault-agent (version) dříve, než nahradí nainstalovanou binárku a než se zapíše unita, takže noexec připojení, zamítnutí SELinuxem nebo nesoulad glibc instalátor zastaví se srozumitelnou hláškou, dříve nainstalovaného agenta nechá nedotčeného a nikdy nezpůsobí restartovací smyčku, agent.yaml se zapisuje s právy 0640, používá se systemctl restart, aby opakované spuštění aktualizovalo běžícího agenta, hostitelé instalovaní s předchozím rozložením se migrují (stará binárka odstraněna, drop-in přepisy ExecStart odstraněny, ostatní drop-iny zachovány) a návratové kódy jsou 2 preflight / 3 stažení či ověření / 4 služba neběží (stav a journal se vypisují s redigovanými tokeny a UUID). Pokud server nemá nakonfigurovanou CA, instalátor už nezapisuje prázdný ca.crt a vygenerovaný agent.yaml nechává server_ca_file prázdné, takže agent ověřuje server systémovým úložištěm důvěryhodných certifikátů; instalátor pro Windows obdobně prázdnou CA nezapisuje ani neimportuje. Self-update agenta a runner vzdálené odinstalace nyní volí adresář, který je zapisovatelný a není na noexec připojení (adresář binárky, stavový adresář, poté dočasný adresář), místo předpokladu, že /tmp umožňuje spouštění, a pokud žádný nevyhovuje, vypíší odmítnuté adresáře. Vzdálená odinstalace rozpozná hostitele instalované skriptem (bez balíčku rpm/deb): unita, drop-iny a adresáře agenta se odstraní přímo místo selhávajícího rpm -e a zastavení služby, odstranění unity a odstranění /opt/mazevault-agent jsou povinné kroky, jejichž selhání se serveru nahlásí místo falešného úspěchu, /opt/mazevault-agent se odstraní jen tehdy, když v něm binárka skutečně je, a požadavek na roota je vysvětlen v chybové hlášce. Nová volitelná proměnná MAZEVAULT_CA_FILE (release kit, instalátory, check-config.sh, hodnoty Helm, dokumentace) určuje CA vkládanou do instalačních skriptů; Compose kit pro ni připojuje CUSTOM_CERT_DIR do backendu jako /custom-certs. Operátoři, kteří 203/EXEC obešli drop-inem ukazujícím na /usr/local/bin, pouze znovu spustí instalační skript.
• Compose kit nenastartoval: databáze bez TLS, dokumentace bez HTTPS — Při výchozím MAZEVAULT_ENV=production backend odmítá připojení k databázi bez TLS, ale PostgreSQL dodávaný s kitem běžel bez TLS (sslmode=disable), takže backend se nikdy nestal zdravým; kontejner dokumentace naslouchal jen na portu 80, zatímco kit publikoval a kontroloval HTTPS. PostgreSQL v kitu nyní používá TLS s certifikátem z volume certs a backend i OCSP responder se připojují s sslmode=require; kontejner dokumentace obsluhuje HTTPS na portu dokumentace kitu (DOCS_PORT, výchozí 8088), je-li připojen certifikát, jinak prosté HTTP na portu 80 (Helm beze změny). Stávající Compose instalace změnu převezmou spuštěním instalátoru z nového kitu, který nainstaluje jeho docker-compose.yml a ponechá stávající .env i datové volumy (samotný upgrade-mazevault.sh docker-compose.yml nenahrazuje).
• Stažení CRL ve formátu DER vracelo prázdné tělo — GET /api/v1/ca/{id}/crl (výchozí format=der) odpovídal 200 s hlavičkami pro DER, ale bez obsahu; CRL vracel jen format=pem. Endpoint nyní vrací CRL v kódování DER, dekódovaný z uloženého PEM.
• Čísla CRL se opakovala a servírovaný CRL mohl být starý — CRL generované po revokaci braly číslo z vlastního čítače, takže čísla CRL jedné CA se opakovala a šla zpět (RFC 5280 §5.2.3) a GET /api/v1/ca/{id}/crl mohl po vygenerování novějšího CRL dál vracet starší. Všechny CRL jedné CA nyní sdílejí jednu rostoucí řadu čísel navazující na nejvyšší dosud vydané číslo; číslo se přiděluje atomicky v databázi, takže souběžné generování na více replikách nikdy číslo nezopakuje.
• Vestavěné role ztrácely oprávnění přidaná při upgradu — Backend při každém startu přepsal oprávnění vestavěných rolí starším pevným seznamem, takže oprávnění přidaná migracemi zmizela po prvním restartu: report:read/report:write, keytab:read (User, Secret Manager), dashboard:write, agent:admin, audit:read, config:read a project:write (Certificate a Secret Manager) a token:read. Stejně se přepisovaly i úpravy vestavěných rolí provedené zákazníkem. Backend nyní pouze zakládá chybějící role a existující nemění; migrace 000207_restore_system_role_permissions obnoví zamýšlená oprávnění. Zároveň přidělí token:read/token:write/token:delete rolím Project Admin a Secret Manager (migrace 000193 je přidělovala rolím, které už neexistují). Migrace oprávnění pouze přidává a žádná neodebírá, takže stávající přiřazení rolí i úpravy zákazníka zůstávají zachovány.
• Nasazení do keystore přes agenta posílalo balíček, který agent neuměl přečíst — Orchestrovaný krok agent_keystore_sync předával agentovi jediný blob exported_data, zatímco agentův CertificateSyncBundle očekává certificate_pem, private_key_pem a chain_pem; každá rotace do JKS / PKCS#12 / Windows store proto na agentovi selhala s failed to decode certificate PEM a řetězec CA se nikdy nedostal do trust store. Všichni konzumenti nasazení (Kubernetes secret, Key Vault, agent keystore, agent file, Oracle wallet) nyní rozdělují export jediným sdíleným helperem — první certifikát = leaf, další certifikáty = řetězec vydavatelů, klíč zvlášť — který přijímá i base64 podobu po průchodu gateway, a keystore krok posílá přesně ta pole, která agent deserializuje (včetně post_install_command, dříve vnořeného na špatném místě). Jde o opravu pouze na straně backendu/gateway, kompatibilní s již nasazenými agenty.
• Kroky rotace agent_command končily timeoutem u každého agenta — Krok přeposílal HTTP požadavek přes typ proxy zprávy, který agent nikdy neimplementoval, takže restarty služeb a další příkazové kroky čekaly 30 s a selhaly. Krok nyní používá požadavek agenta agent_command (vynucený allowlist) a respektuje timeout_seconds.
• Cíle Agent File, WebLogic a Oracle wallet se nedaly provést — agent_file_sync, agent_file_backup a weblogic_restart builder workflow generoval, ale nikdy nebyly registrovány (unknown step type), a registrované kroky weblogic_deploy / oracle_wallet_deploy vracely executed, aniž by kontaktovaly jakýkoliv hostitel. Tyto cíle nyní běží přes skutečné registrované kroky (viz Nové funkce); sloučené typy kroků weblogic_restart a agent_file_backup jsou odmítnuty s pokynem znovu vytvořit cíl nasazení místo hlášení falešného úspěchu.
• Cíle Web Server a Load Balancer byly tiše přeskakovány — Builder workflow neměl větev pro cíle web_server a load_balancer, takže rotace s takovým cílem hlásila úspěch, aniž by cokoliv nasadila. Nyní jsou při uložení odmítnuty a u již existujících selže sestavení workflow s explicitním důvodem (viz Cíle nasazení se validují při uložení).
• Cíl Database Wallet šel vytvořit bez agenta — UI označovalo Database Wallet jako cíl nevyžadující agenta, přestože nasazení spouští orapki na databázovém hostiteli přes agenta; takové cíle se nikdy nemohly provést. UI i API nyní pro tento typ cíle agenta vyžadují a aktualizace cílů posílané jako JSON dokumenty se explicitně serializují na každém databázovém driveru (GORM u map-based update nespouští serializátory polí; driver Postgres strukturu shodou okolností zakódoval, SQLite ji odmítla).
• Cíl Windows windows_root importoval privátní klíč do úložiště důvěryhodných kořenů — Windows keystore installer sestavoval PFX s privátním klíčem pro každé úložiště a jako cestu k úložišti používal surový typ keystore (windows_root), což není platný název Windows store. Cíle windows_root a windows_ca nyní instalují pouze veřejné certifikáty (leaf do určeného úložiště, řetězec klasifikovaný do Root / CA), windows_my dostává PFX leaf + klíč bez řetězce a typy keystore se mapují na skutečné názvy úložišť My / Root / CA. Backend tomu odpovídá: krok agent_keystore_sync už pro windows_root / windows_ca nevyžaduje privátní klíč (CA certifikát bez klíče lze nyní nasadit do trust store) a private_key_pem pro tato úložiště do bundle nikdy nevkládá, ani když ho export obsahuje; JKS / PKCS#12 / windows_my bez klíče nadále selžou rychle. Hodnota UI Windows Cert Store (keystore_type: windows) nikdy neodpovídala ničemu, co agent přijímá; editor nyní nabízí explicitně Windows — Personal (My), Trusted Root CAs a Intermediate CAs (bez cesty, aliasu a hesla úložiště pro Windows store), uložené cíle se starší hodnotou windows se při provádění kanonizují na windows_my a cíle agent_keystore se validují při uložení (JKS / PKCS#12 potřebují keystore_path; neznámé typy úložiště jsou odmítnuty).
• Starší záznamy mohly exportovat jako leaf špatný certifikát — Certifikáty importované před zavedením leaf_certificate_pem mají v raw_certificate_pem přesně to, co bylo nahráno — může jít o bundle „root, leaf“; nový resolver řetězce zpočátku četl toto surové pole dříve než public_chain_pem (vždy leaf-first), takže by takový záznam exportoval, zobrazoval a nasazoval CA certifikát jako leaf (a hlásil prázdný, úplný řetězec). Leaf se nyní vybírá podle uloženého SHA-256 thumbprintu záznamu bez ohledu na pozici v uloženém materiálu; bez thumbprintu platí dosavadní pořadí (vyhrazené pole leaf → první blok public_chain_pem → surový upload → DER). Kryto regresním testem s root-first surovými bundly pro end-entity i CA záznamy.
• Discovery slučovala více end-entity certifikátů z jednoho souboru — Agent hlásí jeden záznam na každý end-entity certifikát nalezený v PEM souboru, ale jako tělo posílá celý soubor; backend bundle normalizoval heuristikou „první ne-CA blok“, takže soubor se dvěma end-entity certifikáty (starý + obnovený, server + klient) oba reporty sloučil do prvního certifikátu a druhý se nikdy nezaznamenal. Nahlášený fingerprint nyní vybírá leaf uvnitř bundle, sourozenecké end-entity certifikáty jsou z řetězce tohoto leafu vyloučeny a heuristika se použije jen tehdy, když žádný blok neodpovídá.
• Nasazení do osobního úložiště Windows vyžadovalo heslo keystore, které neexistuje — Úložiště Windows My žádné heslo keystore nemá; agent ho potřebuje jen k zabalení dočasného PFX, který na hostiteli importuje a smaže, a PowerShell prázdnou hodnotu odmítne. Cíle typu windows_my bez nakonfigurovaného hesla proto při instalaci selhávaly. Krok agent_keystore_sync nyní vygeneruje jednorázové náhodné heslo PFX, pokud žádné není nakonfigurováno (nikdy se neloguje ani nepersistuje a heslo zadané operátorem je nadále respektováno), takže pro Windows úložiště není třeba zakládat žádný bezvýznamný secret. Na agentovi se heslo PFX předává PowerShellu přes prostředí procesu místo vkládání do skriptu, takže heslo s uvozovkami nebo $ nemůže import rozbít ani být vypsáno zpět v chybě. Pokud nasazení běží přes gateway, odvozuje se jednorázové heslo z idempotency klíče kroku, takže opakovaný pokus předloží identický bundle a agent dokončenou instalaci přehraje místo jejího odmítnutí jako jiné operace. Názvy Windows úložišť agent řeší jedním sdíleným pravidlem: My a jakýkoliv prostý název LocalMachine úložiště nalezený nebo nakonfigurovaný na hostiteli (např. WebHosting, výchozí úložiště IIS na současném Windows Serveru) jsou identity úložiště, která dostanou PFX; Root, CA, AuthRoot, TrustedPublisher a Disallowed jsou trust-anchor úložiště, která dostanou pouze veřejné certifikáty — privátní klíč se do nich nikdy neimportuje, a to ani cestou obnovy či starších metadat; bundle, který pro trust-anchor úložiště nese privátní klíč, je odmítnut s explicitní chybou místo poloviční instalace (obnovený klíč by se jinak tiše ztratil). Názvy, které by mohly změnit PowerShell skript, jsou odmítnuty. Funguje s již nasazenými agenty (samotná změna backendu instalaci opraví).
• Kandidáti vydavatelů z inventáře nebyli identifikováni podle thumbprintu — Vyhledávání vydavatelů v resolveru řetězce nenačítalo thumbprint_sha256 u kandidátních CA záznamů, takže výběr leafu podle thumbprintu zavedený výše se na ně nevztahoval a starší podřízená CA uložená root-first se jako vydavatel nikdy nenabídla (řetězec zůstal neúplný — bezpečné, ale doplnění neproběhlo). Sloupec se nyní načítá a regresní test pokrývá kandidáta uloženého root-first.
• Import privátního klíče přijal libovolný klíč k certifikátu bez těla — POST /discovered-certificates/{id}/import-key přeskakoval kontrolu shody klíče a certifikátu, když spravovaný certifikát neměl uložené tělo (podoba, kterou před touto verzí produkovala každá adopce), takže se mohl tiše uložit nesouhlasící klíč a selhat až při nasazení. Import nyní takový požadavek odmítne s explicitní chybou, dokud tělo neexistuje.
• Připojení klíče ke spravovanému certifikátu bez těla ho nechalo bez těla — Update cesta importu připojila klíč, ale na záznamy bez těla neuložila leaf PEM / DER; nyní tělo připojí, zachová bohatší uložený řetězec a chybějící řetězec doplní z inventáře.
• Import certifikátu bral identitu z prvního PEM bloku — Bundly v pořadí root, intermediate, leaf (jak je vydávají některé nástroje) byly zaznamenány s common name, serialem a otiskem rootu, zatímco uložené tělo byl leaf. Identita a metadata se nyní odvozují z normalizovaného leafu bez ohledu na pořadí bloků.
• Import více souborů zahazoval samostatné soubory s klíčem — Nahrání certifikátu spolu se samostatným .key souborem klíč tiše zahodilo (UI tvrdilo, že byl spárován při náhledu) a importovalo pouze certifikát, takže opakovaný import spravovaného certifikátu za účelem doplnění klíče vždy skončil chybou „already exists“. Klíč se nyní páruje na backendu a importuje společně s certifikátem.
• Rotace tajemství už neselhává na cizím klíči zálohy — Každá rotace tajemství padala v ságe na pozadí s insert or update on table "rotation_backups" violates foreign key constraint "rotation_backups_execution_id_fkey". Záloha před rotací vznikala dříve, než existoval řádek exekuce rotace, a nikdy nenastavila execution_id, takže nenulový cizí klíč insert odmítl a žádná rotace nemohla proběhnout. Záloha se nyní vytváří uvnitř exekuce (po runtime probe, před prvním mutujícím krokem) s platným execution_id a rozřešení organizace je ověřeno předem. Regrese byla neviditelná, protože testovací harness SQLite nevynucuje cizí klíče a omezení existuje jen v SQL migraci; reálnou insert cestu nyní pokrývá test s vynuceným cizím klíčem.
• Migrace rotačních šablon korektně zpracují nová pole politiky — Perzistenční cesta rotačních šablon a její migrace byly opraveny tak, aby nově přidaná pole politiky (lead_time_days, grace_period_days, secret_custody_mode) konzistentně kolovala mezi API, SDK, providerem a uloženým katalogem.
• Aktualizace rotační šablony už nepadá při částečných úpravách — Dekodér požadavku create/update rotační šablony dereferencoval typované nil ukazatele, takže jakýkoli požadavek, který vynechal volitelné pole — běžný případ u úpravy jediného pole, například změny pouze intervalu — způsobil paniku a vrátil HTTP 500. Dekodér nyní rozlišuje přítomnost: vynechaná pole se přeskočí, explicitní 0 nebo false se zachová jako zamýšlená hodnota a project_id lze nastavit, změnit nebo vymazat (explicitním null) bez dopadu na ostatní pole.
• Vyřazení agenti se mohou znovu zaregistrovat autorizovaným náhradním tokenem — Re-registrace odregistrovaného nebo revokovaného agenta byla rovnou odmítnuta, takže vyměněný host se nemohl vrátit ani s jednorázovým tokenem vydaným přes reregister. Re-enrollment vyřazeného agenta je nyní povolen pouze účelově vydaným náhradním tokenem — rozlišeným novým diskriminátorem purpose na deployment tokenech — zatímco zastaralé deployment tokeny ani recovery tokeny jej stále nemohou vzkřísit; při úspěchu se vyčistí markery vyřazení agenta a jednorázový token se spotřebuje.
• Vzdálená odinstalace selže čistě a hlásí selhání spuštění runneru — Vzdálená odinstalace nyní předem odmítne host bez podporovaného správce balíčků (apt-get/rpm) jako nepodporovaný, místo aby hlásila úspěch po best-effort úklidu, zatímco balíček zůstal nainstalovaný. Pokud se odpojený odinstalační runner nepodaří spustit, agent nyní toto terminální selhání nahlásí zpět přes health kanál — a smíří již přijatou operaci — místo pouhého lokálního zalogování.
• Rotace keytab selže bezpečně (fail-closed) při chybě dotazu na stav agenta — Chyba databáze při zjišťování stavu agenta u keytab cíle již není považována za „neaktivní“ (což tiše přeskočilo nasazení, ale rotaci hlásilo jako dokončenou). Rotace nyní při chybě dotazu selže bezpečně a přeskočí pouze potvrzeně neaktivního agenta.
• Potvrzení zálohy rotace omezeno na stav recovery_required — POST /rotation/backups/{id}/acknowledge nyní přepíná pouze zálohu, která je skutečně ve stavu recovery_required, a vrací 404 pro neznámé id a 409 pro jakýkoli jiný stav životního cyklu, místo tichého přepsání zálohy v libovolném stavu.
• Import Terraform mazevault_deployment obnoví organizaci — Read resource deploymentu nyní znovu naplní organization_id ze serveru, takže importovaný deployment lze zničit; dříve delete volání posílalo prázdnou organizaci a bylo odmítnuto s 400.
• Zákaznický Helm chart používá Redis místo tichého přechodu na paměťovou cache — Zákaznický Helm chart měl ve výchozím stavu externalRedis.connectionQuery: abortConnect=false, což je volba StackExchange.Redis (.NET), kterou Redis klient Go backendu odmítá (redis: unexpected option). Backend proto přecházel na paměťovou cache, stav gatewaye nemohl používat Redis a OCSP responder při startu padal do restartovací smyčky. Výchozí hodnota je nyní prázdná a chart odmítne vyrenderovat, pokud connectionQuery obsahuje abortConnect — zákazníci, kteří ho mají ve vlastních values, ho musí odstranit. Backend ani OCSP responder navíc při selhání parsování nebo připojení k Redisu už nelogují heslo: URL v chybách připojení jsou redigovány a chyby parsování URL už neopakují původní URL.
• Poznámka u certifikátu odmítnuta pod zobrazeným limitem 256 znaků — Uložení Poznámky (Note) u certifikátu selhávalo i u textu výrazně kratšího než inzerovaných 256 znaků, pokud obsahoval ne-ASCII znaky (například českou diakritiku), a detail certifikátu neposkytl žádnou zpětnou vazbu. Backend vynucoval limit v UTF-8 bajtech, zatímco počítadlo v UI, validátor požadavku i sloupec VARCHAR(256) počítají znaky — dvoubajtový znak jako ř tak spotřeboval dvě jednotky kvóty (u běžného českého textu byl efektivní strop ≈240 znaků). Stejná bajtová kontrola se týkala i tagů certifikátu (64) a dokumentační URL (500). Všechny tři limity jsou nyní na každé vrstvě vynucovány v Unicode znacích, editor poznámky počítá a ořezává po code pointech (emoji se počítá jako jeden znak) a plných 256 znaků lze uložit bez ohledu na písmo. Sekce Tagy / Dokumentace / Poznámka navíc již nepolyká chyby API: validační chyby i chyby oprávnění se zobrazují přímo u pole, editor ponechá rozepsaný text otevřený k opravě a probíhající uložení nelze odeslat dvakrát. Import certifikátu nyní aplikuje stejnou normalizaci tagů (ořez mezer, deduplikace, limity 64 znaků / 50 tagů) jako editor v detailu. Tělo požadavku PUT /certificates/{id} (UpdateCertificateRequest) je nyní popsáno v OpenAPI specifikaci. Změna schématu není potřeba.
• Spravované tokeny nešlo v Orchestrator módu uložit do Azure Key Vault — Vytvoření nebo obnova spravovaného tokenu (POST /tokens, POST /tokens/{id}/renew) v Orchestrator módu selhávalo s 500 failed to offload token value to external provider, pokud byl cílem offloadu Azure Key Vault. Obecná offload cesta pojmenovala každou hodnotu bez certifikačních metadat mazevault-keys/key-<unix-timestamp> — cestový identifikátor navržený pro HashiCorp Vault, který Key Vault odmítá, protože názvy secretů smí obsahovat jen [0-9a-zA-Z-] (400 BadParameter: Method PUT does not allow operation 'key-…'). Stejný identifikátor používaly keytaby a privátní klíče importované přes discovery (mazevault-keys/<cn>-<serial>, s tečkami z CN), takže i tyto offloady na Azure selhávaly. Identifikátor se nyní generuje podle providera: Key Vault dostane plochý, čitelný a kolizím odolný název (mazevault-token-<název-tokenu>-<id>, mazevault-keytab-<principal>-<id>, mazevault-<cn>-<serial>), který se validuje proti kontraktu Key Vaultu ještě před odesláním požadavku; HashiCorp Vault a AWS Secrets Manager zachovávají historické uspořádání mazevault-keys/… beze změny. Samotná hodnota tokenu se nikdy nemění — je base64 kódována pro přenos přesně jako dřív a vrací se byte-po-bytu (pokryto testem s shell metaznaky, bílými znaky i Unicode). Tvrdý limit Key Vaultu na jeden secret (25 600 bajtů zakódovaného payloadu, ≈19 200 raw bajtů) se nyní kontroluje předem a hlásí jako 400 s přesným limitem a velikostí odeslané hodnoty místo obecné 500 z Azure; explicitní název secretu porušující vzor Key Vaultu je rovněž odmítnut jako 400, nikoli tiše přepsán. Společně bylo opraveno několik latentních vad ve stejné cestě: token service předávala tenanta pod špatným metadata klíčem (org_id místo organization_id), takže se offload integrace vybírala napříč celým systémem — první povolená secret-manager integrace jakékoli organizace — a reveal / delete tokenu řešily integraci bez jakéhokoli tenant scope; výběr integrace je nyní scopovaný projekt → organizace a nikdy se nerozšíří na vault jiného tenanta (explicitně zvolené integration_id, které chybí nebo je vypnuté, je odmítnuto místo nahrazení jiným); obnova tokenu mazala předchozí externí hodnotu dřív, než byla zapsána nová, takže neúspěšný offload nechal token bez hodnoty — pořadí je nyní zapsat → persistovat → odstranit starou, neúspěšná obnova ponechá předchozí hodnotu netknutou a neúspěšný insert metadat odstraní právě odloženou hodnotu; uložená Azure reference s verzí by při aktualizaci vytvořila nový secret pojmenovaný GUIDem verze — holý název secretu se nyní extrahuje správně; asynchronní worker pro offload secretů dotazoval neexistující sloupec is_active na project_integrations (skutečný příznak je enabled); custody události tokenů a keytabů nyní odkazují na vlastnící záznam, typ klíče a jednajícího uživatele místo náhodného UUID; a sériové číslo certifikátu kratší než osm znaků už nezpůsobí panic generátoru názvů. Není potřeba databázová migrace, změna API ani konfigurace.
• Windows agent instalovaný z generovaného skriptu se nespustil jako služba — Instalační skript končil chybou neznámého příkazu install a agent nemohl běžet jako služba Windows. Agent nyní běží jako služba MazeVaultAgent (automatický start, automatický restart při selhání) z C:\Program Files\MazeVault Agent\, data a logy zůstávají v C:\ProgramData\MazeVault\; agent získal podpříkazy install a uninstall. Opětovné spuštění skriptu aktualizuje na místě a migruje dřívější rozložení; na hostu s balíčkem MSI skript odmítne běžet. C:\ProgramData\MazeVault\ (bootstrap token, privátní klíč agenta, pre-seed soubor) je nyní čitelný jen pro SYSTEM a Administrators; dřívější instalace jej nechávaly čitelný pro každého lokálního uživatele, proto na existujících Windows hostech skript spusťte znovu.
• Ověření přihlašovacích údajů MongoDB přijalo s connection URI jakékoliv heslo — U MongoDB integrace nastavené přes connection URI se ověření údajů rotovaného uživatele přihlašovalo uživatelem z URI (obvykle adminem) místo rotovaného uživatele, takže prošlo i špatné nové heslo a staré heslo nebylo nikdy odmítnuto. Ověření se nyní přihlašuje jako rotovaný uživatel vůči nastavené autentizační databázi (výchozí admin) a zachovává hostitele a volby z URI. Připojení přes host/port se navíc vůbec nenavázalo (must have a / before the query ?); sestavované URI je opravené.
• Ověření přihlašovacích údajů Oracle přijalo s connection stringem jakékoliv heslo — Stejná chyba postihovala Oracle integrace nastavené přes connection_string: ověření se připojovalo uživatelem z connection stringu místo rotovaného uživatele. Nyní v connection stringu nahradí uživatele a heslo údaji rotovaného uživatele a zbytek řetězce zachová.
• Ověření přihlašovacích údajů MSSQL ignorovalo rotovaného uživatele v režimech Windows a Azure AD — Při auth_mode windows se ověření údajů rotovaného uživatele přihlašovalo vlastní Windows identitou backendu a jméno s heslem ignorovalo; při azure_ad zkoušelo přihlášení přes Azure AD pro databázového uživatele s heslem, takže mohlo odmítnout i správné heslo. Ověření nyní vždy používá SQL autentizaci s rotovaným uživatelem, jak se rotovaní uživatelé zakládají; připojení admina si ponechává nastavený režim.
• CLI končilo při chybě kódem 0 a ignorovalo --profile a --config — Každý příkaz mazevault chybu jen vypsal a skončil kódem 0, takže skripty a CI nepoznaly neúspěšné volání (např. mazevault secrets get proti serveru, který vrací 500). Příkazy teď při jakékoliv chybě končí kódem 1: chybějící nebo neznámé přepínače a příkazy (hláška na stdout jako dřív) i selhané volání API, chyba konfigurace nebo klíčenky (Error: … na stderr). --profile/-p se nečetl, CLI tak vždy volalo server profilu current_profile; teď pro daný běh zvolí server profilu i jeho uložené tokeny. --config/-c se ignoroval, vždy vyhrál ~/.mazevault/config.yaml; teď se čte zadaný soubor (jako YAML). Před upgradem zkontrolujte skripty: --profile, který v konfiguraci není, teď skončí kódem 1 (profile '<name>' not found) místo tichého použití current_profile, a neexistující soubor --config skončí chybou místo použití výchozí konfigurace. Uložené přihlašovací tokeny jsou teď vázané na server, který je vydal, a jinému serveru se nikdy nepošlou (dřív --config se stejně pojmenovaným profilem mířícím jinam poslal token tomu serveru); tokeny uložené starším CLI server neuvádějí, proto se po upgradu jednou přihlaste mazevault auth login.
• CLI secrets get, list a delete, špatné heslo a vypršené sezení — mazevault secrets get, secrets list a secrets delete volaly cesty, které server nemá, a nikdy nefungovaly. get nově čte tajemství z GET /api/v1/secrets?project_id&key&environment, list z GET /api/v1/projects/{id}/secrets?environment=… a delete najde id tajemství v tomto seznamu (přesná shoda klíče a prostředí; žádná nebo víc shod nic nesmaže) a volá DELETE /api/v1/secrets/{id}. Výstup secrets list v JSON/YAML pojmenovává čas změny updated_at (dříve last_modified). Špatné heslo u mazevault auth login (i LDAP) nově hlásí login failed: 401 Unauthorized místo unauthorized: please login again. Při vypršeném uloženém refresh tokenu CLI spadlo na přetečení zásobníku; nově skončí hláškou session expired, please login again. Obnovené sezení uloží novou platnost i vyměněný refresh token; odpověď přihlášení nebo obnovení bez expires_in už token neoznačí za okamžitě vypršený. CLI zatím sezení obnovit neumí (server čte refresh token jen z cookie), po vypršení sezení se proto znovu přihlaste.
• Integrace OCI Vault nedokázala vytvořit secret a vypisovala smazané secrety — Vytvoření secretu v OCI Vault (například z pravidla synchronizace) vždy selhalo, protože požadavek neuváděl master encryption key, který OCI vyžaduje. Konfigurace integrace OCI Vault má nově pole key_id, OCID master encryption key trezoru; nastavte ho u každé integrace OCI Vault, která má secrety vytvářet (bez něj vytvoření secretu skončí srozumitelnou chybou a do OCI se nic neodešle). Čtení, výpis, aktualizace ani mazání secretů ho nepotřebují. Výpis a hledání podle jména nově vracejí jen secrety ve stavu ACTIVE, takže secret smazaný přes MazeVault (v OCI 30 dní ve stavu PENDING_DELETION) se už neobjevuje ve výpisu ani v importu externích secretů a jméno se přeloží na aktivní secret, ne na smazaný se stejným jménem.
• Reconcilery databází: drain sessions MongoDB, hesla PostgreSQL, přihlášení k Azure SQL a volby MSSQL — Ukončení sessions jednoho uživatele MongoDB ukončilo všechny operace v clusteru, všech uživatelů; nově ukončí jen operace běžící pod tímto uživatelem v jeho autentizační databázi (auth_database, výchozí admin). Reconciler PostgreSQL se nepřipojil, když jméno nebo heslo obsahovalo znaky URL jako #, / nebo ?; všechny hodnoty se nově kódují. Reconciler MSSQL se k Azure SQL s auth_mode: azure_ad přihlašoval jako SQL login a selhal; nově používá ověření Microsoft Entra: s tokenem (service principal, managed identity, DefaultAzureCredential; s use_msi nově client_id vybere user-assigned managed identity, dříve se vždy použila system-assigned) a v režimu s heslem přes veřejnou klientskou aplikaci v client_id, kterou tento režim nově vyžaduje. Volba MSSQL keep_alive: true znemožnila každé připojení; keep_alive je nově perioda keep-alive v sekundách (true ponechá výchozích 30 s ovladače) a connection_timeout, login_timeout (použije se, když connection_timeout není nastaven) a keep_alive uložené z webového rozhraní se už neignorují. keep_alive_interval nemá žádný účinek.
• Rotace databáze PostgreSQL se správně vrací a sjednocuje — Neúspěšná rotace PostgreSQL integrace zadané přes host, port a databázi (tvar, který vytváří UI) nyní vrátí předchozí heslo; návrat se dřív připojoval jen přes connection string. Návrat rotace sqluser:<role>:<user> (PostgreSQL i Oracle) obnoví heslo tohoto uživatele, ne uživatele z username integrace; návrat ensure žádné heslo nemění a hlásí, že změny rolí je nutné vrátit ručně, a chybějící host je chyba místo připojení na localhost. Operace ensure smaže nežádoucí roli, kterou vytvořil admin integrace (PostgreSQL 16+ zapisuje tvůrce jako člena, takže se taková role nemazala), a poškozený desired_json, undesired_json, grants_json nebo aad_members_json konektory PostgreSQL, Oracle a MongoDB odmítnou chybou invalid <pole> (jako už MSSQL) místo hlášení reconciled bez provedení změn.
• HSM zařízení PKCS#11 zůstávají použitelná i po nové instanciaci a vypisují své klíče — Druhé zařízení PKCS#11 HSM na stejném modulu nebo totéž zařízení po úpravě, neúspěšné sondě stavu či pětiminutovém obnovení provideru skončilo chybou CKR_CRYPTOKI_ALREADY_INITIALIZED a zůstalo nedostupné až do restartu backendu; totéž potkalo CA nastavenou na PKCS#11 HSM po jejím prvním použití. Modul se nově inicializuje jednou za běh backendu a je sdílený a nahrazený provider zařízení zavře svou HSM session. CA na PKCS#11 HSM drží jednu HSM session, dokud se nezmění její konfigurace HSM (dříve vydání, obnova i plánované běhy pokaždé otevřely novou session a nikdy ji nezavřely). Když je k tokenu přihlášené jedno zařízení, jiné zařízení na stejném tokenu projde jen se stejným PINem: se špatným nebo chybějícím PINem se hlásí jako nedostupné a změněný PIN začne platit, až se zavřou všechny session tokenu (např. po restartu backendu). Souběžné operace na jednom PKCS#11 zařízení už neshodí backend. Výpis a detail klíčů zařízení nově čtou velikost klíče z modulu, takže klíče na tokenu podle standardu (např. SoftHSM2) se vypíší a nepřeskakují.
• Sledování Azure Key Vault hlásí nové verze secretů — Sledování externích změn integrace Azure Key Vault hlásilo jen vytvořené a smazané secrety; novou verzi existujícího secretu (hodnotu změněnou přímo v Key Vaultu) nikdy nenahlásilo, takže nevzniklo varování o rozdílu. Sledování teď vychází z času poslední změny v seznamu secretů a jen u změněného secretu načte seznam jeho verzí (nečte žádné hodnoty, stačí oprávnění list); změnu nahlásí, když se změnila aktuální verze, samotnou úpravu tagů nehlásí. Reference klíče, která není id secretu nakonfigurovaného trezoru, se nyní odmítne. Hodnota šifrovaná end-to-end, kterou nejde dešifrovat, je nyní chyba místo vrácení šifrované obálky a vzdálený identifikátor ukládaný při synchronizaci certifikátu a po rotaci do Key Vaultu už neobsahuje dvojité lomítko, když vault_url končí /.
• Průvodce integrací načítá agenty, používá výchozí hodnoty organizace a zobrazuje chyby z backendu — „Key Vault is behind Private Endpoint“ v průvodci integrací nově vypíše agenty projektu (volal neexistující endpoint a zobrazil „Failed to load agents“) a umožní vybrat agenta ve stavu active (dřív šel vybrat jen neexistující stav online). Krok databáze použije bezpečnostní výchozí hodnoty organizace až po načtení prostředí organizace, takže prostředí jako prod označené jako produkční dostane produkční výchozí hodnoty. Chyby při ukládání integrace, testu připojení, náhledu aplikací Entra nebo ukládání cíle nasazení secretu ukážou zprávu z backendu místo „Request failed with status code 400“.
• Discovery agenta najde nové certifikáty při každém skenu a cache hesel sdílí bezpečně — Agent po prvním skenu souborového systému považoval prohledané kořeny za hotové a při každém dalším hodinovém skenu je až do restartu přeskakoval, takže certifikáty přidané mezitím nikdy nenašel; každý sken teď projde všechny kořeny znovu. Sken přerušený ukončením procesu nebo pádem se po restartu dál obnoví; zrušený sken začne procházet znovu a zachová si postup po souborech (nezměněné soubory znovu neparsuje). Hesla keystorů schválená v MazeVaultu i nalezená během skenu drží cache bezpečná pro souběžný přístup, takže schválené heslo, které dorazí během skenu nebo obnovy, už agenta neshodí chybou concurrent map writes. Hledání nápověd k heslům na lokálních discích běží nejvýš jednou za sken scanneru souborového systému a JKS, ne jednou pro každý keystore, a hledání odpovídajícího privátního klíče vedle certifikátu přeskočí soubory větší než 1 MiB. key_vault_secret_id z JSON souboru vedle keystoru se stáhne jen z URL https://….vault.azure.net; managed-identity token hosta se jinému hostiteli nikdy nepošle.
• Lokální obnova certifikátu agentem instaluje jen odpovídající certifikát, obnoví nalezené PKCS#12 keystory a šifruje rozpracovaný stav — Obnova PKCS#12 s reuse_key nyní doběhne; dříve byl klíč načtený z keystoru chybně označen a instalace vždy selhala. Agent odmítne vydaný certifikát, který neodpovídá privátnímu klíči, jež připravil, takže chybný certifikát už nenahradí funkční soubor ani keystore. Keystore PKCS#12 nebo JKS nalezený souborovým scannerem (typ filesystem s keystore_type) backend nyní nabídne k lokální obnově a agent ho přijme. Rozpracovaná obnova v <state_dir>/pending-renewals/ je nyní šifrovaná klíčem odvozeným z mTLS klíče agenta (client_key_file) místo privátního klíče a hesla keystoru v čistém textu; agent bez mTLS klíče drží rozpracovanou obnovu jen v paměti, takže po restartu mezi přípravou a instalací instalace odpoví „renewal operation not found or expired“ a obnovu je třeba spustit znovu. Soubor, který starší agent zapsal v čistém textu, se při prvním načtení znovu zašifruje, nebo se bez mTLS klíče přesune do paměti a smaže. Payload úlohy obnovy se nemění.
• Konflikty synchronizace Entra jde vypsat i vyřešit — GET /api/v1/entra/{integrationId}/sync-conflicts a POST /api/v1/entra/sync-conflicts/{id}/resolve nefungovaly: každý čekající konflikt byl odmítnut jako už vyřešený (500). Konflikt se nyní vyřeší jednou. Neznámý konflikt vrací 404 a už vyřešený konflikt 409, i když se sejdou dvě souběžná vyřešení. Hodnoty resolution v požadavku zůstávají local_wins, remote_wins a manual. Ukládají se jako use_mazevault, use_entra a use_merged. JSON konfliktu nyní používá uložená pole: field_name, mazevault_value, entra_value, status (pending, resolved, ignored), resolution, resolved_value a resolution_notes. Ta nahrazují field, local_value a remote_value.
• Více zero-knowledge secretů v jednom prostředí; jména smazaných a archivovaných secretů jdou použít znovu — Druhý zero-knowledge (v2) secret ve stejném projektu a prostředí nešel založit (chyba serveru) a jméno smazaného nebo archivovaného secretu nešlo použít znovu. Jedinečnost nyní platí jen pro živé secrety: v prostředí projektu jeden živý secret na jméno a jeden živý zero-knowledge secret na blind index (databázová migrace 000276). Obnova archivovaného secretu, jehož jméno (nebo blind index) mezitím použil jiný secret, odpoví 409 Conflict a secret zůstane archivovaný; nejdřív archivujte nebo smažte novější secret. Migrace se nespustí, pokud už živé secrety v jednom prostředí sdílejí jméno nebo blind index, a vypíše je; nadbytečné archivujte nebo smažte a spusťte ji znovu. Návrat migrace (rollback) se odmítne, dokud existují řádky, které by starý index nepřijal (např. více zero-knowledge secretů v jednom prostředí).
• Přepínače se zapnutou výchozí hodnotou zachovají výslovné vypnutí — Uložení false u příznaku, který je ve výchozím stavu zapnutý, dříve uložilo true: auto_renew a auto_discover CA účtu (účet SSLmarket přepnutý na ruční obnovu už nezakládá placené objednávky), příznaky šablony automatická archivace, oznámení incidentů a automatická obnova, exists a compare_enabled prostředí projektu, enabled rotačního resource a cíle rotace (cíl založený vypnutý se už nenasazuje) a custody události neúspěšných akcí s klíči (nově se počítají jako selhání). Záznamy uložené před upgradem se nemění: zkontrolujte CA účty, které jste dříve přepnuli na ruční obnovu, mohou mít automatickou obnovu stále zapnutou.
• Výměna klíčů ECDH funguje, integraci, ze které secrety čerpají, jde smazat, povýšení v Entra je v historii rotací — Migrace 000274 vytvoří tabulku session_keys, kterou žádná migrace nevytvářela, takže každá výměna klíčů selhala; zároveň rozšíří rotation_executions.config_type na 50 znaků, takže povýšení postupně nasazeného sekundárního credentialu Entra na primární se nyní zapíše do historie rotací a reportů (typ o 22 znacích se nevešel a chyba se ignorovala; záznam se nyní zapisuje v transakci povýšení, takže při chybě se povýšení vrátí). Migrace 000275 znovu vytvoří cizí klíč secrets.external_integration_id s ON DELETE SET NULL: smazání integrace, kterou secrety používají jako zdroj (typicky names_only secrety v orchestrator režimu), skončilo chybou cizího klíče; nyní projde, tyto secrety se nahlásí jako osiřelé (v orchestrator režimu označí jako chybějící) a odkaz ztratí. Odkaz na integraci, která už neexistuje (možný jen tam, kde cizí klíč nikdy nevznikl), migrace zaloguje a nastaví na NULL.
• Vault a interní CA vydávají certifikáty v mezích šablony a platnosti CA — Účet Vault CA bez mount_path používá výchozí mount pki i pro stav a výpis certifikátů (dříve se stav ptal na špatnou cestu a hlásil certifikáty jako odvolané) a podepisování ve Vaultu bere platnost ze šablony místo default_ttl účtu. Interní CA omezí platnost certifikátu koncem platnosti samotné CA, po vypršení vlastního certifikátu odmítne podepisovat, podpis bez šablony certifikátu odmítne chybou místo pádu a u podřízené CA vrací řetěz až ke kořeni. Znovu vytvořené providery Vaultu už nenechávají běžet rutiny pro obnovu tokenu.
• TLS certifikát serveru: nesouhlasící pár klíčů se odmítne, výměny se auditují — Nahrání systémového certifikátu (POST /api/v1/system/certificate) s privátním klíčem jiného certifikátu nebo s nečitelným certifikátem nyní vrátí 400 místo 500 a každá úspěšná výměna zapíše auditní událost SYSTEM_CERTIFICATE_REPLACED (kdo, kdy, subjekt, sériové číslo a expirace; nikdy klíč). Self-signed certifikát vytvořený při úvodním nastavení pokrývá hostitele z webové adresy organizace (dříve v něm byla celá URL a neodpovídala žádnému hostiteli) a už nesmaže hlavní klíč vygenerovaný ve stejném kroku bootstrapu.
• Exporty certifikátů se auditují, automatická archivace podle šablony běží, synchronizace stavů z CA používá nastavení účtu — Každý export certifikátu (GET /api/v1/certificates/{id}/export, i s privátním klíčem) zapíše auditní událost CERTIFICATE_EXPORT s uživatelem, formátem, informací, zda šel ven klíč, a výsledkem (i neúspěšný, také když privátní klíč nejde přečíst nebo získat); heslo ani klíč se nikdy nezapisují. Expirované certifikáty se každou hodinu archivují, pokud má jejich šablona zapnuté „automaticky archivovat expirované“, po uplynutí „archivovat po dnech“ (volba dříve neměla účinek); každá automatická archivace zapíše auditní událost ARCHIVE_CERTIFICATE a obnovený certifikát jde znovu používat. Pravidelná synchronizace stavů s externími CA používá nastavení CA účtu (např. sandbox nebo vlastní URL SSLmarketu) místo výchozího endpointu providera.
• Zrušení obnovy zachová dokončené obnovy, import PFX zachová jediný certifikát CA, úklid DCV v Cloudflare hlásí chyby — POST /api/v1/renewal-queue/{id}/cancel už nepřepíše dokončenou obnovu na zrušenou (vrátí 409) a pro neznámé ID vrátí 404 místo úspěchu. Opakovaná oprava předání obnovy, která už jednou proběhla, nekončí chybou. Import PFX přes záložní cestu OpenSSL zachová řetěz i s jediným certifikátem CA (dříve se zahodil). Odstranění DNS-01 záznamu _acme-challenge z Cloudflare ohlásí chybu, když ho Cloudflare odmítne (např. token bez práva upravovat DNS), místo aby záznam tiše zůstal.
• Notifikační a monitorovací poskytovatelé hlásí skutečný výsledek doručení — Událost nebo metrika Dynatrace odmítnutá API (např. 401 s propadlým tokenem) a SMS odmítnutá SMSEagle (HTTP 200 s chybovým textem, např. Invalid login or password) jsou nyní chybou v logu místo doručení. Webhooky Microsoft Teams vytvořené přes Power Automate Workflows odpovídají 202, což se nyní bere jako úspěšné doručení. Alerty pro Zabbix se zahazovaly a metriky se posílaly ve formátu zabbix_sender přes HTTP: obojí nyní jde přes metodu API Zabbixu history.push (Zabbix 7.0 nebo novější) na ZABBIX_URL (URL frontendu; /api_jsonrpc.php se doplní, pokud chybí), s API tokenem v nové proměnné ZABBIX_TOKEN (patří do úložiště secretů); alerty jdou do trapper položky mazevault.alert (typ text) a metriky do trapper položek pojmenovaných podle klíče, vše na hostu ZABBIX_HOSTNAME, takže tyto položky vytvořte (pokud položka omezuje „Allowed hosts“, uveďte adresu frontendu Zabbixu). Nepoužívaný mock balíček webhooků je odstraněn.
• E-mailová upozornění mají správný tvar a týdenní report vynechá neaktivní kanály — Zprávy SMTP nyní mají hlavičky From a Date (RFC 5322); některé poštovní servery zprávy bez nich odmítaly nebo řadily do spamu. Předmět s koncem řádku nebo znaky mimo ASCII se kóduje podle RFC 2047, takže název prostředku, např. klíč secretu nebo common name objeveného certifikátu, už nemůže do upozornění přidat hlavičky (např. Bcc); adresa s koncem řádku je odmítnuta. HTML e-maily (týdenní report, odkazy na sdílení) mají správné hlavičky MIME-Version / Content-Type. Týdenní report jde jen do kanálů s povoleným reportem, jejichž integrace je aktivní.
• Exporty reportů: buňky CSV se nespustí jako vzorec, Terraform export zůstane platný — Buňka exportu CSV začínající =, +, -, @, tabulátorem nebo CR (např. common name certifikátu =HYPERLINK(…) nebo název projektu) nyní dostane na začátek ', takže ji Excel nebo LibreOffice zobrazí jako text a nevyhodnotí. Terraform export projektu nebo organizace dá klíči secretu, který existuje ve více prostředích, samostatný resource pro každé prostředí (db_password, db_password_prod) místo duplicitní adresy, escapuje uvozovky, zpětná lomítka, konce řádků a ${ / %{ v názvech, klíčích a prostředích a každý znak labelu resource mimo písmena, číslice a _ nahradí _.
• Znovu připojený agent zůstane připojený; nový sken zachová rozhodnutí operátora o objevených konfiguračních souborech — Když se agent znovu připojil, uzavření jeho předchozího WebSocketu odstranilo i nové spojení, takže agent vypadal jako nepřipojený a synchronizace certifikátů, secretů i příkazy agentovi selhávaly s agent not connected, dokud se nepřipojil znovu. Staré spojení nyní nové nechá být. Konfigurační soubor ignorovaný nebo adoptovaný z config discovery se při dalším skenu agentem už nevrací do stavu pending (a adoptovaný neztratí vazbu na konfigurační soubor).
• Pravidla synchronizace: změny se validují a plán se dodržuje — Změna target_environment nebo sync_direction pravidla synchronizace (PUT /api/v1/projects/sync-rules/{ruleId}) nyní prochází kontrolami jako při vytvoření: pravidlo typu pull nebo obousměrné potřebuje cílové prostředí, rezervované nebo neplatné prostředí se odmítne s 400 a prostředí se uloží v kanonickém tvaru. Plánované synchronizace se řídí sync_schedule pravidla (výraz cron, např. */5 * * * * nebo @daily); dříve se každé povolené pravidlo spustilo, když se hodinu nesynchronizovalo, bez ohledu na plán. Pravidlo bez plánu nebo s neplatným výrazem cron (zalogováno jako varování) se dál synchronizuje každou hodinu.
• Verze konfiguračních souborů už v kopii s placeholdery nedrží extrahované hodnoty secretů — Při adopci objeveného konfiguračního souboru s extrakcí secretů se secrety uložily do trezoru, ale kopie verze s placeholdery (obsah s odkazy ${VAULT:…}) dál obsahovala jejich hodnoty v čitelné podobě (šifrované v klidu jako veškerý obsah verzí). Kopie s placeholdery nyní místo každé extrahované hodnoty obsahuje odkaz ${VAULT:<název>}. Jednou po upgradu, na pozadí po startu serveru, primár přepíše kopie s placeholdery u existujících verzí, které se stále shodují s původním obsahem (řádek logu config version placeholder copies regenerated; běh se zapíše do system_configurations jako config_version_placeholders_regenerated_at a neopakuje se). Kopie, která už placeholdery obsahuje, se nikdy znovu nesestavuje. Verze, jejíž secret už nejde přečíst nebo byl mezitím rotován, si kopii ponechá (zalogováno jako config version placeholder copy not regenerated). Původní obsah verzí se nemění.
• Registrace gateway zakládá E2EE session — POST /api/v1/gateways/register nově vrací i session_id a server_public_key (aditivně), pokud gateway poslala platný P-256 public_key: gateway z něj odvodí session klíč, vyžádá si mTLS certifikát a heartbeaty šifruje hned od prvního. Primární backend ukládá session klíč zašifrovaný klíčem MAZEVAULT_MASTER_KEY, takže šifrované heartbeaty jdou otevřít i po restartu backendu a na každé replice. Starší gateway nová pole ignorují. Gateway teď může mít více sessions (každá dostane další verzi klíče). Sessions se zatím neobnovují: 23 hodin po registraci gateway posílá heartbeat opět nešifrovaně, stále se svým API tokenem. POST /api/v1/gateways/csr nově podepíše jen CSR pro gateway dané session (CN gateway-<id>, volitelně DNS jméno gateway-<id>.mazevault.local, žádné jiné SAN) a jen dokud je gateway aktivní; jiné CSR odmítne s 403.
• Azure Key Vault: externí hodnoty, linky syncu přes gateway a key usage certifikátu — Čtení hodnoty, kterou MazeVault ukládá do Azure Key Vault (key offload), ji vrací přesně tak, jak je uložená; prostá hodnota, která byla náhodou platné base64 (např. password1234), se vracela dekódovaná. Secrety synchronizované z Key Vault přes gateway se nově propojí se svou integrací jako při přímém syncu, takže se zobrazují jako synchronizované z trezoru místo local_only. Žádost o certifikát v Key Vault provedená přímo na primary zachová key usage šablony (dřív se zahodila a trezor vydal výchozí key usage). Formát úlohy pro gateway se nemění.
• HSM zařízení: výchozí routing a operace s klíči v Azure Key Vault / SoftHSM — HSM zařízení vytvořené bez environments nebo applies_to nově obsluhuje všechna prostředí i rozsahy, jak je zdokumentováno (dřív se nikdy nevybralo a rotace hsm_generator končily chybou „no HSM device configured“); existující zařízení se opraví bez migrace. HSM zařízení v Azure Key Vault vytváří ECDSA klíče na křivce podle požadované velikosti (P-256, P-384 nebo P-521; jiná velikost je odmítnuta, dřív byl každý klíč P-256), vrací správně veřejný klíč i velikost RSA klíče a klíče vypsané zařízením jdou použít podle jména. Vestavěné softwarové HSM podepisuje RSA-PSS a obnoví RSA i EC klíče, které samo zabalilo.
• Krok rotace Kubernetes secretu míří na nastavený cluster — Když MazeVault běží v Kubernetes, krok rotace kubernetes_secret použil vlastní in-cluster přihlášení MazeVaultu, i když krok měl nastavený kubeconfig, a secret tak zapsal do clusteru MazeVaultu. Nastavený kubeconfig nyní vždy vyhrává; in-cluster přihlášení se použije jen bez něj. Zkontrolujte rotace s kubeconfig, které běžely na instalaci v clusteru: secret v cílovém clusteru se neaktualizoval.
• Vstupy rotace: rozšířená konfigurace Entra a delegated custody HSM — Entra credential, jehož rozšířená konfigurace rotace není platný JSON, už neshodí preflight rotace s HTTP 500: preflight hlásí invalid_extended_rotation_config (ruční kontrola) a credential se automaticky nerotuje, dokud se konfigurace neopraví. Krok hsm_generator v režimu delegated už nepředává navazujícím krokům prázdné heslo; krok databáze nebo secretu po něm nyní selže s new_password not found místo nastavení prázdného hesla.
• Chyby klienta vrací 4xx místo 500 — Chyby validace, neexistující zdroje a stavové chyby API už nekončí 500: neznámá role při přiřazení, slabé heslo, URL integrace odmítnutá ochranou proti SSRF, neplatné prostředí, EAB pověření bez projektu, CSR, které není PEM, neznámý typ reportu a poškozené JSON tělo vrací 400; neznámá id (archivované položky, gateway, loga organizací, Terraform export, tajemství, schémata poskytovatelů, šablona jiné organizace) vrací 404; schválení žádosti nebo obnovy, která už nečeká, kopie tajemství na existující klíč a aktivace DR při aktivní primární gateway vrací 409; neplatný bootstrap token agenta vrací 401. Odpověď nikdy neobsahuje text databáze ani názvy constraintů. Revokace cizího API tokenu vrací 404 místo 204 (nic se nezrušilo). Chybová těla těchto endpointů mají společný tvar {code, message, request_id}.
• Spuštění rotace keytabu a převod formátu fungují — POST /rotation/resources/keytab/{id}/trigger se dostane k executoru keytabů místo odpovědi 400. POST /format/convert převede veřejný certifikát a řetězec (vyžaduje certificate:read na certifikátu) místo vrácení zástupného textu.
• Přihlášení SRP už neprozrazuje, které účty existují — POST /auth/srp/init odpoví na neznámý e-mail nebo účet bez SRP stejně jako na skutečný účet (200 se stálým saltem); krok verify pak selže 401 jako u špatného hesla. Dříve vracel 404 nebo 400. /auth/srp/init a /auth/srp/verify mají stejný limit pokusů jako /login (při překročení 429).
• Délka hesla se počítá ve znacích; LDAP přihlášení najde účet bez ohledu na velikost písmen v e-mailu — Minimum 8 a maximum 128 znaků u lokálních hesel se počítá ve znacích, ne v bajtech: sedmiznakové heslo s diakritikou se odmítne a dlouhé heslo s diakritikou se přijme. LDAP přihlášení, kdy adresář vrací atribut mail s velkými písmeny (běžné u Active Directory), použije existující účet místo vytvoření druhého; nové LDAP účty se ukládají s e-mailem malými písmeny. Omezení regionů licence (allowed_regions) se nevynucuje, dokud není nastavena GeoIP databáze, místo aby se každá veřejná adresa brala jako neznámá země.
• Sdílené odkazy: vypršené odkazy se mažou, špatná hesla jsou omezena — Otevření sdíleného odkazu, který vypršel nebo vyčerpal zhlédnutí, ho nyní opravdu smaže (smazání se dřív vrátilo zpět a šifrovaná hodnota zůstala v databázi). Odkaz chráněný heslem se po 5 špatných heslech spálí; do té doby každé špatné heslo odpoví 403 jako dosud, potom odkaz odpoví 404 i na správné heslo. Počet se ukládá v novém sloupci shared_secrets.failed_attempts (migrace 000298).
• Hodnoty jen v externím úložišti selžou viditelně; extrakce z konfigurace zvládne opakované klíče — Čtení tajemství names_only (hodnota jen v externím poskytovateli), když ho nevyřeší key offload ani sync rule, a čtení tajemství bez lokální hodnoty v Orchestrator Mode bez sync rule služby nyní skončí chybou místo prázdné hodnoty. Extrakce tajemství z konfiguračního souboru, kde je stejný klíč dvakrát (např. password ve dvou INI sekcích), uloží obě hodnoty; druhá dostane placeholder …/password_2 místo přerušení extrakce.
• Historie hesel tajemství je solená a API ji už nevrací — Historie, která brání znovupoužití jedné z posledních 10 hodnot, ukládá každou hodnotu jako solený hash PBKDF2-SHA256 místo prostého SHA-256, takže stejné hodnoty nejde propojit napříč tajemstvími. Historie se nyní při každé změně hodnoty opravdu ukládá (dřív se neukládala vůbec, takže kontrola opakování nikdy nic neodmítla); změna tajemství na jednu z jeho posledních 10 hodnot se odmítne s 400 (PUT /api/v1/secrets/{id}, Terraform provider a další uživatelské zápisy). Opětovné odeslání aktuální hodnoty není znovupoužití: provede se jako změna jen metadat bez nové verze, takže změna metadat nebo ttl_hours z Terraformu funguje dál. Systémová obnovení a synchronizace se nikdy neodmítnou: kompenzace neúspěšné rotace, rollback ze zálohy rotace, sync pull, řešení konfliktu synchronizace, synchronizace mezi projekty a předrotační synchronizace s Key Vaultem. Stávající záznamy pro kontrolu opakování fungují dál, dokud je nenahradí novější hodnoty. Odpovědi s tajemstvím už neobsahují password_history_hashes.
• Licenční klient rozumí odpovědím licenčního serveru — Heartbeat, na který server odpoví odvolanou nebo vypršelou licencí (prosté 200 s LICENSE_REVOKED / LICENSE_EXPIRED), nyní označí licenci backendu REVOKED / EXPIRED místo ponechání ACTIVE a chyby dešifrování. Hodinové metriky využití se posílají s validačním požadavkem (POST /api/v1/validate) místo neexistující /api/v1/metrics, která pro každou organizaci vracela 404. Licenční server tyto metriky zatím nevyužívá a hodinové požadavky se počítají do jeho limitu validačních požadavků. Enrollment odmítnutý build autentizací nyní zaloguje cílenou radu (zkontrolovat BUILD_AUTH_SECRET, nebo systémové hodiny / NTP).
• Obnova neexistující položky z archivu selže; retence auditu umí mazat — Obnova projektu, tajemství nebo certifikátu, který neexistuje, nyní odpoví 404 a nezapíše auditní událost RESTORE_* (dřív odpověděla úspěchem a obnovu zaauditovala). Retenční čištění auditu nyní umí opravdu smazat události starší než doba uchování (nejméně 1 den): trigger neměnnosti se vypne jen uvnitř transakce čištění a neúspěšné čištění se zaloguje místo ignorování. Čištění zatím žádná úloha nespouští, auditní události se tedy dál uchovávají neomezeně.
• Výchozí organizace je ta první vytvořená — Funkce, které používají výchozí organizaci (a incidenty rotačních zdrojů bez projektu, např. systémových klíčů platformy, včetně incidentů pokračování po schválení), nyní použijí organizaci vytvořenou jako první. Dřív to byla organizace řazená první podle náhodného ID, takže na instanci s více organizacemi mohl incident selhání rotace platformního klíče i jeho notifikace dostat jiný tenant. Servisní identita bez jediného projektu nyní dostává incidenty ve své organizaci. Po upgradu zkontrolujte (instance s více organizacemi): trasy bez projektu posuzují role na úrovni organizace ve výchozí organizaci, což teď může být jiná organizace než dřív; ověřte, kteří administrátoři v ní mají role. Bootstrap tokeny agentů (POST /agents/bootstrap) nyní vytvoří nasazení v organizaci, ve které se ověřovalo oprávnění agent:admin; pro globálního administrátora bez kontextu organizace je to výchozí organizace a požadavek odpoví 400 jen tehdy, když žádná organizace neexistuje. Serverový příkaz agent-bootstrap má volitelný parametr --organization-id; bez něj jde token do výchozí organizace, kterou příkaz vypíše na stderr a discovery agenta vrací šablonu agent-mtls organizace agenta.
• Integrace přes agenta jde uložit (po upgradu zkontrolujte log migrace) — Uložení integrace, která běží přes agenta, selhávalo, protože project_integrations.agent_id odkazoval na uživatele místo na agenty. Migrace 000272 odkaz přesměruje na agenty. Každé existující agent_id, které neodpovídá žádnému agentovi (mohlo obsahovat jen id uživatele), se nastaví na NULL, takže integrace nemá vázaného agenta, dokud ho nenastavíte, a každý takový řádek se zapíše jako NOTICE do logu migrace. Po upgradu v logu migrace tato upozornění zkontrolujte a uvedené integrace znovu navažte na jejich agenty.
• Microsoft Graph: chybný client secret se někdy zkoušel znovu — Vrstva opakování klienta Entra ID (Microsoft Graph) hledala HTTP status kdekoli v textu chyby, takže náhodné trace nebo correlation ID obsahující např. a503 udělalo z odpovědi invalid_client (chybný secret) opakovatelnou chybu a žádost o token se poslala znovu. Číslo statusu se nyní rozpozná jen jako samostatné slovo; chybný secret selže po jedné žádosti o token.
• Terraform: mazevault_shared_secret sdílí secret podle ID; CreateSharedSecret v Go SDK vyžaduje Value — Vytvoření zdroje vždy končilo 400, protože backend ke sdílení potřebuje hodnotu. Provider nyní při vytvoření sdílení načte hodnotu secretu z secret_id a odešle ji; hodnota se nikdy neukládá do Terraform state a share_url zůstává citlivý. Secret, jehož hodnotu server nepřečte (zero-knowledge, pouze názvy, externí), skončí srozumitelnou chybou místo prázdného sdílení. V Go SDK vrací CreateSharedSecret chybu ještě před odesláním požadavku, když je Value prázdná; SecretID zůstává zastaralé a hodnotu předává volající.

Bezpečnostní a závislostní aktualizace

• API tokeny smazaného uživatele přestanou fungovat — Smazání uživatele (přesune ho do Archivu) nyní vypne jeho API tokeny (mvt_…) a token archivovaného uživatele je odmítnut, i když je stále označený jako aktivní. Dříve takový token dál ověřoval se všemi rolemi, které uživatel měl při smazání, dokud nevypršel. Obnova uživatele z Archivu tokeny znovu nezapne; uživatel si vytvoří nové. Tokeny uživatelů archivovaných před touto verzí jsou odmítnuty také, bez jakékoli akce.
• Kroky rotace a synchronizace zůstávají v projektu rotovaného prostředku — Před během každého kroku rotace a akce po rotaci (i při obnovení rotace, delegaci na gateway a doručení po rotaci Entra) MazeVault ověří, že každá uvedená integrace patří projektu rotovaného secretu, certifikátu nebo aplikace Entra, že agent_id je agent jeho organizace a target_project_id projekt jeho organizace a že secret (secret_id, password_secret_id), certifikát (certificate_id) nebo credential Entra (credential_id, podle projektu jeho aplikace), který krok čte nebo zapisuje, patří do stejného projektu a org_id je jeho organizace; jinak krok neběží a rotace selže (akce po rotaci se zapíše jako selhaná). Pravidlo synchronizace s integrací jiného projektu nyní selže místo běhu, preflight rotace hlásí integraci jiného projektu jako chybějící a propojení secretu na integraci jiného projektu se do generovaného workflow rotace nedostane. Integrace, agent_id a target_project_id mimo rozsah API při uložení odmítalo už dříve; secret_id, password_secret_id, certificate_id, credential_id a org_id se při uložení neověřují a odmítnou se až při běhu kroku. Tohle pokrývá ručně psaná workflow a konfigurace uložené staršími verzemi. Certifikáty bez projektu a doručení Entra spuštěná před upgradem se nezužují. Cíle nasazení managed tokenů stejně tak přijmou jen integraci, agenta nebo target_project_id organizace tokenu (jinak POST /api/v1/tokens/{id}/targets vrátí 400) a existující cíl mimo ni při příští synchronizaci selže, místo aby token dostal.
• Auditní log a archiv zůstávají v organizaci — GET /api/v1/audit-logs/ a POST /api/v1/audit-logs/search (i agregace) nyní vracejí jen události projektů a organizací, ve kterých má volající audit:read; dříve viděl každý držitel audit:read události všech organizací. Auditní události mají organizaci (migrace 000237: sloupec audit_events.organization_id, plní se při zápisu z projektu události nebo z prostředku, který jmenuje; existující události doplněny); události bez organizace (přihlášení, uživatelské účty, systémové klíče) vidí jen globální role. Archiv (/api/v1/archived/*, stránka Archivované položky) stejně vypisuje jen projekty, secrety, certifikáty, objevené certifikáty a žádosti o certifikát volajícího; smazaní uživatelé nemají organizaci a vidí je jen globální role. Obnovení nebo trvalé smazání archivované položky (/projects|secrets|certificates/{id}/restore|permanent, /archived/…/{id}/restore|permanent) se nyní posuzuje v organizaci položky (403 pro položku cizí organizace, 404 pro neznámé id); smazané uživatele obnoví nebo smaže jen globální role. Log streamy (Splunk, Elasticsearch, Syslog) nyní dostávají jen události organizace, která je nastavila; dříve dostával stream každé organizace auditní události všech organizací.
• Log streamy: bezpečnostní události bez organizace dostanou organizace jejich uživatele (BREAKING pro instalace s více organizacemi) — Události, které nepatří žádné organizaci (přihlášení, MFA, změny hesla a uživatelů, přidělení rolí, break-glass a dočasný přístup), se posílají do log streamů každé organizace, ve které má uživatel, o kterém událost je, neexpirovanou roli na organizaci nebo na některém jejím projektu. Je to subjekt, kterého událost jmenuje (přihlášený uživatel, uživatel, jehož MFA, heslo, role nebo přístup se změnil, cíl break-glass), nikdy uživatel, který akci provedl; uživatel s rolemi ve dvou organizacích se tak objeví ve Splunku, Elasticsearch nebo Syslogu obou. S právě jednou organizací dostávají všechny log streamy dál všechny takové události. S více organizacemi se událost, jejímž subjektem není uživatel s rolí v organizaci (neúspěšné přihlášení neznámým jménem, změny uživatelů jen s globálními rolemi, odebrání přidělení role, vytvoření a zneplatnění API tokenu, nastavení instance, plánované systémové úlohy), neposílá nikam; pokud na nich stojí vaše SOC detekce, čtěte je v auditním logu (/api/v1/audit-logs, globální role).
• Registrace agenta potřebuje interní CA organizace nebo CA instance (BREAKING) — mTLS certifikáty agentů už nepodepisuje interní CA jiné organizace: registrace agenta selže, dokud organizace neinicializuje svou interní CA (Nastavení organizace → Nastavení projektu → Certifikační autority → Inicializovat interní CA) nebo globální administrátor nevytvoří CA instance (POST /api/v1/ca/initialize). Zkontrolujte před upgradem, pokud se agenti registrují v organizaci bez vlastní interní CA (viz Certifikační autority, CA účty a šablony zůstávají v organizaci).
• POST /api/v1/ca/initialize vyžaduje globální roli (BREAKING) — Vytvoření CA instance nově vyžaduje globální roli; organizační role dostane 403. Automatizace, která ji vytváří tokenem s organizační rolí, musí použít globální.
• Příjemci týdenního reportu se nastavují po organizacích (BREAKING, po upgradu zkontrolujte) — Každá organizace má nyní vlastní e-mailové příjemce týdenního reportu a ti dostávají jen report své organizace. Administrátor organizace (report:read/report:write v organizaci) je čte a mění přes GET/PUT /api/v1/organizations/{id}/reports/settings, report organizace odešle přes POST /api/v1/organizations/{id}/reports/trigger a zobrazí jeho náhled přes GET /api/v1/organizations/{id}/reports/preview; globální administrátor to může pro kteroukoli organizaci, projektová role dostane 403. Změna se zapisuje do auditu (REPORT_RECIPIENTS_UPDATED). System Outputs → Weekly Expiry Report upravuje příjemce vybrané organizace. Pondělní běh pošle každé organizaci její vlastní report a kanály s povoleným reportem ho nově dostanou i tehdy, když organizace nemá e-mailové příjemce. Upgrade: na instanci s jednou organizací se dosavadní příjemci přesunou k ní automaticky. Při více organizacích zůstanou jako příjemci na úrovni instance, kteří nedostávají nic (nepůjde jim report žádné organizace), dokud je globální administrátor nepřidá ke správným organizacím; záložka Weekly Expiry Report je globálnímu administrátorovi vypíše a umí je smazat. GET/PUT /api/v1/reports/settings (globální role) nyní čtou a mění jen tento zbylý seznam a POST /api/v1/reports/trigger (globální role) pošle každé organizaci její vlastní report. Expirující certifikáty bez projektu, které instanční e-mail uváděl jako nepřiřazené, nyní nejsou v reportu žádné organizace: přiřaďte je do projektu.
• Orchestrator Mode: offload klíče bez projektu se odmítne (BREAKING) — Import nebo discovery privátního klíče certifikátu bez projektu a export, smazání nebo znovupoužití takového klíče při obnově nově selže, dokud certifikát nepřiřadíte do projektu (viz Offloadované klíče zůstávají v organizaci a trezoru volajícího).
• Projektové role, incidenty, Terraform export organizace a žádosti agentů o hesla zůstávají v organizaci — Projektová role (tak, jak ji přiděluje záložka Správa přístupu projektu) už na trasách bez projektu (výpisy, stažení a změny managed tokenů a keytabů, šablony certifikátů, schvalování CSR, fronta obnov a výpis incidentů, zakládání service identit) nejedná s právy výchozí organizace instance, pokud její projekt patří jiné organizaci; takový volající tam dostane 403 a tam, kde trasa bere project_id, pošle project_id svého projektu. Trasy, které berou projekt jen z těla požadavku (POST /api/v1/secrets/, POST /api/v2/secrets, POST /api/v2/secrets/compare a /migrate, POST /api/v1/certificates/csr, POST /api/v1/certificates/import, /import/bulk, /import/file a náhledy importu), se posuzují v projektu z těla (u /migrate v projektu každého secretu), takže je projektové role všech organizací používají dál a nově i organizační role jiné než výchozí organizace, které tam dřív dostaly 403; import bez projektu se dál posuzuje ve výchozí organizaci. GET /api/v1/incidents/{id} a POST /api/v1/incidents/{id}/resolve se posuzují v projektu nebo organizaci incidentu: incident jiné organizace vrátí 403, neznámé id 404. GET /api/v1/terraform/export/organization/{id} vyžaduje org:read v dané organizaci (jinak 403, neplatné id 400). /api/v1/admin/password-requests vypíše jen žádosti agentů organizací, ve kterých má volající agent:admin (projektová role nevidí žádné, agent bez organizace vyžaduje globální roli), a /approve a /reject žádosti jiné organizace vrátí 403 (neznámé id 404) a nic nezmění.
• Projektové role jednají jen ve svém projektu na trasách keytabů, tokenů, CSR, fronty obnov a incidentů (BREAKING pro volající API s projektovými rolemi) — Projektová role nově jedná jen nad záznamy svého projektu i v organizaci, do které její projekt patří; dřív měla na trasách bez projektu práva celé této organizace. GET /api/v1/keytabs, GET /api/v1/tokens, GET /api/v1/renewal-queue/ a GET /api/v1/incidents/ vypisují jen záznamy projektů a organizací, ve kterých má volající oprávnění ke čtení (projektová role: záznamy svého projektu, žádné organizační; organizační a globální role vidí to, co dřív). /api/v1/keytabs/{id} (čtení, úprava, smazání, download, history, check-compliance), /api/v1/tokens/{id} (čtení, úprava, smazání, value, renew, targets) a POST /api/v1/certificates/csr/{id}/approve, /reject a /archive se posuzují v projektu záznamu, bez projektu v jeho organizaci: záznam jiného projektu nebo organizační záznam odpoví 403 a nic se nezmění, neznámé id 404. POST /api/v1/keytabs a POST /api/v1/tokens s project_id potřebují oprávnění v tomto projektu a projekt musí patřit organizaci, do které se záznam ukládá; bez project_id potřebují oprávnění na úrovni organizace. GET /api/v1/keytabs/dashboard bez project_id, POST /api/v1/service-identities/ a POST /api/v1/certificate-templates/ potřebují oprávnění na úrovni organizace. Volající API a SDK jen s projektovou rolí dostanou u těchto vytvoření bez project_id 403 a vidí jen keytaby, tokeny, položky fronty obnov a incidenty svého projektu; stránky KeyTab Management a Token Management takovému uživateli ukážou jen záznamy jeho projektu a import keytabu nebo vytvoření tokenu tam (formuláře projekt neposílají) vyžaduje organizační roli.
• Upgrade: u velkých auditních logů naplánujte servisní okno — Migrace 000237 doplní audit_events.organization_id všem existujícím událostem a po dobu běhu drží zámek ACCESS EXCLUSIVE na audit_events. U velkých auditních tabulek to trvá minuty a zápisy auditu (i požadavky API, které audit zapisují) mezitím čekají a blokované je i čtení auditního logu; backend nedokončí start, dokud migrace neskončí, proto odpovídajícím způsobem zvyšte timeouty startovací a liveness sondy. Aktualizace přepíše každý přiřaditelný řádek, tabulka proto dočasně potřebuje volné místo na disku až zhruba ve své velikosti. Upgrade naplánujte do servisního okna.
• Gateway pracuje jen se svými úlohami — Endpointy úloh gateway (GET /api/v1/gateway/tasks, GET /api/v1/gateways/{id}/tasks, POST /api/v1/gateway/tasks/{id}/claim, PATCH /api/v1/gateway/tasks/{id}) nově jednají jen za gateway ověřenou hlavičkou X-Gateway-ID a jejím tokenem. gateway_id v query, cestě nebo těle, který jmenuje jinou gateway, dostane 403 a změna stavu úlohy jiné gateway 404; dříve gateway se svým platným tokenem vypsala (s dešifrovaným payloadem), převzala a dokončila úlohy všech ostatních gatewayí. Nasazené gatewaye už posílají své id na obou místech a fungují dál; gateway_id u GET /api/v1/gateway/tasks je nově nepovinný.
• Příkazy IIS a post-install už nejde podvrhnout (agent a backend) — Vestavěná položka allowlistu post-install příkazů agenta Import-Module WebAdministration nově odpovídá jen přesně tomuto příkazu; dříve se na hostiteli agenta provedlo cokoli připojeného za ni (; …, &&, |). Agent navíc odmítne každý post-install příkaz se zalomením řádku (u vestavěných vzorů i vzorů z allowed_commands), protože shell spouští každý řádek jako samostatný příkaz, a na Windows agentech každý post-install příkaz se znaky (, ), {, }, @, $, zpětným apostrofem nebo jakýmkoli ne-ASCII znakem, protože PowerShell takové výrazy v argumentech vyhodnotí dřív, než program spustí, a Unicode mezery, typografické uvozovky a pomlčky bere jako jejich ASCII protějšky (strukturované požadavky agent_command běží bez shellu a změna se jich netýká). Na Windows agent při obnově certifikátu z Windows store a při kontrole trust store předává jméno store, otisk a jméno CA certifikátu do PowerShellu jako proměnné prostředí, takže podvržené jméno store nebo CA certifikátu už nespustí kód. Agent předává jméno aplikačního poolu, webu a hostname IIS do PowerShellu jako proměnné prostředí místo vkládání do textu skriptu a úspěšný post-install příkaz loguje jen názvem programu (hesla walletu a keystoru se už do logu agenta nedostanou). Krok rotace IIS recycle na backendu přijme jen jméno poolu z písmen, číslic, mezer a . _ - ( ), takže chrání i agenty starších verzí. Vyžaduje akci: post-install příkaz ve tvaru Import-Module WebAdministration; Restart-WebAppPool … je nově odmítnut — použijte samotné Restart-WebAppPool -Name "<pool>" (PowerShell modul načte sám; vestavěný vzor pokrývá jména poolů z písmen, číslic, _, - a .), jinak — např. pro .NET v4.5 Classic — přidejte odpovídající vzor do allowed_commands agenta; víceřádkový post-install příkaz je třeba zapsat na jeden řádek; krok IIS recycle se jménem poolu s jinými znaky neprojde validací a je třeba ho opravit. Agenti a backend předchozí verze zůstávají kompatibilní.
• Konektory ve výchozím stavu ověřují TLS (BREAKING, zkontrolujte před upgradem) — Účty CA ADCS nově ověřují certifikát serveru, pokud nebyl uložen s vypnutým Verify SSL (verify_ssl: "false"); dříve každé spojení s ADCS, které nese heslo servisního účtu, u účtů vytvořených v UI ověření vynechalo, i se zapnutým přepínačem. Krok rotace PostgreSQL (postgres_db) bez ssl_mode se nově připojuje se sslmode=verify-full místo disable a čte i sslmode, jak ho ukládá průvodce integrací. Audit streamy (syslog přes TLS, Elasticsearch) nově důvěřují PEM CA v tls_ca_cert, takže privátní CA už nepotřebuje tls_skip_verify. Účty CA Smallstep s Root CA Fingerprint a bez trust bundlu nově důvěřují vlastnímu rootu step-ca: MazeVault jednou stáhne /roots a ponechá jen root s tímto otiskem SHA-256 (jako step ca bootstrap), takže insecure_skip_tls už není potřeba. Servery ADCS a cílové databáze PostgreSQL pro rotaci, jejichž certifikátu backend nedůvěřuje, se přestanou připojovat s chybou x509:: přidejte CA do úložiště důvěry backendu (viz Konfigurace TLS, oddíl 8) nebo ověření explicitně vypněte. Přestanou se připojovat i účty CA Smallstep s Root CA Fingerprint a bez CA Trust Bundle, jejichž step-ca stojí za proxy ukončující TLS s veřejným certifikátem (certifikát proxy nevede k připnutému rootu): nechte TLS projít až na step-ca (passthrough), nebo vložte CA proxy do CA Trust Bundle.
• Tajné hodnoty se už neukládají do rotačních workflow, historie kroků ani notifikací — Výchozí tělo rotačního kroku api_notification (i jako post-rotation akce Entra) už neobsahuje tajné hodnoty: kontext kroku se maskuje stejně jako u kroku webhook, nový client secret ani heslo se tak na nastavenou URL neodešle. Generované kroky rotace databáze už neukládají administrátorské jméno a heslo integrace do rotační konfigurace ani do historie kroků; orchestrátor je načte z databázové integrace až při běhu kroku. Migrace 000221 odstraní uložené kopie z existujících rotačních konfigurací a z historie exekucí všude, kde je odkazovaná databázová integrace stále drží (krok se smazanou integrací hodnoty ponechá; migrace jejich počet zapíše jako WARNING do logu serveru PostgreSQL a řádky, které stále drží přihlašovací údaje v otevřeném textu, vypíše SELECT 'rotation_configs' AS source, id::text FROM rotation_configs WHERE workflow_steps::text LIKE '%"admin_password"%' UNION ALL SELECT 'rotation_execution_steps', id::text FROM rotation_execution_steps WHERE step_config::text LIKE '%"admin_password"%';). Předchozí hodnoty Azure Key Vault zachycené krokem post_rotation_sync se už neukládají do výstupu kroku a průběžné checkpointy úloh gateway u delegovaných rotací se ukládají šifrovaně stejně jako konečný výsledek (checkpointy zapsané předchozí verzí se dál čtou). Downgrade odstraněné přihlašovací údaje neobnoví; čekající databázový krok rotace přerušené přes downgrade je nutné spustit znovu jako novou rotaci.
• Odhlášení a změna hesla odvolají obnovovací tokeny — POST /api/v1/auth/logout nově na serveru odvolá obnovovací token z cookie refresh_token (a zapíše auditní událost LOGOUT), takže zkopírovaný obnovovací token po odhlášení přestane fungovat. Změna hesla odvolá všechny obnovovací tokeny uživatele; sezení prohlížeče, které heslo změnilo, dostane novou cookie refresh_token (volající s API tokenem ne), ostatní prohlížeče a zkopírované tokeny se musí přihlásit znovu. Obnovovací token už API nepřijme jako přístupový token v hlavičce Bearer (dosud to šlo 7 dní, i po odhlášení); obnovovací tokeny nově nesou typ: refresh a jedinečný jti a API odmítne každý JWT bez claimu role. Už vydané přístupové tokeny platí do své expirace (výchozí 15 minut).
• Integrace organizace odmítají interní cíle (SSRF) — Vytvoření, úprava a test integrace Jira, Teams, Slack nebo webhook nově přeloží hostitele z URL a je odmítnuto, pokud je kterákoli jeho adresa interní: loopback (vč. ::1 a ::ffff:127.0.0.1), 0.0.0.0/::, privátní sítě (10/8, 172.16/12, 192.168/16, IPv6 fc00::/7), link-local (vč. adresy cloudových metadat 169.254.169.254), carrier-grade NAT 100.64.0.0/10 a multicast. Dříve se odmítaly jen některé IPv4 prefixy a localhost. Instalace on-premises, jejichž cíl Jira nebo webhooku se přeloží na privátní adresu, už takovou integraci neuloží ani neotestují; dříve uložené integrace odesílají dál, dokud se neupraví. Notifikace Jira, Teams, Slack a webhook už nesledují HTTP přesměrování: cíl, který odpoví 3xx, se hlásí jako neúspěšné doručení, nastavte proto konečnou URL.
• ACME server váže každý požadavek na podepisující účet (RFC 8555) — Vestavěný ACME server (/api/acme/*) nově vydá objednávku, autorizaci, výzvu, finalizaci i stažení certifikátu jen účtu, který objednávku vytvořil; jiný účet dostane 404 (dosud mohl kterýkoli registrovaný účet číst cizí objednávky a finalizovat je vlastním CSR). kid je URL účtu z hlavičky Location odpovědi new-account, jak RFC 8555 vyžaduje, takže standardní klienti (cert-manager, certbot, acme.sh, lego) po registraci fungují. Hlavička JWS url je nově povinná v každém požadavku včetně revoke-cert a key-change a musí se rovnat URL z adresáře, který se skládá z MAZEVAULT_BASE_URL (nastavte ji na externí URL, přes kterou ACME klienti MazeVault volají, jinak požadavky skončí 400 malformed). EAB musí být spočítané nad klíčem účtu z požadavku new-account a nést URL new-account; výměna klíče kontroluje, že vnitřní JWS má url vnějšího a jmenuje podepisující účet; odvolání klíčem certifikátu (bez účtu) vyžaduje podpis právě klíčem toho certifikátu a odvolání v obou režimech vyžaduje, aby odeslaný certifikát byl bajtově shodný s vydaným (padělaný certifikát se stejným sériovým číslem dostane 404). Hlavička alg musí odpovídat klíči účtu (ES256 P-256, ES384 P-384, RS256 RSA), JWS s jwk i kid zároveň skončí 400 malformed a nepodporovaný kód důvodu odvolání 400 badRevocationReason místo odvolání s důvodem unspecified. Klíče účtu ES384 (P-384) jsou přijaty a ověřují se s SHA-384 a deaktivovaný účet dostane 401 unauthorized místo 404 accountDoesNotExist.
• Entra ID SSO: nonce vždy vynucený, žádné propojování podle e-mailu (vyžaduje akci) — Přihlášení přes Entra ID nyní vždy odmítne ID token, jehož nonce neodpovídá hodnotě vydané pro toto přihlášení (ochrana proti přehrání tokenu podle OIDC); proměnná MAZEVAULT_ENFORCE_OIDC_NONCE je odstraněná a ignoruje se, smažte ji z .env / hodnot Helmu (check-config.sh na ni upozorní). Přihlášení přes Entra se také už nepřipojí k existujícímu účtu MazeVault jen proto, že se shoduje claim email nebo preferred_username: Microsoft je uvádí jako proměnlivé a neověřené, takže kdokoli, kdo si takovou adresu nastaví, by mohl účet převzít, včetně lokálního administrátora. Účet se páruje jen podle neměnného ID objektu Entra (oid) nakonfigurovaného tenantu: účty, které se už dříve přihlásily přes Entra SSO, fungují beze změny. Uživatel, jehož účet MazeVault (se stejným e-mailem v jakékoli velikosti písmen, i archivovaný) se přes Entra SSO ještě nikdy nepřihlásil, nyní místo přihlášení dostane chybu; e-maily nových účtů z Entra se ukládají malými písmeny. Jednorázové propojení: (1) administrátor tento účet MazeVault smaže (Řízení přístupu → Uživatelé), (2) trvale ho smaže v Archivu (DELETE /api/v1/archived/users/{id}/permanent, oprávnění archive:permanent_delete; smaže API tokeny a záznamy MFA uživatele, účet anonymizuje a zapíše auditní záznam), (3) uživatel se přihlásí přes Entra ID, čímž vznikne nový účet svázaný s jeho ID objektu s rolemi podle mapování skupin Entra. Samotné přihlášení archivovaný účet nikdy nesmaže. Role přidělené starému účtu lokálně a jeho osobní data se nepřenášejí, přidělte je znovu. Lokálního nouzového (break-glass) administrátora ponechte na e-mailové adrese, která se v Entra nepoužívá.
• Kroky rotace databází: náhodná hesla Oracle a žádná SQL injection (u Oracle vyžaduje akci) — Krok rotace Oracle bez new_password ve vstupu (jednoduchá rotace i sqluser:<role>:<user>) dosud nastavil všem účtům stejné pevné, veřejně známé heslo; nově vygeneruje náhodné heslo o 30 znacích (crypto/rand, aspoň dvě velká a dvě malá písmena, dvě číslice a dva speciální znaky ^_~, takže projde i ora12c_strong_verify_function). Takové účty rotujte znovu: jde o účty rotované krokem databáze Oracle, jehož workflow nepředal new_password (např. vlastní workflow bez kroku generátoru hesla); najdete je v historii rotací, nebo jednoduše rotujte všechny účty Oracle spravované MazeVaultem. Kroky ensure pro MSSQL a Oracle a reconcilery MSSQL, MySQL a Oracle odmítnou oprávnění grantu, které není oprávněním SQL Serveru (whitelist) nebo klíčovým slovem oprávnění Oracle/MySQL, ještě před odesláním SQL; kroky Oracle odmítnou neplatné jméno uživatele, role nebo člena místo vytvoření prázdného identifikátoru. Ukončení session přijme jen číslo session (MSSQL, MySQL) nebo sid,serial# (Oracle) a název PDB u Oracle musí být prostý identifikátor. Reconciler MySQL escapuje hesla, jména uživatelů, rolí a grantee a kvotuje názvy schémat a objektů; reconciler Oracle přijme heslo obsahující -- nebo /* a odmítne heslo s uvozovkou. Krok generic SQL u PostgreSQL už nezdvojuje zpětná lomítka (jen pokud server běží se standard_conforming_strings=off), takže heslo se \ po rotaci funguje (účet PostgreSQL, který tento krok dříve rotoval na heslo se \, možné jen s vlastní politikou hesel, má v databázi zdvojenou podobu a je třeba ho rotovat znovu); když nastavení nejde přečíst, krok skončí chybou, a odmítne jméno uživatele s bílými znaky, uvozovkami, hranatými závorkami, zpětným lomítkem nebo #. Reconciler MySQL skládá connection string přes ovladač, takže název databáze, jméno uživatele ani heslo s ?, &, @ nebo / už nepřidá parametry ovladače jako allowAllFiles.
• Discovery agenta vyžaduje klientský certifikát agenta — POST /agent/discover dosud přijal kteréhokoli přihlášeného uživatele nebo token a vydal čerstvý JWT agenta registrovaného pro zadaný hostname (případně založil nového aktivního agenta). Nyní přijme jen zaregistrovaného aktivního agenta identifikovaného jeho mTLS klientským certifikátem (stejně jako POST /api/v1/agents/me/refresh-token): agent může změnit jen svůj vlastní název, OS a verzi, jiný hostname odmítne s 403, volání bez platného certifikátu agenta dostane 401 a endpoint už agenty nezakládá (odpověď 201 zmizela) — noví agenti se registrují přes POST /api/v1/agents/register. Agenti MazeVault tento endpoint nikdy nevolali, nasazených agentů se změna netýká.
• Heartbeat gatewaye mění identitu gatewaye jen s jejím tokenem — POST /api/v1/gateways/{id}/heartbeat dosud přebíral roli, prostředí, verzi softwaru, client ID managed identity a podporovaná prostředí od kohokoli, kdo znal ID gatewaye; podle těchto polí se řídí směrování úloh a failover. Nově se použijí jen tehdy, když heartbeat nese přihlašovací údaje gatewaye z registrace (X-Gateway-ID + Authorization: Bearer <token> nebo X-Gateway-Token). Heartbeat bez nich se dál přijímá a udržuje gateway naživu (last_heartbeat), takže gatewaye předchozí verze fungují dál, jejich identitní pole se ale ignorují, zalogují a započítají do mazevault_gateway_heartbeat_identity_ignored_total. Gatewaye této verze token posílají a heartbeat odeslaný jako E2EE obálka se nyní dešifruje session klíčem gatewaye (jeho identitní pole se dříve nikdy nepoužila). Aktualizujte gatewaye: gateway na předchozí verzi už heartbeatem nezmění svou roli ani prostředí.
• Nastavení organizace, dokončení úvodního nastavení a stav systému vyžadují oprávnění — GET /api/v1/organization/summary vyžaduje org:read; kontakty pro incidenty se řídí stránkou System Outputs: GET /api/v1/organization/incident-contacts vyžaduje system_output:read a PUT vyžaduje system_output:write (dříve mohl kterýkoli přihlášený uživatel přepsat, kam chodí upozornění na incidenty). Endpointy pracují s organizací volajícího, změna kontaktů se zapisuje do auditu (UPDATE_INCIDENT_CONTACTS) a bez system_output:write stránka kontakty jen zobrazí. GET /api/v1/organization/settings zůstává čitelný pro každého člena. Dokončení úvodního nastavení je nově POST /api/v1/bootstrap/complete a vyžaduje system:admin; projeví se jen jednou, další volání nic nemění a GET vrací 405. GET /api/v1/health/system (verze komponent, pool spojení, stav licence) vyžaduje přihlášeného uživatele s system:read; sondy liveness a readiness dál používají veřejný /api/v1/health. Panel Platform health na dashboardu vidí jen uživatelé se system:read; ostatním postranní panel ukazuje provozní stav jako nedostupný.
• MFA kódy a přihlašovací výzvy jsou jednorázové; vypnutí MFA vyžaduje opětovné ověření — TOTP kód projde nejvýš jednou (RFC 6238 §5.2; poslední použitý časový krok se ukládá u uživatele, migrace 000224) a MFA výzva při přihlášení (session_token z POST /auth/mfa/verify) vydá tokeny jen jednou. DELETE /api/v1/auth/mfa nově vyžaduje JSON tělo s heslem účtu (password) nebo aktuálním TOTP či záložním kódem (code) (400 bez obojího, 401 při neshodě), takže samotný přístupový ani API token už MFA nevypne. API klienti, kteří tento endpoint volají, musí tělo posílat. POST /auth/mfa/enroll a POST /auth/mfa/verify-enrollment vrací 409, dokud je MFA zapnuté, takže druhý faktor jde vyměnit jen po vypnutí s opětovným ověřením.
• Anonymní POST /api/v1/enroll odstraněn — Backend na neautentizovaný POST /api/v1/enroll pro libovolné ID zákazníka založil POC licenci, serverový uzel a OAuth klienta se scopes agent:read, agent:write, certificate:read a certificate:request a volajícímu vrátil secret klienta. V MazeVaultu tento endpoint nic nepoužívalo: backend získává licenci z licenčního serveru a agenti se registrují bootstrap tokenem (mazevault-agent enroll). Endpoint už neexistuje; volání je nyní odmítnuto. OAuth klienti, kteří přes něj už vznikli, se při upgradu automaticky deaktivují (migrace 000225; nic jiného OAuth klienty nikdy nezakládalo) a token vydaný deaktivovanému OAuth klientovi je nově odmítnut hned, ne až po vypršení.
• Bezpečnostní hlavičky webového rozhraní (nálezy OWASP ZAP) — Každá odpověď webového rozhraní nově obsahuje Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy a Cross-Origin-Resource-Policy a statické soubory nově dostávají i X-Content-Type-Options: nosniff (nginx ho u nich zahazoval). Statické soubory už neposílají Access-Control-Allow-Origin: *. Content Security Policy a Cross-Origin-Embedder-Policy: require-corp jsou zatím v režimu hlášení; vynucení přijde, až nebudou hlášena žádná porušení. Chybějící soubory jako favicon.ico nebo sitemap.xml vracejí 404 místo stránky aplikace a robots.txt zakazuje indexaci. Zastaralá hlavička X-XSS-Protection byla odstraněna. Hlavičky jsou definované na jednom místě ve frontend image a používá je Docker Compose kit i Helm chart.
• Bezpečnostní hlavičky webového rozhraní (nálezy OWASP ZAP) — Každá odpověď webového rozhraní nově obsahuje Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy a Cross-Origin-Resource-Policy a statické soubory nově dostávají i X-Content-Type-Options: nosniff (nginx ho u nich zahazoval). Statické soubory už neposílají Access-Control-Allow-Origin: *. Content Security Policy omezená na vlastní origin a Cross-Origin-Embedder-Policy: require-corp se vynucují. Odpovědi API mají Cross-Origin-Resource-Policy: same-site a chybové stránky nginx už neukazují jeho verzi. Chybějící soubory jako favicon.ico nebo sitemap.xml vracejí 404 místo stránky aplikace a robots.txt zakazuje indexaci. Zastaralá hlavička X-XSS-Protection byla odstraněna. Hlavičky jsou definované na jednom místě ve frontend image a používá je Docker Compose kit i Helm chart.
• Odstraněny tranzitivní CVE v Go (x/net, x/mod) — golang.org/x/net byl povýšen 0.55.0 → 0.56.0 a golang.org/x/mod 0.37.0 → 0.40.0 napříč moduly agent, cli, k8s-operator a terraform-provider-mazevault kvůli vyřešení CVE-2026-46600, CVE-2026-56864 a CVE-2026-56865.
• Aktualizace závislostí napříč moduly — Byly aktualizovány další modulové závislosti: golang.org/x/crypto → 0.55.0 a golang.org/x/sys → 0.47.0 v ocsp-responder, cloud.google.com/go a související balíčky v backend a google.golang.org/grpc, google.golang.org/genproto a balíčky OpenTelemetry v terraform-provider-mazevault.
• Odstraněn gRPC DoS (CVE-2026-84445) — google.golang.org/grpc byl povýšen 1.83.1 → 1.83.2 v backend a terraform-provider-mazevault kvůli vyřešení CVE-2026-84445 (odepření služby v gRPC-Go přes chybně formovaný RPC požadavek), na kterém padal Trivy filesystem sken dev-pipeline. Oprava je fixována na patch řadu 1.83.2 (řada 1.84.0 je stále zasažena). Transitivní golang.org/x/mod → 0.40.0 (CVE-2026-56864 / CVE-2026-56865), který následná aktualizace nástrojů stáhla zpět na 0.39.0, byl znovu aplikován. Ověřeno go build, go vet, govulncheck (0 dosažitelných) a čistým Trivy skenem CRITICAL,HIGH --ignore-unfixed.
• Odstraněn Jackson Core/Databind DoS (CVE-2026-68497, CVE-2026-89407, CVE-2026-89425, CVE-2026-91776, CVE-2026-91777) — com.fasterxml.jackson.core:jackson-databind byl v Java SDK (sdks/java/pom.xml) povýšen 2.18.8 → 2.18.11. Prvotní bump → 2.18.10 vyřešil CVE-2026-68497 (DoS vytížením CPU přes neohraničené parsování čísel); následná vlna Jackson advisories pak označila čtyři další HIGH DoS — dva v tranzitivním jackson-core (CVE-2026-89407 regex backtracking, CVE-2026-89425 neohraničený růst StringBuilder) a dva v jackson-databind (CVE-2026-91776 neohraničený růst cache, CVE-2026-91777 kvadratické forward-reference) — všechny opravené ve 2.18.11, která tranzitivně srovná i jackson-core → 2.18.11. Vše zůstává na patch řadě 2.18.x (drop-in, bez změn API) a Trivy filesystem sken dev-pipeline je zelený. Java SDK nyní importuje Jackson BOM (com.fasterxml.jackson:jackson-bom, pinnutý přes jedinou property jackson.version) v dependencyManagement, takže jackson-core, jackson-databind i jackson-annotations zůstávají verzově zarovnané a budoucí bumpy Jacksonu jsou změna na jednom řádku.
• Odstraněn x/net HTTP/2 DoS (CVE-2026-78669) — golang.org/x/net byl povýšen → 0.60.0 v modulech backend, agent, cli, k8s-operator a terraform-provider-mazevault kvůli vyřešení CVE-2026-78669 (odepření služby v net/http2 přes nadměrné HTTP/2 SETTINGS rámce), na kterém padal Trivy filesystem sken dev-pipeline. Všech pět modulů se čistě buildí i testuje a Trivy sken CRITICAL,HIGH --ignore-unfixed je zelený napříč všemi moduly.
• Druhá vlna závislostí (ověřeno) — Byla aplikována a ověřena další dávka bezpečných bumpů (backend go build/vet/plný go test, agent build/test linux+windows, frontend tsc -b/lint/build/165 testů na Node 24, Trivy, govulncheck): Go moduly backendu (Azure azcore 1.23.2 / azidentity 1.14.1, azblob 1.8.2, aws-sdk-go-v2/config 1.33.8, service/s3 1.114.2, gin-contrib/cors 1.7.9, go-ldap/ldap/v3 3.4.15, microsoft/go-mssqldb 1.11.2, golang.org/x/crypto 0.57.0, golang.org/x/oauth2 0.37.0, golang.org/x/time 0.16.0, google.golang.org/api 0.301.0 — ta tranzitivně posunula google.golang.org/grpc → 1.84.0, kterou aktuální databáze Trivy pro CVE-2026-84445 už neflaguje, a koordinovaný lockstep bump k8s.io/api + k8s.io/apimachinery + k8s.io/client-go 0.28.0 → 0.37.1, proti kterému se Kubernetes rotační kroky čistě buildí i testují); npm balíčky frontendu (lucide-react 1.50.0, @types/node 26.6.4, globals 17.13.0, vitest 5.0.3); a GitHub Actions (actions/checkout, actions/setup-go, actions/setup-node v5 → v7 a actions/download-artifact v4 → v8, která zůstává kompatibilní s již připnutým actions/upload-artifact@v7 a stahováním podle name/pattern v tomto repu). Odloženo (blokováno): dříve sledované PR typescript 7 a eslint 10 (stále blokované peer rozsahy ESLintu).
• Konsolidované aktualizace závislostí — Byla aplikována a end-to-end ověřena velká dávka rutinních aktualizací (backend/agent go test, frontend tsc/lint/build/165 testů na Node 24, Trivy, govulncheck): Go moduly backendu (microsoftgraph/msgraph-sdk-go, swaggo/swag, swaggo/gin-swagger, Azure azcore/azblob, Venafi/vcert, aws-sdk-go-v2 core/config/credentials/s3/route53, gin-contrib/cors, jackc/pgx, miekg/pkcs11, lib/pq, mongo-driver, prometheus/client_golang, stretchr/testify), Go moduly agenta (go-resty, prometheus/client_golang, golang.org/x/crypto 0.57.0, golang.org/x/sys 0.48.0, go-pkcs12 0.7.3), npm balíčky frontendu (react/react-dom 19.3.0, react-router 8.4.0, axios 1.20.0, date-fns, jspdf-autotable, @noble/hashes a @noble/ciphers 2.4.0, lucide-react 1.x, @types/node 26, @testing-library/react a user-event, @vitejs/plugin-react 6, globals 17, autoprefixer, @tailwindcss/postcss, eslint-plugin-react-refresh, vite-plugin-node-polyfills), základní image kontejnerů (alpine 3.21 → 3.24 pro init-certs, python 3.12-alpine → 3.14-alpine pro build stage dokumentace) a GitHub Actions (actions/upload-artifact 4 → 7, actions/github-script 7 → 9, azure/aks-set-context 4 → 5, azure/login 2 → 3, codecov/codecov-action 4 → 7, github/codeql-action 3 → 4, docker/build-push-action 6 → 7, docker/setup-buildx-action 3 → 4, docker/login-action 3 → 4, zaproxy/action-baseline 0.14 → 0.15). Automatické PR závislostí se nyní otevírají proti integrační větvi dev (Dependabot target-branch: dev pro každý ekosystém) místo výchozí větve. Odloženo (blokováno upstreamem, ponecháno jako otevřené sledované PR): typescript 7 (blokuje peer typescript <6.1.0 v typescript-eslint) a eslint 10 / @eslint/js 10 (blokuje eslint-plugin-react, který zatím nedeklaruje peer eslint ^10).
• Material UI povýšeno na v9 (major, frontend) — Administrátorská konzole byla migrována z Material UI 7 na @mui/material / @mui/icons-material 9.4.0 a @mui/x-date-pickers 9.14.0. Všechna odebraná/přejmenovaná v9 API byla migrována oficiálními MUI codemody plus cílenými opravami: zastaralé systémové style-propy (fontWeight, display, fontFamily, alignItems, fontStyle, spacing, …) přesunuty do sx; legacy slot-propy TextField/Dialog/Checkbox/Autocomplete (InputProps, inputProps, InputLabelProps, SelectProps, PaperProps, TransitionProps) přesunuty do sjednoceného API slotProps; odebrané ikony *Outline přesměrovány na ekvivalenty *OutlineOutlined; a theme override MuiButton containedPrimary přepsán přes v9 API variants. Jde o interní upgrade frontendové knihovny komponent bez změny aplikačních rout, chování nebo backend/API kontraktů; kompletní TypeScript type-check, ESLint, produkční build i sada 165 unit testů procházejí.
• Build/test frontendu vyžaduje Node ≥ 22.22 — Testovací toolchain byl povýšen na vitest 5 a jsdom 30, jejichž vestavěné undici vyžaduje runtime API Node (webidl.util.markAsUncloneable) dostupné až na Node ≥ 22.22. CI i Docker image frontendu už běží na Node 24; do kořene repozitáře a do frontend/ byly přidány soubory .nvmrc (fixované na Node 24), takže lokální vývoj vybere kompatibilní runtime automaticky.
• Autentizační cookies mají SameSite=Lax (nález OWASP ZAP) — Cookies refresh_token a XSRF-TOKEN se při COOKIE_SECURE=true posílaly se SameSite=None, takže je prohlížeč přikládal i k požadavkům z cizích webů. Nově mají vždy SameSite=Lax; COOKIE_SECURE dál řídí jen příznak Secure. Webové rozhraní volá API vždy na vlastním originu a přihlášení přes SSO (Entra) se nemění. Existující relace pokračují: refresh cookie dostane nový atribut při dalším obnovení tokenu.
• Cache API a ochrana proti cross-site požadavkům (nálezy OWASP ZAP) — Odpovědi API mají nově výchozí Cache-Control: no-store, no-cache, must-revalidate a X-Content-Type-Options: nosniff, takže odpovědi přihlášení, obnovení tokenu, SSO ani stavové odpovědi neukládá prohlížeč ani proxy; CRL a ACME si ponechávají vlastní cache politiku. Izolace zdrojů podle Fetch Metadata odmítne cross-site požadavky prohlížeče s 403, pokud nejde o navigaci na nejvyšší úrovni nebo o origin uvedený v CORS_ALLOWED_ORIGINS. Klientů mimo prohlížeč (agenti, gatewaye, SCEP/ACME/OCSP, CLI, Terraform) se změna netýká. Pokud API volá prohlížečová aplikace z jiné domény, uveďte její origin v CORS_ALLOWED_ORIGINS.
• Role omezené na organizaci zůstávají ve své organizaci — Role přiřazená pro jednu organizaci už nedává přístup k projektům, tajemstvím, certifikátům ani během rotace jiné organizace: kontrola oprávnění posuzuje každý požadavek v organizaci a projektu daného zdroje, ne ve výchozí organizaci volajícího, a za globální se považuje jen role přiřazená bez organizace i projektu. Role uvnitř vlastní organizace a globální role fungují jako dosud. Uložená rozhodnutí o oprávněních se nově drží zvlášť pro organizaci, projekt, IP klienta a stav MFA. Přiřazení role (POST /api/v1/rbac/users/{id}/roles) s project_id, organization_id nebo environment, které je uvedené, ale neplatné (ne-UUID, prázdný řetězec, číslo), se odmítne s 400 místo uložení jako globální přiřazení.
• Tajemství lze zakládat jen v projektech, kam smíte zapisovat — POST /api/v1/secrets, POST /api/v2/secrets, POST /api/v2/secrets/migrate a POST /api/v2/secrets/compare berou projekt nebo tajemství z těla požadavku a kontrola oprávnění ho nově posuzuje právě tam: volající potřebuje secret:write (u porovnání secret:read) v tom projektu, v jeho organizaci nebo globálně, a to pro prostředí uvedené v těle. Dříve role omezená na jeden projekt založila tajemství v libovolném projektu, i cizí organizace, převedla tajemství cizího tenanta do formátu zero-knowledge a porovnala prostředí cizího projektu. Takové požadavky nyní dostanou 403; dávka migrace, která obsahuje tajemství, do něhož volající zapisovat nesmí, se odmítne celá a nepřevede se z ní nic.
• Konfigurace, běhy a zálohy rotace zůstávají ve svém projektu — /api/v1/rotation/configs/{id} (čtení, úprava, smazání, preflight, spuštění), /api/v1/rotation/resources/{kind}/{id} (čtení, připravenost, historie, spuštění: Entra credentialy v projektu registrace aplikace, cíle nasazení a obnovy certifikátu v projektu certifikátu; systémové klíče, keytaby a tajemství servisních identit jen pro globální role), /api/v1/rotation/executions/{id} (i /resume), /api/v1/rotation/preflights/{id} a /api/v1/rotation/backups/{id}/… se nově posuzují v projektu a organizaci rotační konfigurace, běhu, preflightu nebo zálohy, kterou jmenují; neexistující id vrátí 404. Dříve role rotace v jednom projektu přečetla a spustila rotaci tajemství cizí organizace a odhalila nebo obnovila jeho předrotační hodnotu. POST /api/v1/rotation/configs ověří secret_id z těla (403/404) a odhalení i obnova zálohy ověří secret:read v projektu a prostředí tajemství. GET /api/v1/rotation/executions, GET /api/v1/rotation/backups a GET /api/v1/rotation/resources vypíšou jen to, co patří projektům a organizacím, kde má volající rotation:read (s globální rolí vše, včetně zdrojů bez projektu, jako jsou systémové klíče). Cíl certifikátu secret_manager smí zapisovat jen do projektu organizace certifikátu a jeho uložení vyžaduje secret:write v tom projektu (404/403); preflight zablokuje existující cíl v cizí organizaci (target_project_other_organization).
• Role omezené na prostředí se posuzují v prostředí tajemství — Role přiřazená pro jedno prostředí se nově ověřuje proti prostředí tajemství, které požadavek jmenuje, ne proti ?environment= nebo výchozímu: role jen pro dev už nepřečte, nepřevede ani nezkopíruje tajemství z prod (403). POST /api/v1/secrets/{id}/copy posoudí cílové prostředí v projektu tajemství a u neznámého tajemství vrátí 404.
• Detekce driftu napříč organizacemi vyžaduje globální roli — POST /api/v1/secrets/drift/detect bez project_id projde vazby tajemství všech organizací; nově vrátí 403, pokud volající nemá secret:write globálně. Webové rozhraní projekt posílá vždy.
• Projektové role platí mimo kontrolu trasy jen ve svém projektu — Přiřazení omezené na projekt už neplatí pro rozhodnutí bez projektu (záloha rotace patřící organizaci, rozsah výpisu, kontrola rozsahu z těla). Kontrola trasy u endpointů bez projektu nebo bez dohledatelného id projektovou roli zatím pustí, dokud se tyto endpointy neomezí na svůj rozsah.
• Integrace, aplikace Entra, pravidla synchronizace a vazby secretů zůstávají ve svém projektu — Cesty, které nesou jen id integrace, registrace aplikace Entra, pověření Entra, spravovaného subjektu, konfliktu synchronizace Entra, pravidla nebo konfliktu synchronizace (/api/v1/projects/integrations/{id}… včetně databázových relací, /api/v1/entra/{integrationId}/…, /api/v1/entra/apps/{id}…, /api/v1/entra/credentials/{id}…, /api/v1/entra/subjects/{id}, /api/v1/entra/sync-conflicts/{id}/resolve, /api/v1/projects/sync-rules/{id}…, /api/v1/projects/sync-conflicts/{id}/resolve), se nyní posuzují v projektu, kterému daný prostředek patří: role jiného projektu nebo organizace dostane 403 a neexistující id 404 (dříve některé odpovídaly 200 s prázdným seznamem, 409 nebo „failed“ dry-runem). GET /api/v1/integrations, GET /api/v1/entra/expiry-report a POST /api/v1/admin/azure/mi-permissions-check ukazují jen integrace a pověření projektů, ve kterých volající oprávnění má. Pravidlo synchronizace, vazba secretu a akce po rotaci v konfiguraci rotace Entra smí odkazovat jen na integraci vlastního projektu (jinak 400), úprava pravidla synchronizace už nemění project_id (Terraform zdroj mazevault_sync_rule při změně project_id pravidlo nahradí), smazání vazby secretu vyžaduje její vlastní secret (jinak 404) a databázová integrace čte odkazy do Key Vaultu (admin_password_integration_id, wallet_password_integration_id, uložené administrátorské přihlašovací údaje) jen z integrace vlastního projektu.
• Vazby agentů a discovery politika zůstávají v organizaci agenta — POST /api/v1/projects/{id}/integrations/agents naváže jen agenta organizace projektu; agenta jiné organizace nebo neznámé agent_id odmítne s 400 a nic neuloží (dříve šlo navázat libovolného agenta a neznámý vrátil 500). PUT /api/v1/agent-integrations/{id} se nyní posuzuje v projektu vazby: upravit ji může zapisovatel toho projektu (project:write) (dříve jen role na celou organizaci, a ty upravily vazby kterékoli organizace), role jiné organizace je odmítnuta a neznámá vazba dostane 404. GET /api/v1/agents/me/discovery/policy sestaví balíček jen ze šablon organizace volajícího agenta (dříve dostal každý agent šablony nejstarší organizace včetně jejích kandidátů hesel keystore); agent bez organizace dostane jen vestavěné výchozí hodnoty. Agenti nepotřebují změnu: požadavek je stejný a organizace se bere z identity agenta. Agenta registrovaného bez organizace (starší registrace) nelze navázat na projekt, dokud se znovu nezaregistruje s deployment tokenem. Vazby mezi organizacemi vytvořené před tímto vydáním se automaticky neodstraní: projděte seznam agentů každého projektu (záložka Integrace projektu) a agenty jiných organizací odpojte.
• Schvalovací politiky a žádosti zůstávají ve své organizaci — PUT/DELETE /api/v1/projects/approval-policies/{policyId}, GET /api/v1/projects/approval-requests/{requestId} a jeho akce /approve a /reject se nyní posuzují v projektu, do kterého politika nebo žádost patří. Dříve mohla role v libovolné organizaci přečíst schvalovací žádost jiné organizace, schválit či zamítnout ji a oslabit nebo smazat její schvalovací politiky. Role jiného projektu nebo organizace nyní dostane 403 a neexistující id 404 (dříve 500 u úpravy, schválení a zamítnutí a 204 u smazání). Úprava politiky mění jen její vlastní nastavení (název, spouštěč, podmínky, schvalovatele, expiraci, notifikace, zapnutí); project_id, id a časová razítka v těle se ignorují, politiku tak už nejde přesunout do jiného projektu. Zdroj Terraformu mazevault_approval_policy při terraform destroy bere politiku už smazanou v MazeVaultu jako smazanou.
• Úprava a import certifikátu zůstávají v organizaci volajícího — PUT /api/v1/certificates/{id} s project_id nově vyžaduje certificate:import i v cílovém projektu (jinak 403) a služba odmítne přesunout certifikát (i s privátním klíčem) do projektu jiné organizace (400); šablona jiné organizace je nově také 400 (dříve 500). POST /api/v1/certificates/import, /import/bulk a /import/file posuzují každý project_id požadavku: bez certificate:import v daném projektu je celý požadavek odmítnut s 403 a nic se nenaimportuje (dříve mohl držitel práva jednoho projektu naimportovat certifikát i privátní klíč do libovolného projektu, i cizí organizace). template_id jiné organizace, než je cílový projekt, je na všech importních cestách odmítnuto s 400, stejně jako template_id bez project_id; PUT /api/v1/certificates/{id} podobně odmítne šablonu pro certifikát bez projektu, pokud ho týž požadavek do projektu nepřiřadí. /import a /import/bulk ignorují organization_ca_account_id a ca_id z těla (jako už souborový import); CA účet se řídí šablonou. Odpověď „already exists“ jmenuje projekt existujícího certifikátu jen při importu do téhož projektu. Cesta hromadného importu ve Swaggeru je opravena z /certificates/import/batch na /certificates/import/bulk (samotná cesta API se nemění).
• Konfigurační soubory a objevené certifikáty zůstávají v organizaci — GET /api/v1/config-files, GET /api/v1/config-files/overview, GET /api/v1/discovery-results, GET /api/v1/discovered-certificates a GET /api/v1/discovered-certificates/stats nově vypisují a počítají jen záznamy projektů a organizací, ve kterých má volající oprávnění ke čtení (dříve soubory, výsledky discovery a objevené certifikáty všech organizací). Záznam bez projektu patří organizaci agenta, který ho nahlásil (objevený certifikát ze synchronizace CA organizaci CA účtu); agent bez organizace: jen globální role. GET /api/v1/config-files/{id}, POST /api/v1/discovery-results/{id}/adopt a /ignore a GET/POST /api/v1/discovered-certificates/{id} (detail, assign, adopt, ignore, archive, import-key) se posuzují v projektu nebo organizaci záznamu: záznam jiné organizace vrátí 403 a nic se nezmění, neznámé id 404 (GET /config-files/{id} dříve vracel 500). Cílový projekt u assign, bulk/assign, bulk/adopt a u adopt výsledku discovery musí být projekt, ve kterém má volající discovered_cert:assign (u výsledku discovery config:write; jinak 403), a bulk/assign, bulk/adopt a bulk/ignore odmítnou celý požadavek (403), pokud některé id patří do rozsahu, kde volající nemá discovered_cert:bulk. Projektová role vidí a mění jen objevené certifikáty už přiřazené jejímu projektu; nepřiřazené vyžadují roli organizace. Cílový projekt musí patřit organizaci záznamu, i pro volajícího s rolemi ve více organizacích (403; neznámý cílový projekt 404 místo 500), a adopce používá organizaci záznamu. Objevený certifikát se automaticky (report agenta, synchronizace CA) navazuje jen na spravovaný certifikát vlastní organizace, takže přes něj už nejde přesunout ani odhalit certifikát jiné organizace; přiřazení záznamu navázaného na spravovaný certifikát přesune tento certifikát jen v rámci organizace (jinak 409) a nově vyžaduje i certificate:write na něm a v cílovém projektu (403). Vazby na spravovaný certifikát jiné organizace vzniklé před touto verzí zůstávají, ale certifikát už nepřesunou. Import a obnova certifikátu navazují jen objevené certifikáty vlastní organizace, detail a import-key starší vazbu na spravovaný certifikát jiné organizace ignorují (import-key vrátí 400) a synchronizace CA účtu ani adopce už nedají objevenému ani spravovanému certifikátu jiné organizace tento CA účet ani jeho objednávku.
• Certifikační autority, CA účty a šablony zůstávají v organizaci — CA patří organizaci svého projektu, CA na úrovni organizace organizaci, jejíž CA účet ji navazuje. GET /api/v1/ca vypíše jen CA organizací a projektů volajícího (globální role všechny); GET/PUT /api/v1/ca/{id}, POST /api/v1/ca/{id}/hsm a POST /api/v1/ca/{id}/crl/regenerate nad CA jiné organizace nebo nad CA bez organizace bez globální role skončí 403. ca_authority_id CA účtu i ca_account_id šablony certifikátu musí patřit téže organizaci (jinak 400) a každá cesta vydání (včetně obnovy a ACME) odmítne šablonu, která byla na CA účet jiné organizace navázána před touto verzí. PKI režim root vytvoří organizaci vlastní root CA místo použití stejnojmenné CA jiné organizace. POST /api/v1/projects/{id}/ca/{caId}/hsm a POST /api/v1/projects/{id}/certificates/{certId}/revoke nově pracují s {caId} / {certId} projektu {id} (dříve četly id projektu jako id CA / certifikátu a nefungovaly); CA nebo certifikát mimo projekt vrátí 404. Certifikáty gatewayí (POST /api/v1/gateways/csr) se vydávají jen ze systémové šablony gateway-mtls instance a podepisuje je jen CA instance (vytvořená přes POST /api/v1/ca/initialize, které nově vyžaduje globální roli: role organizace dostane 403); šablona tenanta jménem gateway-mtls (obchvat, který si některé instalace vytvořily) se nově ignoruje a bez systémové šablony nebo CA instance je odpověď 404 (dříve 500). Šablony bez CA (např. agent-mtls) podepisuje interní CA jejich organizace, jinak CA instance, nikdy CA jiné organizace. Systémové šablony (agent-mtls, gateway-mtls) už nejde upravit ani smazat (403). ocsp_responder_cert_id CA musí být certifikát organizace CA (400). Vydávání, obnova, finalizace ACME i DCV používají CA účet šablony jen v organizaci šablony. Žádost o certifikát (POST /api/v1/certificates/csr, POST /api/v1/projects/{id}/csr) smí použít jen šablonu organizace projektu (nebo agenta); šablona jiné organizace vrátí 404 a POST /api/v1/certificates/csr bez projektu vyžaduje certificate:request v organizaci šablony. Upgrade: organizace bez vlastní interní CA a instalace bez CA instance už nedostanou mTLS certifikáty agentů podepsané nějakou jinou interní CA: registrace agentů selže, dokud organizace neinicializuje svou interní CA (Organization Settings → Project Settings → Certificate Authorities → Initialize Internal CA) nebo globální administrátor nevytvoří CA instance (POST /api/v1/ca/initialize). CA vytvořená přes POST /api/v1/ca/initialize, kterou později navázal CA účet organizace, je CA té organizace, ne CA instance; byla-li jediná, dostanou gatewaye 404, dokud globální administrátor nevytvoří novou CA instance. PKCS#11 HSM, jehož modul nejde načíst, nově skončí chybou (test zařízení ho hlásí jako nedostupné) místo paniky, která při odvolání certifikátu CA nastavené na takové HSM zastavila backend.
• Stránky organizace pracují s organizací z cesty — /api/v1/organizations/{id}/… se nově posuzuje v organizaci, kterou jmenuje {id}, ne ve výchozí organizaci volajícího: role omezená na jednu organizaci už nepřejmenuje cizí organizaci, nepřidá jí prostředí, nepřečte její licenci ani nastavení synchronizace a nespravuje její účty CA, interní CA, HSM zařízení, politiky obnovy ani ACME (EAB) pověření (403), a to ani s ?project_id= projektu vlastní organizace (403). Položky pod cestou se hledají jen v této organizaci: prostředí, politika obnovy, HSM zařízení nebo EAB pověření cizí organizace vrátí 404 a zůstanou beze změny; smazání neexistující (nebo už smazané) položky nově vrátí 404 místo 204 (prostředí, politiky obnovy, EAB pověření) nebo 400/409 (HSM zařízení). POST /api/v1/organizations/{id}/acme-credentials odmítne project_id, default_template_id nebo šablonu v doménovém pravidle z cizí organizace (404) a objednávka ACME už nepoužije dříve uloženou výchozí šablonu ani šablonu doménového pravidla cizí organizace (bez jiné šablony se objednávka odmítne). PUT/DELETE /api/v1/organizations/integrations/{id} a /api/v1/organizations/templates/{id}, akce agenta /api/v1/agents/{id}/… (kanál aktualizací, dopad, odregistrace, nová registrace, odinstalace) a zastaralé /api/v1/ca-accounts/{id}/products a /sync se posuzují v organizaci integrace, šablony, agenta nebo účtu CA (agent bez organizace: jen globální role); neznámé id vrátí 404. GET/POST /api/v1/ca-accounts/ s jiným organization_id, než je organizace volajícího, vyžaduje oprávnění CA v té organizaci (403). Terraform zdroje mazevault_environment, mazevault_renewal_policy a mazevault_hsm_device berou 404 při destroy jako už smazaný objekt.
• Schvalování vynucuje princip čtyř očí, expiraci a jednorázové použití — Žadatel už nemůže schválit vlastní žádost o schválení (princip čtyř očí), ani s oprávněním approval:approve a required_approvers: 1; žádost po expires_at už nejde schválit a schválená žádost o publikaci rotace už po expires_at neplatí. Obojí se odmítne chybou a žádost zůstane pending. Souběžné hlasy se serializují, takže kvórum se počítá správně. Vytvoření žádosti o schválení přes API už nepřijímá pole, která patří serveru (status, policy_id, expires_at, resolved_at, decisions), takže klient nevytvoří rovnou schválenou žádost ani hlasy za jiné uživatele, a required_approvers je nejméně 1; vlastní hlas žadatele se do kvóra nikdy nezapočítá. Schválenou žádost o publikaci rotace nově použije jen jeden nový záměr rotace: když původní záměr rotace nejde znovu použít (tajemství s environment_bound preflightem) nebo když automatické pokračování po schválení autorizuje znovu, převezme schválení čekajícího záměru nový záměr (stejný prostředek, akce a schvalovací politika; uživatel převezme jen schválení vlastních žádostí) a původní záměr se označí superseded. Dřív taková rotace skončila znovu na „approval required“ a nikdy neproběhla. Souběžná spuštění záměru, který se znovu použije (jeho preflight ještě platí), zatím takto omezená nejsou a jedno schválení mohou použít obě (sledováno jako F-BEROT-044).
• Přidělení rolí a přístupu nepřesáhne práva volajícího — Přiřazení role (POST /api/v1/rbac/users/{id}/roles), odebrání přiřazení, vytvoření a smazání mapování skupiny (/api/v1/rbac/mappings) a vytvoření uživatele s role (POST /api/v1/rbac/users) nově vyžadují, aby volající měl každé oprávnění dané role včetně oprávnění, která omezují její zákazy (!x) (a pro předání role admin samotnou roli admin) přes vlastní přiřazení rolí, která pokrývají cílový rozsah a nevyprší dřív; jinak odpověď zní 403. Správce organizace spravuje role jen ve své organizaci; uživatel vytvořený s role dostane globální přiřazení, takže ho smí vytvořit jen volající s touto rolí globálně (jinak vytvořte uživatele bez role a přiřaďte mu roli organizace nebo projektu). Smazání uživatele (DELETE /api/v1/rbac/users/{id}) vyžaduje práva odebrat každé jeho přiřazení role. Správci organizací a stránka Access Control: stránka zakládá uživatele s globální rolí user a přiřazuje role bez rozsahu (globálně), takže správce organizace tam nově dostane „Failed to create user“ / „Failed to assign role“. Uživatele vytvořte přes API bez role (POST /api/v1/rbac/users jen s email a password) a roli přiřaďte přes POST /api/v1/rbac/users/{id}/roles s {"role_id": "<role>", "scope": {"organization_id": "<organizace>"}} (nebo project_id; role projektu jde přiřadit i na záložce Access projektu). Rozsah, jehož project_id patří jiné organizaci než organization_id, nebo neznámý projekt se odmítne s 400; granted_by je vždy volající. Dočasný přístup (POST /api/v1/access/temporary) nově přijímá zdokumentované tělo (target_user_id, resource_type, resource_id, permissions, duration_minutes, reason, volitelně environment); schvalovatel potřebuje <resource_type>:grant_access v projektu nebo organizaci zdroje a smí udělit jen oprávnění, která sám má, nebo konkrétní akce daného typu zdroje, a udělení pro jeden zdroj už neplatí pro požadavky bez tohoto zdroje. Break-glass (POST /api/v1/access/break-glass) vyžaduje oprávnění access:break_glass a * přes globální přiřazení (prakticky globální administrátor); odmítnuté pokusy se zapíší do auditu jako GRANT_BREAK_GLASS_DENIED.
• Přiřazení rolí pro všechna prostředí (*) a nouzový přístup break-glass nyní platí (před aktualizací je zkontrolujte) — Přiřazení role s prostředím * nyní platí ve všech prostředích; dříve neplatilo v žádném a nic neudělovalo. Zůstává omezené na svou organizaci nebo projekt a stejně jako každé přiřazení vázané na prostředí neplatí pro požadavek bez prostředí (totéž platí pro * v dočasném udělení). Udělení break-glass (POST /api/v1/access/break-glass) nyní dává držiteli * na všechny typy zdrojů ve všech prostředích, dokud po hodině nevyprší nebo není odvoláno (rozhodnutí o přístupu se ukládají do mezipaměti až na CACHE_PERMISSION_TTL_SECONDS, výchozí 5 minut, takže povolení může vypršení o tuto dobu přežít); dříve neplatilo nikdy. Akce životního cyklu archivu dál vyžadují roli admin a zákaz (!x) v některé z rolí držitele blokuje x i během break-glass. Stejně začnou platit dočasná udělení pro prostředí * (POST /api/v1/access/temporary). Pokud požadavku odpovídá několik dočasných udělení, jejich oprávnění se nyní sčítají (dříve se vybralo jedno z nich). Před aktualizací zkontrolujte přiřazení, která začnou platit: SELECT user_id, role_id, organization_id, project_id FROM user_roles WHERE environment = '*';, a aktivní udělení break-glass a udělení s *: SELECT identity_id, resource_type, environment, valid_until, reason FROM environment_permissions WHERE (resource_type = '*' OR environment = '*') AND is_active AND (valid_until IS NULL OR valid_until > now());.
• Skupiny konzistence, položky fronty obnovy a cíle certifikátů zůstávají ve svém projektu — /api/v1/consistency-groups/{id} (čtení, úprava, smazání, /check), /api/v1/consistency-warnings/{id}/resolve a /api/v1/renewal-queue/{id}/… (schválení, zrušení, obnovení, stav DCV, opakování DCV a nové odeslání e-mailu) se nyní posuzují v projektu skupiny konzistence nebo certifikátu ve frontě: role jiného projektu nebo organizace dostane 403 a neexistující id 404 (dříve role omezená na jeden projekt četla, přepsala a smazala skupinu konzistence cizí organizace, rušila obnovy jejích certifikátů a četla jejich DCV záznamy). /api/v1/certificates/{id}/targets/{targetId}… a /api/v1/certificates/{id}/rotation/executions/{execId} vrátí 404 pro cíl nasazení nebo exekuci rotace, které nepatří certifikátu {id}; dříve vracely konfiguraci cíle a exekuci cizí organizace (neplatné {id} na trasách cílů nyní vrátí 400). Vytvoření a úprava cíle nasazení certifikátu (POST /api/v1/certificates/{id}/targets, PUT …/targets/{targetId}) přijme jen agent_id organizace certifikátu a integration_id / database_integration_id projektu certifikátu (jinak 400); dříve mohl cíl odkazovat na agenta nebo integraci Key Vault cizí organizace a /sync tam nasadil certifikát i s klíčem. Cíle uložené před touto verzí se znovu nekontrolují: zkontrolujte agenty a integrace u stávajících cílů certifikátů. Agenta registrovaného bez organizace (starší registrace) už nejde nastavit jako cíl, dokud se znovu nezaregistruje s deployment tokenem.
• ?organization_id= ani organization_id v těle už nesáhnou do jiné organizace — Požadavek, který jmenuje organizaci v ?organization_id= (spravované tokeny, keytaby, šablony certifikátů, nasazení agentů, fronta obnov, CA účty), nově potřebuje oprávnění trasy i v této organizaci, jinak dostane 403; dříve se role posuzovala v organizaci volajícího, zatímco handler pracoval v jmenované. Totéž platí pro organization_id v těle POST /api/v1/projects/ (project:write) a POST /api/v1/deployments/ (deployment:write). GET /api/v1/projects/ vypíše jen projekty, ve kterých má volající project:read. /api/v1/certificate-templates/{id}, /api/v1/naming-conventions/{id}/… a POST /api/v1/keytabs/discovered/{id}/import se posuzují v organizaci šablony nebo objeveného keytabu (neznámé id je 404, dříve 500); POST /naming-conventions/{id}/provision zakládá projekty jen v organizaci šablony (jiné organization_id je 403) a objevený keytab lze importovat jen do projektu jeho organizace (404). Založení projektu potřebuje project:write na úrovni organizace, a to v organizaci z těla, bez ní v organizaci volajícího (projektová role už nestačí); bez organization_id projekt dál vznikne jen na instanci s jedinou organizací. Volající přes API a SDK, kteří mají jen projektovou roli a pošlou ?organization_id= organizace, nově na těchto trasách dostanou 403 (např. výpis tokenů a keytabů); kde trasa bere project_id, pošlete místo toho project_id svého projektu, nebo mějte roli v dané organizaci. Bez project_id projektová role na těchto trasách platí jen pro projekt organizace volajícího (výchozí organizace instance, ve které se tyto trasy posuzují); dřív na nich projektová role jakékoli organizace jednala s právy celé výchozí organizace.
• Dashboardy, reporty a týdenní report ukazují jen organizace volajícího — Bez project_id nyní /api/v1/dashboard/* (přehledy secretů, certifikátů, konfigurace a rotací, /export všech typů, /rotation/failures, /rotation/actionable, /sync/overview, /sync/conflicts, /sync/failures), GET /api/v1/certificates/, /api/v1/archived/summary, /projects, /secrets, /certificates a GET /api/v1/reports/preview počítají a vypisují jen projekty a organizace, v nichž má volající oprávnění; dříve zahrnovaly všechny organizace. Řádky bez projektu (certifikáty, běhy rotací) vidí jen globální role; export ca_accounts vypíše jen organizace, v nichž má volající organizační roli. Potvrzení selhání rotace, selhání synchronizace nebo blokovaného seedu jiné organizace je odmítnuto (404 nebo 403); odložení rotace vyžadující pozornost jiné organizace vrátí already_removed a nic nezmění. GET /api/v1/sync-dashboard/events a /merkle (replikační data celé instance) vyžadují globální roli sync:read. Každý kanál s povoleným reportem (Slack, Teams, webhook, Jira) dostane týdenní report jen své organizace a stejně tak e-mailoví příjemci, kteří se nyní nastavují po organizacích (viz Příjemci týdenního reportu se nastavují po organizacích). Statistiky hesel v compliance reportu počítají jen secrety a šablony organizace.
• Service identity patří do organizace (po upgradu zkontrolujte) — Service identity má nově organization_id: vzniká ve výchozí organizaci instance (té, ve které se posuzují trasy bez projektu), nebo v organizaci z ?organization_id=, kde volající potřebuje service_identity:write ve výchozí organizaci i v ní a role omezená na organizaci vypíše, čte, přejmenuje, smaže a spravuje Universal Auth a client secrets (/api/v1/auth/universal-auth/identities/{id}…, rotační zdroje druhu service_identity_secret) jen u identit své organizace; globální role dál spravují všechny identity. Dříve role service_identity:* libovolné organizace spravovala identity všech tenantů. Neznámé ID identity nově vrací 404 (dříve 500 u úpravy). Migrace 000235 přiřadí každou existující identitu jediné organizaci jejích neprošlých přiřazení rolí, jinak organizaci uživatele, který ji vytvořil (tvůrce s globálním přiřazením role se nepočítá), jinak na instanci s právě jednou organizací této organizaci; nic neodstraní ani nevypne a přihlášení přes Universal Auth funguje dál. Na instanci s více organizacemi zůstane identita, kterou nelze přiřadit, bez organizace a spravují ji jen globální role; migrace každou vypíše jako řádek WARNING (000235: service identity …) do logu PostgreSQL. Po upgradu je vypíšete dotazem SELECT id, client_id, display_name FROM service_identities WHERE organization_id IS NULL; a přiřadíte příkazem UPDATE service_identities SET organization_id = '<id organizace>' WHERE id = '<id identity>';. POST /api/v1/service-identities/?organization_id= vrací 400 pro neplatné ID a 404 pro neznámou organizaci. Terraform resource mazevault_service_identity exportuje organization_id a identitu smazanou mimo Terraform považuje za odstraněnou.
• Offloadované klíče zůstávají v organizaci a trezoru volajícího (Orchestrator Mode) — Import certifikátu s key_storage_mode: external přijme key_integration_id jen z organizace projektu importu (project_id) a bez projektu ho odmítne (400); dřív šel privátní klíč zapsat přes integraci Key Vaultu cizí organizace. Každý offload klíče (certifikáty, keytaby, spravované tokeny) nově použije výslovně zvolenou integraci jen uvnitř organizace volajícího a offload, který neuvádí organizaci ani projekt, se odmítne místo použití nejstaršího secret manageru libovolné organizace: v Orchestrator Mode tak import nebo discovery privátního klíče certifikátu bez projektu selže, dokud certifikát nepřiřadíte projektu. Čtení a mazání offloadovaného klíče použije Key Vault uvedený v jeho referenci (dřív první Azure integraci organizace, případně libovolné organizace, takže se dvěma trezory se klíč hledal ve špatném); reference na trezor, který nemá žádná povolená integrace organizace vlastníka, selže. Export, smazání nebo znovupoužití při obnově externě uloženého klíče certifikátu bez projektu se ze stejného důvodu odmítne. Custody události offloadu nesou organizaci volajícího i tehdy, když je známá jen z kontextu požadavku.

Poznámky

• Dopad na upgrade (efektivní řetězec, tělo z discovery, kontrakt nasazení přes agenta) — Verze 1.0.61 přidává jednu idempotentní, aditivní migraci 000199_discovered_certificate_body (certificate_pem, chain_pem TEXT NULL v discovered_certificates; health check databáze oba sloupce validuje). Do certificates se nepřidává žádný sloupec, neběží žádný backfill, žádný existující řetězec se nepřepisuje. Certifikáty, které už uložený řetězec mají, se exportují, zobrazují, rotují a nasazují byte po bytu stejně jako dosud (kryto regresním testem); chování se mění jen u certifikátů s prázdným řetězcem, a to pouze když v téže organizaci existuje ověřený vydavatel. Čtení (export, detail, seznam pro agenta) nikdy nic nepersistuje; dohledaný řetězec se zapíše jen tehdy, když import nebo adopce ukládá tělo certifikátu bez řetězce. API přírůstky jsou aditivní: chain_source, chain_complete, chain_warnings na GET /certificates/{id} (a /projects/{id}/certificates/{certId}); certificate_pem, chain_pem, chain_certificates na GET /discovered-certificates/{id}; export záznamu bez těla nyní vrací 422 CERTIFICATE_BODY_MISSING místo obecné 500. Terraform: data source mazevault_certificate získává chain_pem, chain_source, chain_complete; jeho certificate_pem je nyní naplněn (dříve byl vždy prázdný, protože SDK četlo pole, které API nevydává) — plány, které na něj odkazovaly, poprvé ukážou hodnotu. Změny chování k prověření: (1) import privátního klíče ke spravovanému certifikátu bez těla je odmítnut, dokud tělo neexistuje (připojí ho příští sken agenta, příští synchronizace s CA, nebo ruční import veřejného certifikátu — CRT/PEM/DER či PFX; agenti používající starý protokol /agents/me/discovery tělo nehlásí, takže záznamy objevené pouze jimi se doplní jednou ze zbývajících dvou cest); (2) cíle nasazení se validují při uložení i při sestavení workflow rotace: cíle WebLogic potřebují keystore_path, trust_store_password_ref při nastaveném trust_store_path a wlst_script_path pro jakýkoliv režim restartu; cíle database wallet potřebují agenta, wallet_path, provider Oracle a update_tns_names=false (rac_nodes je rovněž odmítnut); cíle web_server a load_balancer jsou odmítnuty. Existující cíle se nemění — zapnutý cíl, který tato pravidla porušuje, nyní svou rotaci ukončí chybou s ID cíle a důvodem místo přeskočení nebo hlášení falešného úspěchu a vždy ho lze vypnout nebo smazat; editor v UI při uložení vypne starší update_tns_names=true a u nepodporovaných providerů a typů cílů ukáže alternativu. Před zapnutím automatické rotace prověřte cíle nasazení produkčních certifikátů na web_server, load_balancer, ne-Oracle položky Database Wallet a wallet cíle bez agenta; (3) se zapnutou volbou agenta install_chain_to_trust_store nainstaluje podřízená CA, která dosud neměla řetězec, při nasazení do trust store hostitele i svůj root — stejné chování, jaké vždy měly PFX importy s vloženým rootem. Rollout agentů: oprava nasazení do keystore JKS / PKCS#12 / Windows My na straně backendu/gateway funguje s již nasazenými agenty. Cíl Agent File (PEM), kroky agent_command (WebLogic restart, Oracle orapki), sémantika „pouze veřejné“ u windows_root / windows_ca a nasazení do Oracle wallet vyžadují agenta 1.0.61; starší agenti na tyto požadavky odpoví explicitní chybou unsupported proxy message type a krok nasazení selže rychle. Nasazení Oracle a WebLogic jsou kryta kontraktními testy proti protokolu agenta — před spolehnutím v produkci je ověřte proti skutečnému hostiteli s orapki / WLST na stagingu. Nedosažitelná duplicitní cesta adopce z discovery (CertificateDiscoveryService, handlers_discovery.go) byla odstraněna; její filtry seznamu (managed_certificate_id, discovered_by_agent_id, expirace) byly sloučeny do živého endpointu GET /discovered-certificates jako query parametry agent_id, managed_certificate_id a expiring_within_days a POST /discovered-certificates/{id}/ignore nyní přijímá volitelné tělo {"reason": "..."}, které se ukládá jako state_reason a zaznamenává do auditního logu — jediné dvě schopnosti odstraněného kódu, které živá cesta postrádala; adopce, hromadná adopce i obohacení detailu tam už byly nadmnožinou. Oba živé endpointy získaly Swagger dokumentaci a pět nikdy nenaroutovaných cest /discovery/certificates* ze Swagger výstupu zmizelo. Nepřibývají žádné nové proměnné prostředí, Helm hodnoty ani změny formátu release balíčku.
• Dopad na upgrade (custody klíčů certifikátů, validace CSR, normalizace serialů) — Žádná databázová migrace, žádná nová proměnná prostředí, žádná Helm hodnota, žádná změna formátu release balíčku a žádná změna kontraktu Terraform provideru (resource mazevault_certificate je založen na CSR a je neměnný; doplnění klíče je akce operátora). Změny API jsou volitelné a aditivní: expected_certificate_id na POST /certificates/import a POST /certificates/import/file, key_source_file v odpovědi preview-multi, identity_normalized v odpovědi POST /admin/certificates/backfill a hodnota failed v enumu status požadavku na certifikát. Změny chování, které je třeba před upgradem produkčního inventáře prověřit: (1) šablony s neprázdným allowed_key_sizes nyní odmítají nahraná CSR s jinou velikostí klíče už při odeslání — včetně ADCS a externích CA, které dříve nekontrolovaly nic — ověřte proto seznam u šablon používaných se zákaznickými CSR (prázdný seznam = libovolná velikost); (2) šablony s explicitní san_config ji nyní vynucují i na nahraná CSR — sloupce allow_additional_sans a max_san_count se pro nahraná CSR záměrně nepoužívají, protože je editor šablon nikdy spolehlivě neukládal; (3) při startu primary proběhne na pozadí idempotentní průchod, který přepíše serial_number / thumbprint_sha256 / thumbprint_sha1 pouze u řádků odlišných od uloženého DER (hex serialy zapsané ACME/Vault/finalizací externích objednávek, velká písmena v otiscích); certifikáty z interní CA, ADCS, DigiCert, Venafi a importované jsou již kanonické a nedotknou se jich, vazby na CA/CA účty ani nastavení obnovy se nikdy nemění a nevznikají žádné sync události; (4) import certifikátu, který už existuje v jiném projektu, nyní vrací chybu místo tichého připojení materiálu k záznamu cizího projektu; (5) automaticky schválené požadavky, jejichž vydání selže, jsou označeny failed (externě odložené čekající klíče jsou záměrně ponechány i s referencí pro úklid operátorem — při selhání CA se ze secret manageru nic nemaže) a ručně schválené se vrací do pending. Odložená rozhodnutí (zdokumentována v architektonické referenci): unikátní index na certificates.thumbprint_sha256 (čekající externí objednávky a legacy duplicity by rozbily upgrade), vynucení přiřazení šablony k projektu při odeslání CSR (vyžaduje MAJOR bump kvůli API/Terraform klientům), vlastní EKU OID v interní CA a limit pokusů / detekce zamítnutí u ADCS objednávek, které zůstávají trvale pending.
• Dopad na upgrade (Rotační šablony) — Verze 1.0.61 přidává jednu idempotentní migraci, 000195_rotation_template_policy_fields, která přidává tři sloupce do rotation_config_templates: lead_time_days (INT, výchozí 0), grace_period_days (INT, výchozí 0) a secret_custody_mode (VARCHAR, výchozí local). Kontrola zdraví databáze nyní ověřuje nové sloupce politiky šablon. Terraform resource mazevault_rotation_template získává volitelné argumenty lead_time_days, grace_period_days a secret_custody_mode a Go SDK je odpovídajícím způsobem aktualizováno; všechny přírůstky jsou aditivní a zpětně kompatibilní, žádný resource, datový zdroj, API endpoint ani SDK kontrakt se neodebírá ani nepřejmenovává. Nepřidávají se žádné nové proměnné prostředí, hodnoty Helm ani změny formátu release balíčku. Provider a SDK navíc vystavují již perzistovaná pole project_id a retry_delay_seconds (bez migrace) a organization_id na resource je Optional+Computed. Upozornění: při vytvoření šablony se explicitní 0 u max_retry_attempts, retry_delay_seconds nebo timeout_minutes neuplatní — server použije své výchozí hodnoty (3/5/10); tato pole vynechejte nebo nastavte kladnou hodnotu (pozdější změna na 0 přes update se uplatní).
• Dopad na upgrade (Životní cyklus agentů) — Tato funkce přidává jednu idempotentní migraci, 000196_agent_lifecycle_metadata, která do tabulky agents přidává nullable lifecycle sloupce (unregistered_at, unregistered_by, lifecycle_reason, lifecycle_reason_category, identity_revoked_at, uninstall_status, uninstall_requested_at, uninstall_completed_at, replaced_by_agent_id); kontrola zdraví databáze nové sloupce validuje. Druhá idempotentní migrace, 000198_deployment_purpose, přidává do tabulky deployments sloupec purpose (VARCHAR, výchozí standard), aby bylo možné odlišit autorizovaný jednorázový náhradní token od standardního enrollment tokenu — pouze náhradní token může znovu zaregistrovat vyřazeného agenta; kontrola zdraví databáze validuje i tento sloupec. Všechny změny jsou aditivní a zpětně kompatibilní. Guard RequireActiveAgent na JWT-autentizovaných agentních routách znamená, že agenti, kteří byli odregistrováni, revokováni nebo smazáni, jsou nyní odmítnuti i s neexpirovaným tokenem; podporovanou cestou obnovy zůstává re-enrollment přes platný deployment (nebo jednorázový náhradní) token — starší agenti zůstávají kompatibilní, protože se při odmítnutí jednoduše znovu zaregistrují. Přidány jsou čtyři aditivní agent:admin API endpointy (/agents/:id/lifecycle-impact, /unregister, /reregister, /uninstall) plus aditivní DELETE /api/v1/deployments/:id (deployment:write). Odpovědi list deploymentů nyní vynechávají bootstrap token (DeploymentResponse), zatímco odpověď create jej nadále vrací jednou (DeploymentCreatedResponse) — Go SDK i Terraform resource mazevault_deployment mají nezměněný kontrakt a token na create stále dostávají. Delete resource mazevault_deployment v Terraform provideru nyní volá nový delete endpoint (dříve no-op pouze ve stavu), takže terraform destroy zneplatní enrollment token na straně serveru; Read resource navíc znovu naplní organization_id, takže importovaný deployment lze zničit. Registrovaní agenti nejsou dotčeni. Vzdálená odinstalace je opt-in a pokouší se pouze o připojené Linux balíčkové instalace. Pro tuto funkci nejsou žádné nové proměnné prostředí, hodnoty Helm ani změny formátu release balíčku.
• Dopad na upgrade (Bezpečnost a závislosti) — Jedná se pouze o změny závislostí a build-time: žádné databázové migrace, proměnné prostředí, hodnoty Helm ani změny formátu release balíčku a žádné změny kontraktů API, Go SDK ani Terraform provideru.
• Dopad na upgrade (Frontend MUI v9 a Node toolchain) — Upgrade Material UI na v9 je interní frontendová změna bez dopadu na aplikační routy, chování, backend/API/Go SDK/Terraform kontrakty, proměnné prostředí, hodnoty Helm nebo formát release balíčku. Operátoři, kteří frontend sestavují ze zdrojů, nyní potřebují Node ≥ 22.22 (CI i kontejnerový image frontendu už běží na Node 24; .nvmrc fixuje Node 24 pro lokální vývoj). Runtime nasazení předsestaveného image frontendu není dotčeno.
• Dopad na upgrade (Zálohy rotace) — Tato změna přidává jednu idempotentní migraci, 000197_rotation_backup_lifecycle, která do tabulky rotation_backups přidává sloupce status (VARCHAR, výchozí pending), acknowledged_at a acknowledged_by, dopočítá status z restored_at a nahrazuje starý index expirace za částečný index pro úklid plus index na status; kontrola zdraví databáze nové sloupce validuje. Přidává se jedna nová volitelná runtime proměnná prostředí — MAZEVAULT_ROTATION_BACKUP_RETENTION_DAYS (výchozí 7) — propagovaná do .env.example, docker-compose, instalátorů i všech hodnot Helm. Přidány jsou čtyři aditivní rotation API endpointy pod /rotation/backups (list rotation:read; restore rotation:execute; reveal/acknowledge rotation:write, přičemž reveal/restore navíc vynucují secret:read). Všechny změny jsou aditivní a zpětně kompatibilní — žádný resource, datový zdroj, API endpoint ani SDK kontrakt se neodebírá ani nepřejmenovává — a nemění se formát release balíčku. Protože insert zálohy nyní uspěje, aktivuje se poprvé mechanismus zálohy před rotací a automatického rollbacku; zálohy vyžadující ruční obnovu jsou zviditelné přes nové endpointy a metriku mazevault_rotation_backups_recovery_required.
• Dopad na upgrade (Enterprise Functions / chránění Deploymentu) — Jde pouze o reorganizaci UI a vynucení licence: žádná databázová migrace, žádná proměnná prostředí, žádná hodnota Helm ani změna formátu release balíčku. Nový klíč license feature deployment_management je přidán do sad PoC a Enterprise odvozovaných funkcí getLicenseFeatures (state-aware: active / grace / expiring) a FeatureLicenseMiddleware je aplikován na CRUD skupinu /api/v1/deployments. Nemění se žádná API routa, schéma požadavku/odpovědi, Go SDK ani kontrakt Terraform provideru a plocha Swagger je beze změny. Změna chování: tenanti na plánu Small Business nebo bez licence, kteří dříve dosáhli na Deployment CRUD API, nyní dostanou HTTP 403 a upgrade banner; PoC a Enterprise tenanti nejsou dotčeni. Neautentizované UUID-chráněné bootstrap endpointy agenta zůstávají nechráněné, takže instalace agentů není ovlivněna. Text upgrade banneru pro SSH, Configuration a KeyTab byl sjednocen na „PoC or Enterprise“.
• Dopad na upgrade (offload klíčů v Orchestrator módu) — Pouze backendová změna: žádná databázová migrace, žádná nová proměnná prostředí, žádná změna API kontraktu. Dvě chování jsou záměrně přísnější a operátoři provozující Orchestrator mód by je měli zkontrolovat: (1) Výběr integrace se už nerozšiřuje mimo scope volajícího. Offload tokenu, keytabu nebo privátního klíče, který nese scope projektu/organizace a v něm nenajde povolenou integraci typu secret_manager / key_storage / hsm, nyní selže s no enabled key storage integration found for project/organization … místo tichého použití první integrace kdekoli v systému; explicitně zvolené integration_id, které neexistuje nebo je vypnuté, je odmítnuto stejně. Ujistěte se, že každá organizace používající spravované tokeny nebo keytaby v Orchestrator módu má povolenou secret-manager integraci v některém ze svých projektů. (2) Limit velikosti Azure Key Vault se vynucuje před zápisem. Hodnoty, jejichž base64 přenosové kódování přesáhne 25 600 bajtů (≈19 200 raw bajtů), jsou odmítnuty s 400 a přesným limitem; jde o dokumentovaný strop Azure na jeden secret, ne o omezení MazeVaultu — větší hodnoty vyžadují jako cíl úložiště klíčů projektu integraci HashiCorp Vault nebo AWS Secrets Manager (64 KB). Secrety vytvořené v Key Vaultu touto verzí používají nové ploché pojmenování (mazevault-token-…, mazevault-keytab-…, mazevault-<cn>-<serial>); existující reference uložené u certifikátů se respektují beze změny (update_version vytvoří novou verzi téhož secretu). V Key Vaultu se nic nepřejmenovává ani nemigruje.

---

Verze 1.0.60

Datum vydání: 2026-07-20

Nové funkce

• Správa tokenů — externí API tokeny s povinným sledováním expirace a nasazením přes agenta — Nová Enterprise funkce (licence PoC nebo Enterprise, feature token_management) pro správu externě vydaných API tokenů — například tokenů Jira nebo Signi — které lze obnovit pouze ručně v GUI zdrojového systému. Každý token se ukládá s povinným datem expirace a volitelným per-token předstihem upozornění (výchozí 30 dní); MazeVault před vypršením vyvolá incident token_expiry přes stávající notifikační kanály (e-mail, webhook, Teams, Slack, Jira, SMSEagle) a po vypršení jej eskaluje na critical. Hodnoty tokenů jsou ve standardním režimu šifrované at-rest (AES-256-GCM), nebo se v režimu Orchestrator offloadují do nakonfigurovaného externího správce tajemství (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). Token lze volitelně navázat na projekt a nasadit na stejné typy cílů jako tajemství, přičemž se znovupoužívají sdílené doručovací exekutory MazeVault: konfigurační soubor na serveru spravovaný agentem (JSON/YAML/ENV klíč→hodnota, s volitelným povoleným post-install příkazem), Kubernetes secret, secret v Azure Key Vault nebo secret v AWS Secrets Manager (zápis do Windows registrů / IIS je záměrně odložen). Ruční akce obnovit zaznamená nově získanou hodnotu a nové datum expirace, uzavře otevřený incident expirace a znovu nasadí cíle označené pro sync-při-obnově. Správa tokenů je záměrně oddělená od projektové Správy klíčů (projektová tajemství) i od System Keys v nastavení organizace (infrastrukturní klíče MazeVault) a nachází se pod novou navigační skupinou Enterprise Functions. Přístup řídí nová oprávnění token:read / token:write / token:delete / token:admin — nasazení a obnova vyžadují token:write (admin je implikuje), zobrazení uložené hodnoty tokenu vyžaduje token:admin. Funkce je plně spravovatelná přes nový Terraform resource mazevault_token a datový zdroj mazevault_tokens.
• Dopad na upgrade (Správa tokenů) — Přidává dvě idempotentní migrace: 000193_token_management (vytvoří tabulky managed_tokens a token_deployment_targets, naseeduje oprávnění token:* do stávajících rolí — org_admin plně; operator read/write/delete; user a auditor pouze read) a 000194_token_target_types (zobecní token_deployment_targets o target_type / integration_id / config, takže doručení tokenu znovupoužívá sdílené exekutory secret/certifikátů). Nepřidávají se žádné nové proměnné prostředí, hodnoty Helm ani změny formátu release balíčku — funkce znovupoužívá stávající infrastrukturu šifrování, offloadu tajemství, notifikací/incidentů, doručovacích rotačních kroků a licencování. Kontrola zdraví databáze nyní ověřuje obě nové tabulky. Terraform provider získává aditivní resource mazevault_token a datový zdroj mazevault_tokens; žádný stávající resource, datový zdroj, API endpoint ani kontrakt Go SDK se nemění ani neodebírá. Endpointy jsou chráněné feature token_management (PoC a Enterprise); bez ní API /api/v1/tokens vrací HTTP 403 a UI zobrazí upgrade banner.

Vylepšení

• Admin dávkové řešení na dedikovaných stránkách problémů rotace a synchronizace — Systémový administrátor nyní může vybrat jednotlivé řádky nebo všechny aktuálně viditelné řádky na stránce Rotation Problems a v každé sekci stránky Synchronization Problems. Frontend záměrně opakuje existující auditované single-item akce s nejvýše třemi souběžnými požadavky, zobrazuje průběh i částečná selhání a po dokončení znovu načte dotčené seznamy; nevzniká žádná neauditovaná bulk mutační cesta. Selhání rotace se acknowledgeují a dostupný navázaný otevřený incident se uzavře. Sync failures a blocked-seed incidenty se acknowledgeují ve vlastních sekcích, zatímco pending sync konflikty lze dávkově pouze ignorovat, což změní lokální stav konfliktu bez zápisu kterékoli hodnoty do externího provideru. „Vše viditelné“ je záměrně omezené aktuální stránkou a každé potvrzení uvádí přesný počet dotčených položek. Jednotlivé remediation akce zůstávají dostupné neadmin operátorům se stávajícími write oprávněními; dávkové ovládání vidí pouze systémový administrátor.
• HSM/KMS backend HashiCorp Vault Transit — mazevault_hsm_device nyní podporuje provider_type = hashicorp_vault postavený na engine HashiCorp Vault Transit. Dříve validace hodnotu přijala, ale instanciace selhávala s unsupported HSM provider: hashicorp_vault, protože implementace neexistovala. Klíče Vault Transit generuje a drží Vault (RSA-2048/3072/4096, ECDSA P-256/P-384/P-521); podpis probíhá vzdáleně přes endpoint Transit sign, takže privátní klíčový materiál nikdy neopustí Vault. Implementován je test připojení zařízení, výpis klíčů, získání veřejného klíče, vzdálený podpis (používaný podpisem interní CA a dalšími operacemi směrovanými přes HSM) i mazání klíčů. Konfigurace přijímá vault_url, token a volitelný mount_path (výchozí transit). Wrapping klíč-šifrujícího-klíče (KEK) i nadále obsluhuje samostatné systémové HSM rozhraní a je mimo rozsah tohoto provideru.
• Certifikátové šablony přizpůsobené providerovi pro externí komerční CA — Formulář certifikátové šablony se nyní přizpůsobuje schopnostem providera vybraného vydávajícího CA účtu, místo jednoho pevného sadu polí pro každou autoritu. Každá externí CA má jiné API a model vydávání, takže formulář řídí schopnosti deklarované providerem (vystavené na GET /ca-providers/{type}/schema): provideri s produktovým katalogem (SSLMarket, DigiCert) nabízejí certifikátový produkt jako dropdown ze synchronizovaného katalogu CA — typ certifikátu se odvodí z vybraného produktu a volné pole external template OID se skryje; provideri vyžadující doménovou validaci nabízejí na šabloně metodu doménové validace (email / dns / file), uloženou jako dcv_method (migrace 000191); ACME issuery dál zobrazují ACME challenge policy; interní CA ani jedno. SSLMarket provider nyní odvozuje product_code z navázaného CA produktu šablony (s fallbackem na volný kód a poté výchozí hodnotu účtu) a respektuje per-template metodu validace; DigiCert rovněž preferuje per-template metodu. Nový volitelný argument dcv_method je dostupný na Terraform resource mazevault_certificate_template. Stávající šablony nejsou dotčené: nový sloupec je nullable a prázdná hodnota znamená „použij výchozí providera/účtu".

Opravy chyb

• Terraformem spravované tokeny mají platný a state-safe životní cyklus — Resource mazevault_token používal rezervované root jméno atributu provider, kvůli čemuž Terraform validace schématu resource odmítla. Štítek je nyní dostupný jako token_provider a verzovaný state upgrader zachová hodnoty existujícího stavu. Čtení a mazání tokenů nyní považuje HTTP 404 za nepřítomný resource, ale zachová stav při chybě autorizace, transportu nebo serveru. Prázdná odpověď description / project_id už nenechá ve stavu starou neprázdnou hodnotu. Nové tokeny mohou použít Terraform 1.11+ value_wo s value_wo_version, takže plaintext není v plánu ani stavu; legacy value zůstává podporované, ale je výslovně dokumentované jako stateful. Import nyní podporuje správu pouze metadat. Migrace existujícího resource z value na value_wo není automatická, protože replacement změní ID tokenu a kaskádově smaže jeho deployment cíle.
• Rotation Failure Triage zobrazuje skutečný počet otevřených problémů a průběžnou frontu deseti položek — Widget Overview dříve zobrazoval počet incidentů ve výchozí dvacetipoložkové stránce API jako celkovou hodnotu, takže tenant s více než 20 otevřenými selháními rotace vždy viděl nesprávný počet. Widget nyní používá autoritativní total z existující paginované odpovědi incidentů, pro zobrazení načítá pouze deset nejnovějších nevyřešených rotation-failure incidentů a po každém jednotlivém uzavření znovu načte první stránku, takže se fronta okamžitě doplní dalším nevyřešeným incidentem. Zavádějící page-local badge High/Critical byl odstraněn. Overview záměrně zůstává povrchem pro jednotlivé řešení bez výběru nebo dávkového uzavření.
• Metrika „Missing in PROD“ na Secrets Dashboardu nyní správně odráží cross-environment paritu — KPI dlaždice na Secrets Dashboardu dříve označená Missing in PROD ve skutečnosti nikdy nekontrolovala produkční prostředí ani organizační nastavení is_production. Počítá secret klíče, které existují alespoň v jednom aktivním (porovnávaném) prostředí, ale chybí v jiném aktivním prostředí — jde o signál cross-environment parity, který vyžaduje aspoň dvě aktivní prostředí. Na instancích bez produkčního prostředí (například testovací tenant pouze s development, integration, migration a testing) to vedlo k matoucí nenulové hodnotě „Missing in PROD“. Dlaždice je nyní označená Missing (Cross-Env) jak v přehledu Secrets Dashboardu, tak v pohledu Reports, čímž odpovídá tabulce Missing Secrets (Cross-Environment) pod ní. Podkladový cross-environment výpočet zůstává beze změny — opraveno bylo pouze zavádějící pojmenování a popisek.
• Události custody klíčů v Orchestrator Mode se spolehlivě ukládají — V Orchestrator Mode se při offloadu privátního klíče (například certifikátového klíče odeslaného do Azure Key Vaultu) zaznamenávala custody audit událost, jejíž hodnota metadata byla prázdný řetězec. Protože key_custody_events.metadata je sloupec typu PostgreSQL JSONB, insert selhal s invalid input syntax for type json (SQLSTATE 22P02) a custody záznam se ztratil — pouze se zalogovalo varování — přestože samotný offload klíče proběhl úspěšně. Custody události nyní vždy ukládají syntakticky validní JSON: nenastavená nebo prázdná hodnota metadata se na hranici zápisu normalizuje na prázdný JSON objekt ({}), takže každý offload, načtení i smazání klíče vytvoří trvalý custody audit záznam. Volající, kteří už předávají strukturovaná metadata, nejsou dotčeni. Health check databáze nově validuje i sloupce key_custody_events.
• Vydávání certifikátů přes SSLMarket opraveno na reálné SSLmarket API — Vydání certifikátu přes SSLMarket CA účet selhávalo s API request failed with status 400: {"error":["No route found"]} na standardních i Orchestrator Mode instancích. SSLMarket provider byl implementovaný proti REST tvaru, který neodpovídá zveřejněnému SSLmarket API. Provider nyní cílí na skutečné endpointy a payloady: objednávky se odesílají na POST /order/certificate/{product_code} s plochým tělem objednávky (doména, SANs, roky, CSR, povinné dv_auth_method a pole owner/authorized-contact/technical-contact/invoice, která se při nekonfigurování doplní z defaultů SSLmarket účtu); detail objednávky, stažení certifikátu (podle order id a formátu), tokeny doménové validace (DCV) a revokace nyní používají správné cesty; resolvování produktu čte reálný katalog {"products":[…]}; a odpovědi se parsují podle skutečných JSON tvarů API (stringové identifikátory, pole dns_names a stavy objednávky paid/requested). Autentizace (X-Auth-Token) a base URL byly už dříve správné a zůstávají beze změny. Vydávání certifikátů i asynchronní poller objednávek externí CA nyní proti SSLMarketu doběhnou.
• Audit události push secretů (Orchestrator a Sync) už neselhávají na porušení cizího klíče — V Orchestrator Mode se při pushi secretu do externího provideru (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) zaznamenávala audit událost SECRET_PUSH_CREATE / SECRET_PUSH_UPDATE, jejíž user_id bylo omylem nastaveno na ID projektu místo uživatele. Protože audit_events.user_id má cizí klíč na users(id), insert selhal s violates foreign key constraint "audit_events_user_id_fkey" (SQLSTATE 23503) a audit záznam se ztratil, přestože samotný externí push proběhl úspěšně — externí secret se tak rozešel s auditní stopou. Audit události push secretů i sync-seedu se nyní přiřazují iniciujícímu uživateli (a u systémem iniciovaných synchronizací vyřešenému systémovému aktérovi), takže se ukládají správně. Jako obrana do hloubky nově zapisovač auditu garantuje i trvanlivost: pokud by se jakákoli audit událost nepodařila uložit kvůli chybné referenci aktéra, je jednou zopakována s prázdným (nepřiřaditelným) aktérem místo zahození; a jen pokud je databáze zcela nedostupná, je celá událost vyemitována do centrálního strukturovaného logu jako poslední záchrana. Původní lokální soubor emergency logu (/var/log/mazevault/emergency_audit.log), nepoužitelný na read-only souborových systémech kontejnerů v Kubernetes, byl odstraněn. Nová metrika mazevault_audit_persist_failures_total umožňuje alertování jakékoli takové poslední záchrany.
• Merkle integritní cache nyní sleduje změny secretů — Inkrementální Merkle integritní cache znala pouze slovník událostí certifikátů/keytabů (create / update / delete) a tiše ignorovala události secret služby v minulém čase (created / updated / deleted), logovala merkle cache updater: unknown event type a nechávala integritní cache secretů po každé změně zastaralou. Aktualizátor cache nyní přijímá obě formy, takže operace create/update/delete nad secrety správně aktualizují Merkle integritní strom.
• Zálohy rotace jsou nyní šifrované a podporují automatický rollback — Rotační orchestrátor byl spouštěn bez zapojeného encryptoru, takže pre-rotační zálohy degradovaly na neobnovitelné odkazy na verzi a logovaly rotation backup requested but encryptor not configured — rollback will be limited. Automatický rollback selhané rotace tak nebyl k dispozici. Orchestrátor nyní při startu dostává systémový encryptor, takže se pre-rotační stav ukládá jako šifrovaná záloha a automatický rollback je obnoven. Zálohy externích names_only secretů se i nadále spoléhají na vlastní historii verzí externího provideru, stejně jako dříve.
• Entra ID integrace přijímají workload-identity (AKS) pro background autentizaci — Konfigurace Entra ID integrace (používané pro rotaci secretů app registrací a synchronizaci Microsoft Graphu) s background_auth_method=workload_identity byla odmítnuta s unsupported background_auth_method, přestože Microsoft Graph klient i sdílená Azure credential factory federovanou workload identity na AKS už podporují. Tři samostatné validační brány — vytvoření/úprava integrace, test připojení a runtime kontrola konzistence používaná při rotaci — hodnotu ve výchozím stavu odmítaly, takže integraci nešlo vytvořit, nebo při vynucení selhala později při rotaci s configuration is inconsistent. Všechny tři brány nyní workload_identity přijímají; ta — stejně jako managed_identity — nevyžaduje v konfiguraci integrace žádné statické přihlašovací údaje: na workload-identity clusteru runtime provede federovanou výměnu tokenu pro nakonfigurované (nebo webhookem injektované) client ID managed identity. To odemyká rotaci Entra credentials na AKS workload-identity clusterech bez dedikované client-secret app registrace.
• Krok rotace Spring Actuator Refresh už nepadá na chybné konfiguraci — Post-rotační krok spring_actuator používal nekontrolované typové asertace na actuator_url a na položkách volitelného seznamu endpoints, takže špatný konfigurační klíč (například url místo actuator_url) nebo ne-stringová položka způsobily pád workeru místo srozumitelné chyby. Krok nyní vstup validuje defenzivně a vrací strukturovanou chybu, a refresh URL sestavuje bezpečně tak, aby základní URL, koncové lomítko nebo URL, které už končí na /actuator nebo /actuator/refresh, nikdy nevytvořilo zdvojenou cestu.
• Post-rotační doručení secretu do Key Vaultu a dalších cílů nyní dostane vyrotovanou hodnotu — Post-rotační doručovací akce (push do Azure Key Vaultu, AWS/GCP/OCI secret manager, DevOps proměnné) vyžadují čerstvě vyrotovanou hodnotu secretu, ale fáze post-rotačních akcí sestavovala kontext, který ji vynechával, takže doručovací akce logovala new_password not found in input context a zápis tiše přeskočila. Vyrotovaná hodnota se záměrně nikdy neukládá, proto se nyní řeší až v době provedení z právě aktualizovaného MazeVault secretu — shodně, ať akce běží na primary nebo je delegována na gateway (hodnotu si načte provádějící runtime a nikdy se nepřenáší v payloadu gateway úlohy). Doručení u rotací Entra credentials i nadále probíhá přes dedikované seedované doručovací workflow. Jako zpevnění se předchozí hodnota z Key Vaultu zachycená pro rollback nyní z uloženého záznamu post-akce redaguje, takže se do historie rotace nezapisuje žádný citlivý materiál.
• Azure Managed HSM / Key Vault HSM zařízení lze nyní otestovat a používat — Instanciace zařízení azure_managed_hsm (pro test připojení i pro jakékoli podepisování CA, offload klíčů, rotaci klíčů či šifrování secretů skrz něj směrované) selhávala s CredentialFactory is required for AzureKVProvider, protože HSM device služba vytvářela Azure provider bez credential factory. Azure credential factory je nyní do HSM device služby injektována a protažena do factory provideru, takže Azure Managed HSM zařízení se inicializují se skutečným Azure credentialem.
• Ruční synchronizace secret-manager integrace už neodmítá nekanonické hodnoty typu — Spuštění ruční synchronizace na secret-manager integraci mohlo selhat s sync not supported for integration type: secret-manager, pokud uložený typ integrace používal pomlčku místo kanonické formy s podtržítkem. Typy integrací se nyní při vytvoření kanonizují (malá písmena, ořez, pomlčky na podtržítka) a guard ruční synchronizace porovnává proti kanonické formě, takže secret-manager a secret_manager jsou brány shodně. Migrace 000192 normalizuje případné stávající nekanonické hodnoty project_integrations.type, aby exact-match kontroly (ruční sync, sync rules, key offload) zůstaly konzistentní.
• Pull/obousměrná sync pravidla vyžadují cílové prostředí předem — Vytvoření pull nebo obousměrného sync pravidla bez target_environment bylo přijato, ale později při provedení selhalo hluboko v kanonizéru prostředí s environment slug is empty. Vytvoření sync pravidla nyní vyžaduje a kanonizuje target_environment pro každé pravidlo, které není čistý push (push pravidla odvozují prostředí ze zdrojového secretu), a vrací srozumitelnou validační chybu místo matoucího runtime selhání.
• Vydávání ACME certifikátů nyní dokončí finalizaci (Let's Encrypt / ACME CA) — Report z v1.0.59 popisoval, že vydávání přes ACME projde validací dns-01, ale selže při finalize s chybou POST-as-GET requests must have an empty payload / must have a nil body; to bylo end-to-end reprodukováno proti lokálnímu Pebble serveru. Nalezeny a opraveny dva defekty. Zaprvé MazeVault odesílal CSR na URL objednávky (order.URI) místo na dedikovanou finalize URL objednávky (order.FinalizeURL); protože URL objednávky je read-only POST-as-GET zdroj, odeslání těla CSR tam CA odmítla. Zadruhé poté, co CSR dorazil na správný finalize endpoint, některé RFC 8555-kompatibilní servery (včetně Pebble) nevrací na finalize odpovědi hlavičku Location, takže interní post-finalize poll v ACME klientovi mířil na prázdnou URL a selhal, přestože CSR byl přijat; vydávání se nyní zotaví dotázáním známé URL objednávky a stažením vydaného certifikátu. End-to-end vydávání dns-01 přes finalize je ověřeno reprodukčním testem proti Pebble (build tag acme_pebble).
• Dopad upgradu — Verze 1.0.60 je oprava pojmenování a popisku bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. V endpointu přehledu secretů dashboardu (GET /api/v1/dashboard/secrets/overview) se pole odpovědi missing_in_prod přejmenovává na missing_cross_env. Jde o interní pole dashboardu, které konzumuje pouze frontend MazeVaultu; není součástí Go SDK ani Terraform provideru, takže žádný integrační kontrakt není dotčen. Logika cross-environment parity a výpis chybějících secretů zůstávají funkčně beze změny.
• Dopad upgradu (Orchestrator custody a SSLMarket) — Oprava ukládání custody klíčů v Orchestrator Mode a oprava SSLMarket provideru jsou pouze backendové změny bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. Pro vydávání přes SSLMarket musí integrace CA účtu nastavit správný product_code (SSLmarket účet může nabízet produkty — například trial certifikáty — které nevrací API katalog produktů, a proto se musí nakonfigurovat explicitně) a, pokud účet nemá výchozí firemní data, nastavení owner/contact/invoice vyžadovaná zvoleným produktem. dv_auth_method má při nekonfigurování výchozí hodnotu Email.
• Dopad upgradu (šablony přizpůsobené providerovi) — Funkce certifikátových šablon přizpůsobených providerovi přidává jeden nullable sloupec přes migraci 000191 (certificate_templates.dcv_method) a jedno runtime-počítané pole (template_form) v odpovědi GET /ca-providers/{type}/schema; obojí je aditivní a zpětně kompatibilní. Žádné environment proměnné, Helm values ani změny formátu release balíčku. Terraform resource mazevault_certificate_template získává volitelný argument dcv_method; stávající konfigurace fungují beze změny.
• Dopad upgradu (Audit, Merkle a rotace) — Oprava přiřazení aktéra u auditu push secretů, zpevnění trvanlivosti auditu, oprava Merkle integritní cache a oprava šifrování záloh rotace jsou pouze backendové změny spolehlivosti bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. Přidává se jedna aditivní Prometheus metrika mazevault_audit_persist_failures_total; žádná stávající metrika, API endpoint, Go SDK ani kontrakt Terraform provideru se nemění. Lokální fallback /var/log/mazevault/emergency_audit.log byl odstraněn ve prospěch centrálního strukturovaného logu, takže poslední záchranný audit sink nyní funguje i na read-only souborových systémech kontejnerů.
• Dopad upgradu (Entra WI, doručení rotace, HSM a validace sync) — Tyto opravy přidávají jednu idempotentní datovou migraci 000192_canonicalize_integration_type, která normalizuje stávající hodnoty project_integrations.type na kanonickou formu s malými písmeny a podtržítky; je pouze datová a zpětně kompatibilní. Žádné nové environment proměnné, Helm values ani změny formátu release balíčku. background_auth_method=workload_identity je nyní přijímaná hodnota pro Entra integrace (včetně API povrchu mazevault_integration) a pull/obousměrná sync pravidla nyní vyžadují target_environment při vytvoření. Žádný stávající API endpoint, Go SDK ani kontrakt Terraform provideru se neodstraňuje ani nepřejmenovává.
• Dopad upgradu (Vault HSM a ACME finalize) — HashiCorp Vault Transit HSM provider a oprava ACME finalize jsou pouze backendové bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. Provider hashicorp_vault pro HSM zařízení je aditivní; žádná stávající konfigurace HSM zařízení se nemění. Oprava ACME finalize opravuje pouze tok vydávání certifikátů; žádný API endpoint, Go SDK ani schéma Terraform provideru se nepřidává, neodstraňuje ani nepřejmenovává. Reprodukční test proti Pebble je za build tagem acme_pebble a v běžném CI neběží.
• Dopad upgradu (UX řešení problémů) — Pravdivý počet v Rotation Failure Triage a administrátorské dávkové workflow jsou pouze frontendové změny. Znovupoužívají existující metadata paginace incidentů a stávající single-item mutační endpointy, oprávnění i auditní události. Nejsou potřeba žádné databázové migrace, změny API nebo Swagger kontraktu, nová RBAC oprávnění, environment proměnné, Helm values, změny release balíčku, Go SDK ani Terraform provideru.

Bezpečnost a aktualizace závislostí

• Odstraněny Trivy CRITICAL/HIGH zranitelnosti závislostí napříč všemi moduly — Trivy filesystem sken v dev pipeline (CRITICAL,HIGH, --ignore-unfixed) selhával na opravených, ale zastaralých závislostech. Všechny dotčené balíčky byly povýšeny na opravené verze a ověřeny přes go build, go vet, unit testy modulů a govulncheck (0 dosažitelných zranitelností), plus build frontendu a kompletní Vitest sada:
  • Go — golang.org/x/text 0.37.0 → 0.39.0 (CVE-2026-56852 / GO-2026-5970, nekonečná smyčka v norm.Iter) v backend, cli, k8s-operator a terraform-provider-mazevault.
  • Go — google.golang.org/grpc 1.79.3 / 1.80.0 → 1.82.1 (GHSA-hrxh-6v49-42gf / GO-2026-6061, xDS RBAC a HTTP/2 transport) v backend a terraform-provider-mazevault.
  • Go — software.sslmate.com/src/go-pkcs12 0.7.0 → 0.7.2 (GO-2026-5052) v backend a agent; tuto dosažitelnou zranitelnost odhalil govulncheck, přestože ji Trivy kvůli severity filtru nehlásil.
  • Frontend — axios 1.16.0 → 1.19.0 (GHSA-gcfj-64vw-6mp9 a související advisories).
• React Router povýšen na v8 (major) — Frontend byl migrován z react-router-dom 7.17.0 na react-router 8.3.0, což řeší CVE-2026-55685 a GHSA-qwww-vcr4-c8h2. React Router v8 ruší samostatný balíček react-router-dom; všechny importy byly přesunuty na react-router (aplikace je deklarativní SPA používající BrowserRouter, takže vstupní bod react-router/dom není potřeba). react a react-dom byly zvednuty na minimum 19.2.7.
• Dopad upgradu (Bezpečnost a závislosti) — Jde pouze o změny závislostí a build-time: žádné databázové migrace, environment proměnné, Helm values ani změny formátu release balíčku a žádné změny kontraktu API, Go SDK nebo Terraform provideru. Build frontendu nyní vyžaduje Node ≥ 22.22 (deklarováno novým polem engines v frontend/package.json); CI joby frontendu i Docker image frontendu už běží na Node 24. Povýšení React Router na v8 je interní frontend migrace bez změny aplikačních rout nebo chování; kompletní sada frontend unit testů prochází beze změny.

---

Verze 1.0.59

Datum vydání: 2026-07-18

Vylepšení

• Pohledy rotace secretů se po dokončení na pozadí tiše aktualizují — Záložka Secrets nyní používá existující per-secret poller stavu rotace jako detektor události. Když rotace secretu na pozadí doběhne do koncového stavu, MazeVault načte pouze dotčený secret přes GET /api/v1/secrets/{id} a aktualizuje viditelné číslo verze bez reloadu celé tabulky secretů. Pokud je pro daný secret otevřený modal Version History nebo Rotation Configuration, modal si na místě znovu načte seznam verzí nebo historii exekucí. Nepřibývá žádný globální polling, toast, zvýraznění ani refresh celé stránky.
• Samostatné řízení přístupu pro řešení synchronizačních problémů — Synchronizační problémy nyní používají oddělenou permission hranici sync:read / sync:write místo implicitního navázání akčních tlačítek na project:write. Role project_admin, certificate_manager a secret_manager mohou synchronizační problémy aktivně řešit, zatímco auditor a běžní uživatelé zůstávají v read-only režimu. Navigace i stránka Synchronization Problems tak odpovídají skutečnému oprávnění uživatele.
• Akce pro sync failures a blocked seed incidenty jsou dostupné přímo z problémového pohledu — Globální stránka Synchronization Problems i projektová záložka sync konfliktů nově nabízí potvrzované akce pro retry, ignorování konfliktu, acknowledgement aktuálního sync failure fingerprintu a acknowledgement incidentu typu sync_seed_blocked. Badge v levé navigaci počítá souhrnný sync_problem_count, tedy konflikty, aktuální sync failures i blocked seed incidenty.
• Dismissals synchronizačních problémů škálují jedním dávkovým dotazem — Výpis sync failures nyní vyhodnocuje acknowledged fingerprinty aktuálních selhání jedním dávkovým dotazem místo samostatného lookupu pro každé selhané sync pravidlo. Zachovává se dosavadní fingerprint semantika podle pravidla, času a chyby i chování soft-delete, ale pohled Synchronization Problems zůstává svižný i při větším počtu selhaných pravidel.
• Export certifikátů spolehlivěji obsahuje issuer CA chain — Export certifikátu nyní normalizuje uložené certificate bundle a podle potřeby dohledá hierarchii vydávající interní CA přes parent CA záznamy. PEM/CRT a PKCS#7 exporty obsahují leaf certifikát následovaný issuer chainem, zatímco DER zůstává jako dříve leaf-only.
• Readiness obnovy certifikátů rozumí interním CA účtům — Eligibility obnovy, rotation preflight i metadata rotačních resources nyní resolveují interní organizační CA účty přes jejich podkladovou CertificateAuthority. Obnovy podepisované interní CA reportují CA účet i skutečnou signing CA, stejně jako runtime renewal cesta.
• Domain validation pro externí CA je viditelná a durable — Objednávky externích CA DigiCert a SSLMarket nyní zpřístupňují DCV instrukce přes zaregistrované endpointy renewal queue DCV a projektovou tabulku certifikátů. Certifikáty s čekajícím ověřením domény zobrazují akci View Domain Validation, která otevře existující DCV status panel, kde operátor vidí DNS/HTTP/email instrukce a může spustit provider re-check přímo z certificate workflow.
• Nové certificate requesty přes externí CA mohou čekat na validaci providera — Vydání přes externí CA už nepředpokládá, že SignCSR okamžitě vrátí PEM certifikát. Pokud provider vrátí jen order ID, MazeVault uloží pending certificate placeholder, propojí ho s requestem, založí durable submitted_to_ca queue item a nechá external CA order poller request dokončit, jakmile provider certifikát zpřístupní.
• CA account provider settings se persistují a dají spravovat Terraformem — Create/update/sync toky CA účtů nyní zachovávají ne-tajné provider settings jako DigiCert organization_id, server_platform_id, dcv_method, certificate_dcv_scope, vlastní base_url a SSLMarket defaulty v metadatech účtu. Terraform resource mazevault_ca_account přidává mapu settings pro tyto ne-tajné hodnoty a API klíče nebo ACME EAB materiál dál drží ve write-only credentials.
• Terraform secrety podporují write-only hodnoty pro ephemeral hesla — Resource mazevault_secret nyní podporuje value_wo a value_wo_version pro write-only vstupy v Terraform 1.11+. Operátoři mohou vytvořit heslo pomocí ephemeral Terraform resource, například ephemeral "random_password", a předat ho do MazeVaultu bez uložení plaintextu do Terraform plánu nebo stavu. value_wo_version je uložený trigger pro opětovné odeslání: navyšte ho, když má Terraform poslat novou write-only hodnotu. Starší argument value zůstává podporovaný pro existující konfigurace a server-side generate zůstává dostupný pro secrety generované MazeVaultem.
• API pro update secretu a Go SDK podporují metadata-only update — PUT /api/v1/secrets/{id} nyní bere value jako volitelné pole: vynechání aktualizuje pouze metadata a TTL, zatímco dodaná neprázdná hodnota dál vytváří novou verzi secretu. Go SDK zachovává stávající metodu UpdateSecret(id, value, ...) a přidává request-based update cestu, která umí value záměrně vynechat. Terraform provider ji používá pro životní cyklus write-only secretů.

Opravy chyb

• Synchronization Problems už nezůstávají bez akčních ikon pro oprávněné role — Uživatelé, kteří mohli problémy vidět přes sync:read, dříve často neměli žádnou možnost je vyřešit, protože mutace byly svázané s project:write. Nové endpointy pro acknowledge sync failure a blocked seed incidentu jsou chráněné sync:write, auditované a záměrně omezené jen na synchronizační problémový povrch.
• Ignorování sync konfliktu už nevyžaduje zápis do externího provideru — Resolution ignore nyní pouze uzavře lokální sync_conflicts řádek stavem ignored a nezapisuje do cílového secret manageru. To umožňuje trvale odložit známý konflikt bez rizika nechtěné změny externí hodnoty.
• Acknowledgement sync failure je stabilní jen pro aktuální selhání — Sync failures odvozené ze sync_rules.last_sync_status se ukládají jako dismissal podle fingerprintu složeného z pravidla, času posledního syncu a chyby. Pokud další běh selže jinak, problém se znovu zobrazí; acknowledgment tedy nezakrývá nové nebo změněné selhání.
• Editace konfigurace rotace už neukazuje falešné varování o částečném načtení — Modal konfigurace rotace secretu nyní adresuje historii rotací a readiness přes kanonické ID rotačního resource (rotation_configs.id / resource.resource_id) místo ID secretu. Tím se opravuje zavádějící hláška „Some rotation sections could not be loaded. Available data is shown." při otevření Secrets → Rotations → Edit pro nakonfigurovaný secret.
• Rollback verze secretu spolehlivě funguje nad existující historií verzí — Rollback secretu nyní ukládá archivované řádky historie s vygenerovaným primárním klíčem, zachovává původní čas verze místo času archivace a metadata rollbacku aktualizuje přes modelovou serializační cestu. Frontend navíc zobrazuje backend message / error detail jako error notifikaci místo obecné odpovědi „Rollback Failed".
• Legacy řádky historie secretů s chybějícím UUID jsou opraveny — Migrace 000189_fix_secret_version_null_uuid doplňuje validní UUID do legacy řádků secret_versions, které měly chybějící nebo nulové ID, a model SecretVersion nyní před vložením vygeneruje ID, pokud chybí. Tím se předchází kolizím primárního klíče a selháním rollbacku v prostředích, která už dotčené historické řádky obsahují.
• Manuální rotace secretu už ve stagingu nevytváří duplicitní lokální verze — Krok pre_rotation_sync nyní před lokálním zápisem porovnává externí hodnotu s aktuální hodnotou secretu. Pokud jsou hodnoty shodné, krok hodnotu uloží jen jako kontext pro další kroky rotace a nezvýší verzi secretu. Tím se odstraňuje staging symptom, kdy jedna manuální rotace vytvořila dvě nové verze a matoucí mezilehlou systémovou verzi.
• Historie verzí nyní zobrazuje správného autora u aktuální verze — Řádek aktuální (aktivní) verze v modalu Version History zobrazoval původního autora secretu místo aktéra, který secret naposledy změnil. Servisní vrstva nyní odvozuje autora aktuální verze z nejnovějšího archivovaného záznamu historie, který nese aktéra poslední změny — stejně jako všechny ostatní historické řádky. Automatické rotace spuštěné schedulerem se nadále zobrazují jako System; manuální triggery ukazují uživatele, který rotaci inicioval.
• Pole certificate chain už neduplikují leaf certifikát — Issuance, import, renewal, ACME completion i dokončení objednávek u externích CA nyní normalizují certificate PEM data na hranici zápisu. CertificatePEM zůstává aktuální certifikát, ChainPEM ukládá pouze issuer certifikáty a PublicChainPEM ukládá celý bundle leaf-plus-chain. Existující kontaminovaná chain data se při exportu defenzivně normalizují.
• ACME issuance ukládá leaf a chain odděleně — ACME issuance nyní rozděluje certifikáty vrácené objednávkou na leaf-only certificate data a normalizovaný issuer chain. Tím se zabrání tomu, aby se plný ACME bundle ukládal dvakrát nebo byl interpretován současně jako aktuální certifikát i chain.
• ACME bridge finalizace validuje CSR identifikátory a persistuje async ADCS certifikáty — MazeVault ACME server nyní odmítá finalize CSR, jehož DNS/IP identifikátory nejsou součástí ACME objednávky, konzistentně používá RFC 8555 certificate URL path a vytvoří sledovaný Certificate záznam, když ADCS-backed ACME objednávka doběhne po schválení CA managerem.
• External CA polling správně řeší DCV, pending objednávky i stahování certifikátů — External CA order poller nyní počítá jako dokončenou práci pouze skutečně vyřešené objednávky, fetchuje a ukládá DCV tokeny, když provider vyžaduje validaci, stahuje certificate bundle pro DigiCert a SSLMarket před finalizací a request-originated objednávky dokončuje atomicky napříč záznamy certifikátu, queue, requestu a přiřazení agenta.
• DCV retry už předčasně neresumuje expirované challenge — Operátorský DCV retry před znovunačtením provider instrukcí resetuje expirované nebo stale challenge, bezpečně funguje i bez audit service v testovacím/background kontextu a nechá queue item ve stavu pending_dcv, pokud stále existují expirované tokeny, místo aby nesprávně pokračoval ke stažení certifikátu.
• ADCS DCOM odpovědi přijímají numerické i textové stavy — Backend DCOM parser nyní přijímá legacy numerické ADCS disposition kódy i agent odpovědi jako pending, issued nebo denied, takže zachovává dosavadní chování a zároveň umožňuje bezpečně sjednotit agent/backend kontrakt.
• Obnovené certifikáty zachovávají podkladovou interní signing CA — Renewaly přes interní organizační CA účet nyní zachovávají ID podkladové CertificateAuthority na obnoveném certifikátu a zároveň dál podepisují přes nakonfigurovaný CA account provider. Renewaly přes externí CA účty interní CA pole nadále nevyplňují.
• Audit approval continuation obsahuje rotační kontext — Automatické pokračování rotace po approval nyní zapisuje audit události s projektem rotačního intentu a iniciátorem, pokud je dostupný. Zlepšuje to dohledatelnost bez změny idempotence continuation toku nebo vynucení approval.
• Inference HSM algoritmu u interní CA je krytá regresními testy — Interní CA HSM signer nyní používá čistší type switch pro inference RSA, RSA-PSS a ECDSA algoritmů a testy pokrývají očekávané JWA mapování.
• Terraform update write-only secretů už při změně metadat znovu neposílá ani nerotuje hodnotu — Metadata nebo TTL update Terraformem spravovaného mazevault_secret, který používá value_wo, nyní volá backend bez plaintext hodnoty, pokud se nezmění value_wo_version. MazeVault proto při metadata-only apply zachová existující secret material, historii verzí, offload stav, stav externího provideru i propagaci. Explicitně prázdné hodnoty secretu jsou odmítnuty místo toho, aby se zaměnily za vynechané hodnoty.
• Terraform CA account provider typy se validují konzistentně — Terraform resource mazevault_ca_account nyní odmítá prázdné, whitespace-only, mixed-case a nepodporované hodnoty provider_type ještě před voláním backend API. Akceptované kanonické hodnoty jsou sladěné s backend CA account resolvery, které se umí skutečně připojit, včetně internal, SSLMarket aliasu rapidssl a venafi; placeholder integrace I.CA/PostSignum a PSD2 zůstávají vyřazené, dokud backend nezačne hlásit connectable stav. Venafi account-backed provider resolution je nově zapojený v obou servisních cestách CA účtů, takže dokumentované Venafi CA účty už neselhávají v organization CA-account resolveru. Stávající dokumentované konfigurace s lowercase hodnotami fungují beze změny.

Poznámky k migraci

• Migrace 000189_fix_secret_version_null_uuid opravuje neplatné hodnoty secret_versions.id tak, že chybějící nebo nulové UUID nahradí nově vygenerovanými UUID. Jde pouze o opravu dat a nemění veřejné API kontrakty.
• Migrace 000190_sync_problem_actions přidává permission sync:write do oprávněných systémových rolí a vytváří tabulku sync_problem_dismissals pro trvalé acknowledgement aktuálních sync failure fingerprintů. Migrace je idempotentní a nemění konfigurační schéma ani environment proměnné.

Poznámky

• Dopad upgradu — Verze 1.0.59 obsahuje dvě databázové migrace: 000189_fix_secret_version_null_uuid pro opravu legacy UUID v historii verzí secretů a 000190_sync_problem_actions pro sync remediation oprávnění a per-fingerprint dismissal tabulku. Přibývají sync-specific API endpointy pro acknowledgement aktuálních sync failures a blocked seed incidentů; nevyžadují nové environment proměnné ani změny formátu release balíčku. Terraform write-only hodnoty secretů vyžadují Terraform 1.11+, pokud se value_wo používá s ephemeral vstupy; existující konfigurace s value a generate fungují dál. Update secretu nyní přijímá metadata/TTL-only požadavky bez vytvoření nové verze, což je rozšíření kompatibility API. Refresh pohledů rotace secretů je frontend-only změna a oprava zobrazení autora v historii verzí je backend servisní změna bez konfiguračního dopadu. Změny certificate chainu, exportu, ACME, external CA DCV, async issuance nových requestů, CA account settings, renewalu, auditu approval continuation, HSM, SDK a Terraform provideru nepřidávají žádné další migrace, environment proměnné, Helm values ani změnu formátu release balíčku. Terraform validace CA account provider typů nyní odmítá neplatné hodnoty dříve; dokumentované lowercase konfigurace provider_type fungují dál. CertificateRequest.status může nově vracet submitted_to_ca, pokud request přes externí CA čeká na DCV/provider issuance, a nové renewal queue DCV endpointy používají existující certificate RBAC permissions.

---

Verze 1.0.58

Datum vydání: 2026-07-16

Nové funkce

• ACME challenge policy na šablonách certifikátů — Šablony certifikátů nyní obsahují pole challenge_type (auto, dns-01, http-01, tls-alpn-01, výchozí auto), které řídí způsob ACME validace, pokud je vydávající CA účet ACME provider (Let's Encrypt, ZeroSSL, vlastní ACME). Politika se vynucuje při vydávání: dns-01 vyžaduje nakonfigurovaný DNS solver a bez něj rychle selže, http-01 odmítne wildcard identifikátory (které ACME přes HTTP neumí ověřit) a tls-alpn-01 vrací jasnou chybu „nepodporováno“ místo tichého fallbacku. auto zachovává původní chování (wildcard → DNS-01 při dostupném solveru, jinak HTTP-01). Pole je dostupné v průvodci certifikátů v Project Templates, v detailu šablony a přes Terraform provider (mazevault_certificate_template.challenge_type). U neACME vydavatelů (interní CA, DigiCert, ADCS, …) se ignoruje.
• ACME atributy v Terraform provideru — Resource mazevault_ca_account nyní podporuje ACME pole email, directory_url, eab_kid a eab_hmac_key (HMAC klíč je označen jako citlivý/write-only). Mapují se do šifrovaného úložiště credentials na backendu a umožňují Terraformem spravované účty Let's Encrypt, ZeroSSL a vlastní/EAB ACME. Stávající atributy api_key/base_url zůstávají pro API-style providery. Provider nyní posílá backend-kompatibilní kontrakt credentials/display_name místo dřívějšího generického config, a write-only credentials se při čtení zachovávají (žádný falešný drift).

Vylepšení

• Jedna interní CA — ucelený životní cyklus a správa — Interní certifikační autorita organizace se nyní spravuje jako jediný prvotřídní objekt v Organization Settings → Project Settings → Certificate Authorities → Internal Certificate Authority. Nové endpointy interní CA vyhledají, inicializují a opraví (GET/POST /organizations/{id}/internal-ca, POST /organizations/{id}/ca-accounts/{accountId}/initialize-ca) a vytvoření druhého interního rootu je odmítnuto (guard jedné CA). UI nabízí akci Initialize Internal CA (common name, velikost klíče, platnost) a opravnou akci Initialize CA pro interní účty dříve vytvořené bez klíčového materiálu. OCSP/CRL URL jsou editovatelné a regenerace CRL je dostupná přímo z karty interní CA. Agenti nadále beze změny distribuují certifikát CA do trust store serverů.
• „Add CA Account“ je nyní pouze pro externí CA — Tok Add CA Account už nenabízí volbu Internal (která dříve vytvořila nefunkční „prázdný“ účet bez klíčového materiálu). Správa interní CA je výhradně v sekci Internal Certificate Authority. Interní CA je vyfiltrována z karet externích CA účtů, aby se nezobrazovala dvakrát, přičemž zůstává plně vybíratelná všude jinde (projektové integrace, vazba CA v šablonách, ACME/EAB dialogy).
• Striktní enforcement renewal: Template + CA povinný — Pipeline pro obnovu certifikátů nyní vyžaduje, aby každý certifikát měl přiřazený TemplateID a aby přiřazená šablona měla nastavený CAAccountID. Certifikáty bez šablony nebo se šablonou bez CA účtu jsou odmítnuty s jasnou chybovou zprávou na vstupu do pipeline. Toto odstraňuje předchozí víceúrovňový fallback řetězec pro vyhledání CA (cert-level CA, project overrides, výchozí internal CA) a stanovuje template.CAAccountID jako jediný zdroj pravdy pro výběr CA při obnově.

Opravy chyb

• Interní CA se už nehlásí jako „nenalezena“, když existuje — Záložka Certificate Authorities dříve pro zobrazení interních CA procházela CA vázané na projekty, takže org-level interní CA (bez vazby na projekt) byla neviditelná a sekce vždy ukazovala „No internal CAs found“. Sekce nyní vyhledá interní CA přes vazbu interního CA účtu organizace a správně ji zobrazí včetně OCSP/CRL konfigurace.
• OCSP/CRL konfigurace se ukládá i pro org-level interní CA — Editace OCSP/CRL URL interní CA nyní používá endpoint na úrovni CA (PUT /ca/{id}) místo project-scoped cesty, která neuměla adresovat org-level CA (project_id = NULL). OCSP zůstává záměrně jen pro interní CA — externí CA (DigiCert, Let's Encrypt, ZeroSSL) nadále inzerují vlastní OCSP/CRL respondery přes vložené AIA/CDP ukazatele.
• Dopad na integrace při mazání nyní ignoruje soft-deleted secrety — Raw SQL agregace za affectedSecretCount a collectOrphanedSecretIDs filtrovaly pouze archived_at IS NULL a ignorovaly GORM soft-delete (deleted_at). To mohlo nafouknout hlášený počet „celkem dotčených“ / osiřelých secretů oproti všem ostatním cestám, které se na secrets dotazují přes GORM (a deleted_at IS NULL doplní automaticky). Oba raw dotazy nyní filtrují i deleted_at IS NULL, čímž se obnovuje jednotná a konzistentní množina secretů napříč výsledkem mazání, endpointem dopadu mazání, audit logem i rozpadem podle prostředí.
• Rotace odloženého secretu už nehlásí refresh, který neproběhl — markDelayedSecretReauthorizing nastavoval v metadatech exekuce refresh_performed=true ještě před samotným voláním re-autorizace, takže pád nebo chyba před AuthorizeRotationConfigPublish uložily zavádějící refresh_performed=true, i když žádný refresh neproběhl. Placeholder nyní zapisuje refresh_performed=false; příznak se nastaví na true pouze na úspěšné cestě re-autorizace. Sémantika „nanejvýš jednou“ zůstává beze změny — loop guard se opírá o refresh_attempted + refresh_generation.

Odstranění

• ProjectCAOverride odstraněn — Tabulka project_ca_overrides a veškerý přidružený kód (model, handlery, servisní metoda findProjectCAOverride) byly odstraněny. Tato funkce nebyla nikdy zpřístupněna přes API router (routes nebyly registrovány) a tabulka byla v produkci vždy prázdná. Renewal orchestrator nyní vyhledává CA výhradně ze šablony. Migrace 000188 odstraňuje tabulku.
• buildTemplateFromCert odstraněn — Syntetický fallback pro certifikáty bez šablony byl odstraněn. Certifikáty musí mít přiřazenou řádnou šablonu, než je lze obnovit.

Údržba

• Odstraněno mrtvé PKI UI — Tři osiřelé, nedosažitelné frontend komponenty byly smazány po ověření, že nedojde ke ztrátě funkce: CAManagementTab (jeho funkce Initialize CA / HSM / CRL nahrazuje sekce Internal Certificate Authority) a CertificateTemplatesTab + CertificateTemplateModal (nahrazeno variable-driven tokem certifikátů v Project Templates, který pokrývá subject DN a SAN přes proměnné šablony). Živý CertificateTemplateViewModal (používaný záložkou Templates v projektu) je zachován.
• Opraven komentář v hlavičce migrace 000188 — Komentář v hlavičce 000188_drop_project_ca_overrides.up.sql chybně odkazoval na „Migration 000187“; nyní správně uvádí „000188“. Bez funkční změny.

Poznámky k migraci

• Migrace 000188_drop_project_ca_overrides odstraňuje tabulku project_ca_overrides. Jedná se o nedestruktivní změnu, protože tabulka nikdy nebyla naplněna aplikací (API routes nebyly nikdy zaregistrovány).
• Certifikáty bez TemplateID, které se dříve spoléhaly na fallback na interní CA, budou nyní v dashboardu rotací vykazovat stav „no template assigned" a nemohou se automaticky obnovovat, dokud jim nebude přiřazena šablona.

Poznámky

• Dopad upgradu — Verze 1.0.58 přidává dvě databázové migrace: 000182_add_challenge_type_to_certificate_templates (přidává do certificate_templates sloupec challenge_type VARCHAR(20) DEFAULT 'auto' s CHECK omezením) a 000188_drop_project_ca_overrides (odstraňuje vždy prázdnou tabulku project_ca_overrides). Obě migrace jsou idempotentní a zpětně kompatibilní; existující šablony defaultují na auto a stávající chování ACME vydávání se nemění. Žádné změny konfiguračního schématu.
• Terraform provider — Stávající konfigurace mazevault_ca_account fungují dál; nové ACME atributy jsou volitelné. mazevault_certificate_template získává volitelný atribut challenge_type s výchozí hodnotou. Interní CA se záměrně nespravuje přes Terraform — spravuje se v UI MazeVault.

---

Verze 1.0.57

Datum vydání: 2026-07-07

Opravy chyb

• Synchronizační kroky rotace (pre/post_rotation_sync) nyní používají managed identity místo zastaralých credentials z konfigurace — Když kroky pre_rotation_sync nebo post_rotation_sync orchestrátoru rotace rozpoznávaly Azure credentials přes getAzureCredentialFromConfig, funkce automaticky detekovala pole client_secret ze zašifrovaného konfiguračního blobu integrace, i když byla integrace nakonfigurována s background_auth_method=managed_identity. To způsobovalo chyby AADSTS7000215 (neplatný client secret) během synchronizačních kroků rotace, zatímco identické připojení ke Key Vaultu úspěšně procházelo během nesouvisejících synchronizačních cest. Credential helper nyní preferuje systémovou managed identity, pokud je auth_method prázdný a systém má nakonfigurovanou MI, čímž zabraňuje zachycení zastaralých SSO app credentials. Navíc vrstva delegování přes gateway již neblokuje delegaci pouze kvůli přítomnosti managed identity a delegované synchronizační kroky nyní nesou snapshot secret_metadata, takže gateway-prováděné synchronizační kroky mohou rozpoznat cílový klíč secretu bez nutnosti přímého databázového dotazu.
• Delegování přes gateway již není blokováno přítomností managed identity — canDelegateEnvironment() dříve bezpodmínečně vracelo false, pokud credential factory hlásila dostupnost managed identity, čímž bránilo jakémukoliv delegování synchronizace Azure KV na gateway v prostředích s nakonfigurovanou MI. Tato brána byla odstraněna; delegování přes gateway nyní závisí výhradně na párování prostředí a dostupnosti gateway, což umožňuje správné delegování synchronizačních operací autentizovaných přes MI.
• Rotace v orchestrator mode již neprovádí duplicitní zápis do Key Vault — V orchestrator mode (storage_mode=names_only) krok mazevault_secret dříve volal SecretService.Update, který interně posílal novou hodnotu do externího trezoru přes PushSecretToEnvironment. Protože post_rotation_sync zasílá tutéž hodnotu do trezoru také, každá rotace produkovala nadbytečný duplicitní zápis. Krok nyní v orchestrator mode volá pouze BumpVersion() (lokální inkrementace čítače verze) a jedinou externí zápis přenechává kroku post_rotation_sync.
• Compensate kroku mazevault_secret v orchestrator mode již neselhává na prázdném EncryptedValue — Když rotační sága prováděla rollback kroku mazevault_secret v orchestrator mode, Compensate() se pokoušel dešifrovat EncryptedValue předchozí verze, které je pro secrety names_only vždy NULL/prázdné. To způsobovalo falešné stavy „partially_rolled_back". Cesta kompenzace nyní pro orchestrator-mode secrety ihned vrací nil — rollback hodnoty v externím trezoru zajišťuje PostRotationSyncStep.Compensate, který má per-integration snapshot před přepsáním.
• Pre-rotation sync již v orchestrator mode neprovádí zbytečný round-trip hodnoty zpět do Key Vault — Když pre_rotation_sync detekoval novější hodnotu v Azure Key Vault, volal UpdateSecret, který v orchestrator mode posílal tutéž hodnotu rovnou zpět do trezoru (redundantní síťové volání). V orchestrator mode krok nyní zachytí hodnotu z KV jako kontext previous_value pro následující kroky bez spouštění zápisu do lokální DB nebo externího pushe.
• Discovery report agenta tiše nezapisoval aktualizaci metadat — ProcessDiscoveryReport() ukládal nalezené certifikáty do databáze, ale nikdy neaktualizoval metadata samotného agenta (last_discovery_at, discovered_certificates_count). Po úspěšném discovery běhu zůstal řádek agenta zastaralý, takže operátoři nemohli z dashboardu zjistit, zda agent kdy provedl discovery ani kolik certifikátů nalezl. Transakce nyní končí atomickým count dotazem a aktualizací řádku agenta, takže statistiky na dashboardu odrážejí realitu ihned po každém reportu.
• Verze agenta se neukládala z health heartbeatu — UpdateHealth() ukládal celý health payload do JSONB sloupce health_status a obnovoval last_seen, ale nikdy neextrahoval řetězec agent_version do jeho dedikovaného sloupce. Agenti hlásící svou verzi přes heartbeat se v UI zobrazovali jako verze-neznámá. Handler nyní kopíruje agent_version z health mapy do modelu agenta před uložením.
• Prázdný dropdown prostředí v dialogu Bind Agent — Dialog „Bind Agent" na záložce Project Integrations načítal data prostředí z GET /projects/:id/environment-settings (který vrací ProjectEnvironmentSetting[] s polem environment), ale vykresloval seznam s očekáváním objektů Environment[] (s poli slug a name). Protože se názvy polí neshodovaly, každá položka dropdownu se zobrazovala prázdná. Dialog nyní načítá z GET /organizations/:orgId/environments, který vrací správný tvar Environment[], a dropdown se tak správně naplní.

---

Verze 1.0.56

Datum vydání: 2026-07-01

Vylepšení

• Rozšířené bezpečnostní gate v release pipeline — Vývojová CI pipeline nyní skenuje všechny dodávané image včetně docs a init-certs a release pipeline nově skenuje i docs a při nálezech Trivy se závažností CRITICAL/HIGH release ukončí chybou místo pasivního reportingu. Uzavírá se tím slepé místo, kdy pomocné image mohly projít do vydání s neopravenými zranitelnostmi, i když backend, frontend a ocsp byly čisté.
• Sjednocení base image a lokálního runtime — init-certs se nyní v lokálním docker-compose builduje ze stejného připnutého Dockerfile.init-certs místo ad-hoc bootstrapu nad alpine:latest. Image init-certs přešla na Alpine 3.21 s upgradem balíčků během buildu a runtime stage docs image nyní před zabalením nginx obnovuje Alpine balíčky. Tím se snižuje drift mezi CI artefakty a lokálním během a zároveň expozice známým CVE v OS balíčcích.
• Obnova backend závislostí pro dosažitelné integrační cesty — Byly připnuty opravené Go verze pro github.com/Azure/go-ntlmssp, github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream, github.com/aws/aws-sdk-go-v2/service/s3, github.com/quic-go/quic-go a go.mongodb.org/mongo-driver, což pokrývá dosažitelné volitelné cesty jako ADCS NTLM autentizaci, transport auditního archivu do S3, použití QUIC stacku a MongoDB reconciliaci a rotační kód.

Opravy chyb

• Request ID tracing sjednocen napříč middleware a logy — RequestIDMiddleware nyní plní oba Gin context klíče requestID i legacy request_id a dál vrací hlavičku X-Request-ID; warning logy rozlišení prostředí současně čtou kanonický klíč requestID. Tím se uzavírá mezera ve sledovatelnosti, kdy část logů zapisovala prázdné request ID, přestože už bylo požadavku přiřazeno.
• Orchestrator mode guard používá přesné route patterny — Ingress guard v orchestrator mode už nespoléhá na heuristiky nad suffixy a substringy URL. Místo toho páruje registrované Gin route patterny přes c.FullPath() pro write route secretů v /api/v1/secrets i /api/v2/secrets a současně se vyhýbá false positive zásahům do vnořených flow, jako je import certifikátů. Přímé payloady secretů s polem value zůstávají v orchestrator mode blokované, ale legitimní endpointy pro import certifikátů už nejsou ohroženy náhodným zachycením.
• Synchronizace Entra pro vybrané aplikace nyní zůstává ve stavu pending, dokud neexistují bindingy — Pokud je Entra integrace nakonfigurována se scope selected_apps, ale zatím k ní nejsou uloženy žádné bindingy vybraných aplikací, manuální synchronizace nyní vrací HTTP 409 Conflict místo obecného selhání. Integrace se zapíše s last_sync_status = pending, last_sync_error zůstane prázdné a hodinový plánovač jen zaloguje přeskočení, dokud není nakonfigurována alespoň jedna vybraná aplikace. API i provozní stav tak pravdivě odrážejí postupný onboarding.
• Stavy synchronizačních pravidel a auditní metadata nyní zachovávají provenienci spuštění — Běhy synchronizačních pravidel nyní persistují kanonický execution záznam a promítají výsledné execution_id, trigger_source, zdrojový secret/prostředí a agregované počty výsledků do stavových polí pravidla i metadat synchronizačních logů. Obousměrná synchronizace navíc potlačuje okamžitý echo-push secretů, které byly právě nataženy nebo zůstaly po pull fázi beze změny, čímž omezuje zbytečný churn v externím systému a zároveň drží sync_rules.last_sync_status a project_integrations.last_sync_* v souladu s finálním výsledkem.
• Krok 0 rotace (connection_validation) nyní respektuje background_auth_method integrace — Když orchestrátor rotace provádí operaci lokálně (nedelegovaná cesta), metoda TestConnection() pro integrace Azure Key Vault nyní volá prepareAzureIntegrationRuntimeConfig() před pokusem o připojení. Dříve zastaralé přihlašovací údaje client_secret v zašifrované konfiguraci integrace přebíjely nakonfigurovanou hodnotu background_auth_method=managed_identity, což způsobovalo chyby ClientSecretCredential authentication failed během rotace, zatímco synchronizace (která již používala správnou přípravnou cestu) úspěšně pokračovala. Oprava zajišťuje konzistentní rozlišení autentizační metody napříč cestami synchronizace a rotace.

Poznámky

• Dopad upgradu — Verze 1.0.56 neobsahuje databázové migrace ani změny konfiguračního schématu. Stávající API kontrakty zůstávají stabilní; hlavní provozní změnou je přísnější release gating, takže CI a release joby nyní mohou selhat, pokud image docs nebo init-certs obsahují nevyřešené nálezy se závažností CRITICAL/HIGH.
• Dopad na lokální vývoj — První docker compose up --build po upgradu znovu sestaví dedikovanou image client-init-certs místo stažení generické Alpine base a inline instalace balíčků. Build může být mírně delší, ale lokální chování nyní mnohem přesněji odpovídá dodávané image.

---

Verze 1.0.55

Datum vydání: 2026-06-29

Nové funkce

• Správa cílů rotace secretů (Secret Rotation Targets) — Plná CRUD správa cílů rotace secretů je nyní dostupná přes API, frontend, Go SDK a Terraform. Cíle definují cílová umístění nasazení (Kubernetes secrets, rotace databázových hesel, synchronizace agenta, proměnné DevOps pipeline, cloudové trezory), do nichž MazeVault zasílá aktualizované přihlašovací údaje ihned po dokončení rotace. Nová komponenta SecretRotationTargetList na záložce Secrets umožňuje operátorům přidávat, upravovat a odstraňovat cíle bez opuštění pohledu projektu. Terraform resource mazevault_secret_rotation_target umožňuje plně deklarativní správu; argument config_json přijímá JSON objekt zakódovaný pomocí jsonencode() popisující konfiguraci specifickou pro daný cíl.
• Aktualizace konfigurace interní CA a doplnění AIA (Backfill) — Dva nové API endpointy umožňují aktualizovat měnitelná pole na účtu interní CA bez nutnosti jeho opětovného vytvoření: PUT /api/v1/ca/:id a PUT /api/v1/projects/:id/ca/:caId přijímají ocsp_url, crl_url a ocsp_responder_cert_id s patch sémantikou (vynechaná pole zůstanou nezměněna). Doprovodný endpoint POST /api/v1/admin/certificates/backfill-aia zpětně kopíruje aktuální OCSP a CRL URL z účtu CA do všech existujících certifikátů, které vydal. Rozšíření OCSP URL, CRL Distribution Points a Issuer Certificate URL jsou nyní správně vkládána do šablony x509 v rámci InternalCAProvider.SignCSR() pro všechny nově vydávané certifikáty.
• Výběr agenta v konfiguraci rotace — SecretPostRotationActionsPanel a SecretRotationTargetEditor nyní zobrazují rozbalovací nabídku, která operátorovi umožňuje svázat konkrétního registrovaného agenta s cílem rotace. Tím je zajištěna přesná kontrola nad tím, který on-premise agent provede krok nasazení, bez nutnosti spoléhat se výhradně na směrování dle prostředí.
• Modal pro zobrazení šablony certifikátu — Nová komponenta CertificateTemplateViewModal poskytuje podrobné zobrazení šablony certifikátu jen pro čtení (SAN vzory, key usage, extended key usage, platnost, vazba na CA účet) bez nutnosti opustit aktuální stránku. Modal je přístupný jak ze záložky CertificateTemplatesTab na úrovni organizace, tak ze záložky TemplatesTab na úrovni projektu. Zobrazení nyní také ukazuje algoritmus podpisu (s návratem na výchozí hodnotu CA, pokud není nastaven) a název ACME profilu a označuje omezení sloužící pouze k validaci a pole řízená externí CA, takže operátoři rozumí tomu, která nastavení vynucuje MazeVault a která vydávající CA.
• Šablony certifikátů nyní řídí vydávání od začátku do konce — Šablony certifikátů byly povýšeny z částečně dekorativního metadatového záznamu na autoritativní governance „kuchařku" pro vydávání certifikátů v celém životním cyklu. Pole šablony, která byla dříve ukládána, ale nikdy aplikována, jsou nyní respektována podpisovým enginem a generátorem CSR: max_path_length (s explicitním zpracováním path-length-zero pro CA certifikáty), policy OID certifikátů (policy_identifiers / certificate_policies), signature_algorithm, výchozí šablona common-name (cn_template) a subjektový email. Nová záložka Governance v CertificateTemplateModal zpřístupňuje požadavky na schválení, povolená prostředí a povolené velikosti klíčů a vyhrazená sekce Renewal & Rotation umožňuje nezávisle nastavit politiku opětovného použití klíče. Výchozí hodnoty šablon jsou nyní normalizovány při vytvoření/aktualizaci (validity_days → 365, key_size → 256/2048 dle algoritmu, okna minimální/maximální platnosti), takže šablona nikdy nemůže uložit neúčinné nulové hodnoty.
• Modaly pro zobrazení šablon projektů a konfigurací — Dva nové modaly s detailem jen pro čtení, ProjectTemplateViewModal a ConfigTemplateViewModal, přinášejí stejný způsob rychlé inspekce, který je již dostupný pro šablony certifikátů, i k šablonám projektů (obecná nastavení, pravidla prostředí, schéma proměnných, konfigurace protokolu) a šablonám konfigurací (metadata, souhrn definice, surový JSON). Oba jsou dostupné přes akci zobrazení (ikona oka) v příslušných záložkách správy.
• Terraform: Certificate Rotation Config, Entra Rotation Config a datový zdroj Rotation Resources — Tři nové Terraform povrchy doplňují IaC pokrytí rotační platformy: mazevault_certificate_rotation_config spravuje plánování automatického obnovení a seznamy akcí po rotaci pro konkrétní certifikát; mazevault_entra_rotation_config spravuje nastavení rotace přihlašovacích údajů Entra ID včetně prahu dní před expirací a chování postupné rotace; mazevault_rotation_resources je datový zdroj, který vypisuje všechny rotací spravované zdroje s jejich aktuálním stavem, filtrovatelný podle kind a environment_scope.

Reforma identity prostředí

• Identifikátory prostředí jsou nyní ukládány doslovně a párovány přesně — Identifikátory prostředí zadané v Nastavení organizace jsou jediným zdrojem pravdy. Systém je nyní ukládá doslovně (se zachováním velikosti písmen) a páruje je přesně (s ohledem na velikost písmen) všude — RBAC, secrety, synchronizační pravidla, směrování gateway, úlohy gateway, zámky prostředí i frontend. Identifikátory, které se liší pouze velikostí písmen (například developmentA, DeveLopmentB, DeveLopmentC), jsou považovány za odlišná prostředí. Systém nikdy tiše nepřepisuje, nepřevádí na malá písmena, neořezává ani nemapuje aliasy toho, co operátor zadal.
• CanonicalizeEnvironment je nyní pouze validační: odmítá prázdné/jen z mezer složené, rezervované (*, default, all, system, none), příliš krátké/dlouhé a chybně tvarované identifikátory (povolený tvar ^[A-Za-z][A-Za-z0-9_-]{1,31}$) a při úspěchu vrací vstup beze změny.
• Mapa aliasů prostředí gateway (pro→production, npr→nonproduction atd.) byla odstraněna z backendu i frontendu. SupportsEnvironment(), GetEnvironmentMode(), směrování gateway, failover health-monitoru a frontendový pomocník environments nyní porovnávají identifikátory přesně. Frontendový pomocník prostředí již neaplikuje toLowerCase()/normalizaci tokenů a všechny selektory prostředí získávají své volby výhradně ze seznamu prostředí organizace.
• Dopad: existující data prostředí zákazníků jsou jednotně malými písmeny, takže přesné párování dle velikosti písmen je pro stávající záznamy no-op — nulová regrese RBAC/secret/sync. Identifikátory se smíšenou velikostí písmen jsou podporovány pouze do budoucna.

Vylepšení

• Úplnost prověření před spuštěním rotace (gateway, agent a runtime Entra) — Orchestrátor rotace nyní ověřuje, že každý požadovaný cíl provedení je dosažitelný před prvním mutujícím krokem, a vrací strukturovanou chybu HTTP 412, pokud rotaci nelze bezpečně zahájit. Místo neprůhledné chyby 500/409 jsou nyní zobrazovány tři nové chybové kódy — rotation_blocked_no_gateway, rotation_blocked_agent_offline a rotation_blocked_runtime_unavailable. Prověření nyní zohledňuje certifikáty (správně rozpozná cíle CertificateRotationConfig), shromažďuje všechna požadovaná ID agentů napříč všemi kroky workflow využívajícími agenta a je vynucováno také uvnitř executeCertificateWorkflow. Rotace přihlašovacích údajů Entra spouští stejné prověření runtime v RotateCredentialWithRequest dříve, než životní cyklus přejde do stavu rotating, takže blokovaný runtime nikdy nezanechá přihlašovací údaj rotovaný jen napůl. Změna přihlašovacího údaje nebo certifikátu, kterou nelze nasadit, nyní selže rychle a viditelně namísto toho, aby se spustila a zasekla.
• Delegování synchronizace Azure Key Vault přes gateway — Operace synchronizace push a pull s Azure Key Vault jsou nyní delegovány na příslušnou gateway, pokud backend zjistí, že přímá síťová cesta k endpointu Key Vault není dostupná. Úlohy gateway nesou konfiguraci integrace a provádějí skutečná volání Azure SDK; primární backend zaznamenává pouze výsledný stav synchronizace. Spuštění plánovače synchronizačních pravidel bylo odloženo až po úplné inicializaci delegování přes gateway, čímž se zamezuje přechodným chybám DNS při startu backendu.
• Automatické doplnění cílového prostředí v konfiguraci rotace — Když GetConfigBySecretID vytváří novou konfiguraci rotace pro secret, který ji dosud nemá, pole target_environment je nyní automaticky doplněno z prostředí daného secretu. Tím odpadá ruční krok aktualizace, který byl dříve vyžadován před prvním spuštěním rotace.

Opravy chyb

• Párování prostředí gateway přepracováno na doslovnou/přesnou identitu — Dříve v tomto vydávacím cyklu se párování prostředí gateway spoléhalo na mapu aliasů bez ohledu na velikost písmen (pro→production, npr→nonproduction atd.), která mohla tiše mapovat nesouvisející identifikátory dohromady a mutovat hodnoty zadané operátorem. Tento přístup byl nahrazen doslovným/přesným modelem identity prostředí (viz Reforma identity prostředí výše): SupportsEnvironment() a GetEnvironmentMode() nyní porovnávají přesně, mapa aliasů byla odstraněna a dříve plánovaná migrace normalizace aliasů 000176 byla neutralizována na no-op (nikdy nebyla dodána zákazníkům). Dopředné migrace 000178/000179 odstraňují CHECK constrainty vynucující malá písmena a unikátní indexy bez ohledu na velikost písmen, takže jsou přijímány identifikátory lišící se velikostí písmen.
• Rozšíření AIA nevkládána do vydávaných certifikátů — InternalCAProvider.SignCSR() načítalo ocsp_url a crl_url ze záznamu CA, ale nikdy je nezapisovalo do šablony certifikátu x509, takže každý certifikát vydaný interní CA měl prázdná rozšíření Authority Information Access a CRL Distribution Points. Obě rozšíření jsou nyní správně vkládána do všech nových certifikátů. Existující certifikáty lze zpětně aktualizovat prostřednictvím nového backfill endpointu.
• Device Fingerprint — souběžná podmínka (race condition) při vkládání — Služba detekce anomálií mohla produkovat porušení constraints s duplicitním klíčem, pokud se dvě souběžné autentizační požadavky od stejného dříve neviděného zařízení pokoušely současně zaregistrovat jeho otisk. Cesta vkládání nyní používá upsert vzor s ochranou ON CONFLICT DO NOTHING pro korektní zpracování souběžných registrací.
• Plánovač synchronizačních pravidel — chyby DNS při startu backendu — Na backendech nakonfigurovaných s delegováním přes gateway mohlo první naplánované spuštění plánovače synchronizačních pravidel selhat s chybami DNS, protože se spustil dříve, než subsystém delegování gateway dokončil inicializaci. Spuštění plánovače je nyní odloženo až po připravenosti delegační vrstvy.
• Terraform resource organizace — tiché spolknutí chyb při mazání — Metoda Delete v Terraform resource mazevault_organization vracela úspěch i v případě, kdy backend odpověděl stavovým kódem jiným než 2xx. Chyby backendu jsou nyní zobrazovány jako Terraform diagnostiky, takže terraform destroy viditelně selže namísto ponechání resource v nekonzistentním stavu.
• Policy OID certifikátů tiše vynechány z vydaných certifikátů (Go 1.24+) — InternalCAProvider.SignCSR() vyplňoval pouze zastaralé pole x509.Certificate.PolicyIdentifiers. Go 1.24+ x509.CreateCertificate vydává rozšíření Certificate Policies místo toho z nového pole Policies ([]x509.OID), takže policy OID deklarované v šabloně byly tiše vynechány z každého vydaného certifikátu. SignCSR nyní vyplňuje obě pole — moderní slice Policies (pro současné enkodéry) i legacy slice PolicyIdentifiers (pro starší parsery) — takže policy OID jsou spolehlivě vkládány.
• Podpisová a subjektová pole šablony certifikátu byla neúčinná — max_path_length, signature_algorithm, policy OID certifikátů, výchozí šablona common-name a subjektový email byly v šablonách certifikátů ukládány, ale nikdy se nedostaly do vydaného certifikátu ani vygenerovaného CSR. Všechna tato pole šablony jsou nyní aplikována při podpisu a generování CSR, čímž se uzavírá rozdíl mezi tím, co šablona deklaruje, a tím, co certifikát skutečně obsahuje.
• Import šablony z externí CA ukládal nulové validity_days / key_size — Šablony importované z externích poskytovatelů CA (ADCS, SmallStep) byly ukládány s validity_days = 0 a key_size = 0, což se následně projevovalo jako neplatné výchozí hodnoty v editoru šablon. Importované šablony nyní nesou rozumné výchozí hodnoty (key_size = 2048, valid_days = 365) a servisní vrstva normalizuje veškeré zbylé nulové hodnoty při vytvoření/aktualizaci jako obranu do hloubky.

Databázové migrace

• 000176_normalize_gateway_environments — Neutralizováno na no-op (SELECT 1). Tato migrace původně normalizovala legacy aliasy prostředí na kanonické identifikátory, ale reforma identity prostředí tento směr obrátila (identifikátory jsou nyní ukládány doslovně). Protože migrace nebyla nikdy vydána žádnému zákazníkovi, jsou nyní její .up.sql i .down.sql zdokumentované no-opy, které ponechávají data gateway zákazníků nedotčená.
• 000177_certificate_templates_signature_algorithm — Přidává sloupec signature_algorithm VARCHAR(50) do certificate_templates (idempotentní ADD COLUMN IF NOT EXISTS), aby šablony mohly fixovat algoritmus podpisu při vydávání. Odpovídající .down.sql sloupec odstraňuje. ExpectedColumns["certificate_templates"] v database_health.go byl odpovídajícím způsobem aktualizován.
• 000178_relax_canonical_environment_check — Odstraňuje 11 CHECK constraintů chk_*_canonical (přidaných migrací 000125), které vyžadovaly column = LOWER(column) na každém sloupci nesoucím prostředí. Tyto constrainty by odmítaly identifikátory lišící se velikostí písmen, což odporuje doslovnému kontraktu; validace na straně aplikace (CanonicalizeEnvironment) nadále vynucuje pravidla tvaru, délky a rezervovaných slov. Dolní migrace constrainty znovu přidává. Idempotentní (DROP CONSTRAINT IF EXISTS).
• 000179_case_sensitive_environment_indexes — Nahrazuje unikátní pojistky LOWER() bez ohledu na velikost písmen z migrace 000122 přesným unikátním indexem s ohledem na velikost písmen uniq_environments_org_slug (organization_id, slug) a obnovuje běžné vyhledávací indexy nad surovými sloupci pro každý sloupec nesoucí prostředí. Existující unikátnost na úrovni projektu (idx_project_env) je již přesná. Dolní migrace obnovuje indexy LOWER(). Idempotentní.

---

Verze 1.0.54

Datum vydání: 2026-06-27

Opravy chyb

• Watchdog Entra přihlašovacích údajů — detekce zaseknutí trvale obcházena hodinovou synchronizací — PostgreSQL trigger trg_entra_creds_updated obnovuje updated_at = NOW() při každém UPDATE záznamu v tabulce entra_credentials, včetně zápisů do nesouvisejících polí prováděných hodinovou synchronizační smyčkou (syncedEntraCredentialUpdates). Podmínka updated_at < now() - 30min proto nebyla nikdy splněna pro žádné přihlašovací údaje, které prošly synchronizačním cyklem, a watchdog se nikdy nespustil. Nový sloupec rotation_started_at TIMESTAMPTZ (migrace 000175) je nastaven při přechodu lifecycle_state na rotating a vymazán při rollbacku nebo zotavení watchdogem. Watchdog dotaz nyní používá rotation_started_at IS NULL OR rotation_started_at < cutoff; podmínka IS NULL pokrývá přihlašovací údaje zaseknuté před aplikací migrace.
• Monitor expirace Entra — chyba GORM Preload("") při každé hodinové kontrole — checkExpiringCredentials volal .Preload("") (prázdný řetězec) na GORM dotazu. GORM v2 toto odmítá chybou unsupported relations for schema EntraCredential, každou hodinu loguje chybu a zabraňuje nastavení stavu expiring_soon u přihlašovacích údajů, které skutečně expirují. Neplatné volání .Preload("") bylo odstraněno; chování je jinak nezměněno.
• Sync Rule Pull — porušení FK secret_versions_created_by_fkey pro systémové aktory — SyncRuleService.executePull volá SecretService.Update s req.UserID = uuid.Nil (žádný autentizovaný uživatel). Update bezpodmínečně ukládal &req.UserID jako created_by do nového záznamu SecretVersion; GORM serializuje *uuid.Nil jako řetězec '00000000-...' namísto SQL NULL, což porušuje non-null FK odkazující na tabulku users. Oprava přidává nil-guard: created_by je nastaven na NULL, pokud volající předá zero-value UUID, v souladu s kontraktem nullable sloupce.
• Azure KV Integrace — synchronizované secrets zobrazeny jako „Uloženo lokálně" — syncAzureKeyVaultLocal vytvářel a aktualizoval secrets v tabulce secrets, ale nikdy nevkládal záznam SecretIntegrationLink s link_purpose = 'sync_source'. GetSecretSyncStatus proto vrátil local_only pro každý KV-synchronizovaný secret a uživatelské rozhraní zobrazovalo „Uloženo lokálně" místo „Synchronizováno z KV". Oprava vkládá inline stejnou logiku upsert jako SyncRuleService.upsertPullLink přímo v IntegrationService pomocí s.db a clause.OnConflict, čímž se předchází závislosti napříč službami.

Vylepšení

• Oprávnění rolí — agent:admin přidáno do rolí secret_manager a certificate_manager — Operace správy agentů (agent:admin) byly přidány do systémových rolí secret_manager a certificate_manager (migrace 000174). Operátoři vlastnící pouze jednu z těchto rolí nyní mohou registrovat a konfigurovat agenty bez nutnosti přiřazení samostatné role admin.

Databázové migrace

• 000174_agent_admin_for_managers — Uděluje oprávnění agent:admin vestavěným rolím secret_manager a certificate_manager.
• 000175_entra_credentials_rotation_started_at — Přidává rotation_started_at TIMESTAMPTZ do entra_credentials. Obsahuje partial index idx_entra_creds_rotation_started přes (rotation_started_at) pro stavy rotating a pending_verification.

---

Verze 1.0.53

Datum vydání: 2026-06-26

Opravy chyb

• OCSP — existence certifikátu neověřena před staplingem — Služba OCSP odpovídala na požadavky staplingu bez ověření, zda odkazované sériové číslo v lokálním úložišti certifikátů existuje. Útočník s podělátým nebo znovu použitým sériovym číslem mohl získat platnou OCSP odpověď pro neexistující certifikát. Služba nyní ověřuje existenci certifikátu před sestavením odpovědi a pro neznámá sériová čísla vrací stav Unknown.
• Krok rotace — PostgreSQL GRANT/REVOKE zranitelný SQL injekcí — rotation_steps/postgres_db.go sestavoval příkazy GRANT/REVOKE přímým řetězovým spojením jména role a seznamu oprávnění bez escapování. Jména databázových rolí jsou nyní uzavřena do dvojitých uvozovek pomocí identifikátorového escapování podle pgx, což zavírá cestu SQL injekce.
• SSH klíče — ExportPrivateKey bez autorizační kontroly — ExportPrivateKey neověřoval, zda žádající uživatel má vlastnictví nebo správcovská práva na SSH klíč, před vrácením šifrovaného privátního materiálu. Handler nyní vynucuje stejnou kontrolu členství v projektu a vlastnictví jako ostatní mutation endpointy SSH klíčů.
• SSH rotace — chybné mapování polí API odpovědi pro páry klíčů — Handler odpovědi SSH rotace přímo prohazoval pole páru klíčů z API odpovědi, což způsobovalo vrácení prohozeného nebo prázdného public_key a key_id po úspěšné rotaci. Mapování polí bylo opraveno.
• Rotace keytabu — nestrukturované logování obcházející pipeline — Chyby rotace keytabu byly emitovány přes legacy balíček log, který obchází strukturovaný logovací pipeline a ztrácí kontextová pole požadavku. Všechna volání logů v keytab_rotation_executor.go jsou nyní směrována přes slog.
• CA účty — ca_authority_id neuložen při aktualizaci — UpdateCAAccount tiše zahazoval ca_authority_id při aktualizaci existujícího CA účtu, protože pole chybělo v mapě Updates pro GORM. Pole je nyní zahrnuto a pokryto novým testem.
• Drift schématu CRL / revokace — OCSP vrací 500 — Tabulky revocation_entries a certificate_revocation_lists byly vytvořeny migrací 000005 s legádními názvy sloupců (reason_code, crl_pem), které se odchylují od aktuálních názvů polí GORM modelu (revocation_reason, raw_content). GORM přidává deleted_at IS NULL ke každému dotazu; protože deleted_at v produkčním schématu chyběl, vracel celý subsystém CRL/OCSP chyby SQLSTATE 42703. Migrace 000173 přidává všechny chybějící sloupce idempotentně pomocí ADD COLUMN IF NOT EXISTS a doplní hodnoty z legádních sloupců.

Vylepšení

• Spuštění rotace — tělo požadavku volitelné — Endpointy spouštění rotace nyní přijímají požadavky s prázdným nebo chybějícím tělem; reason se v takovém případě nastaví na "manual".
• CA Interní — podepisování OCSP přes HSM odloženo s explicitní dokumentací — Podepisování OCSP odpovědí přes HSM je explicitně odloženo; kódová cesta nyní obsahuje jasně označený komentář odložení a mezitím vrací odpověď podepsanou softwarově.
• Feature flags — zpříbnění režimu gateway a validace licence — features.go zpřesňuje logiku vyhodnocování gateway_mode a funkcí chráněných licencí, eliminuje třídu falešně pozitivních výsledků enabled při částečně zpracovaném payloadu licence.
• SRP — dokumentace pořadí kroků MFA — Tok ověřování SRP nyní obsahuje explicitní komentář dokumentující řazení kroků MFA a zdůvodnění aktuálního pořadí TOTP/záložních kódů.
• Průvodce pojmenováním secretů — kontext autentizace pro správu tokenů — SecretNamingPolicyWizard nyní předává kontext autentizovaného uživatele voláním správy tokenů, čímž opravuje potenciálně neautentizovanou cestu volání v procesu ukládání průvodce.

Databázové migrace

• 000173_fix_revocation_crl_schema_drift — Přidává chybějící sloupce do revocation_entries (crl_id, revocation_reason, updated_at, deleted_at) a certificate_revocation_lists (raw_content, updated_at, deleted_at). Doplní hodnoty z legádních sloupců reason_code a crl_pem. Plně idempotentní.

---

Verze 1.0.52

Datum vydání: 2026-06-23

Opravy chyb

• Schéma Renewal Policy — chybějící sloupce key_reuse_enabled a validity_duration — Tabulka certificate_renewal_policies byla vytvořena migrací 000010 se sloupcem reuse_private_key; Go model byl následně přejmenován na key_reuse_enabled bez doprovodné migrace, čímž každý zápis dotýkající se tohoto pole selhal na databázové vrstvě. Migrace 000172 přidává key_reuse_enabled BOOLEAN NOT NULL DEFAULT FALSE (s doplněním hodnot z legacy sloupce reuse_private_key) a validity_duration INT NOT NULL DEFAULT 0. Stejná migrace převádí notify_emails z JSONB na TEXT pomocí třífázového přístupu (přidání TEXT staging sloupce → UPDATE přes set-returning funkci → drop JSONB sloupce → přejmenování), čímž obchází omezení PostgreSQL, které zakazuje subquery uvnitř ALTER COLUMN TYPE … USING.
• Fronta obnov — sloupec certificates.organization_id neexistuje — GetRenewalQueue filtroval WHERE certificates.organization_id = ?, ale tabulka certificates obsahuje pouze project_id; organizaci lze dosáhnout přes certificates.project_id → projects.organization_id. Služba nyní provádí druhý JOIN (JOIN projects ON projects.id = certificates.project_id) a filtruje podle projects.organization_id.
• SDK a Terraform Provider — sémantická neshoda notify_days_before []int — Go SDK (sdks/go/models.go) a Terraform provider (internal/resources/renewal_policy.go) deklarovaly pole notify_days_before []int, které v backendu nikdy neexistovalo. Backend ukládá prostý čárkami oddělený řetězec pod klíčem notify_emails. Obě komponenty byly přepsány na notify_emails string a byla přidána dvě nová pole key_reuse_enabled a validity_duration pro sladění s živým API kontraktem. Acceptance testy blokované pomocí t.Skip z důvodu těchto nedostatků jsou nyní aktivní.

Databázové migrace

• 000172_fix_certificate_renewal_policy_schema — Přidává key_reuse_enabled BOOLEAN NOT NULL DEFAULT FALSE (doplněno z reuse_private_key), validity_duration INT NOT NULL DEFAULT 0 a převádí notify_emails JSONB → TEXT v tabulce certificate_renewal_policies.

---

Verze 1.0.51

Datum vydání: 2026-06-22

Nové funkce

• Potvrzení selhání rotace (Acknowledge Rotation Failure) — Operátoři nyní mohou trvale odložit (dismiss) prověřené selhání rotace z dashboardu Rotation Problems bez smazání záznamu spuštění. Nový endpoint POST /api/v1/dashboard/rotation/failures/{id}/acknowledge (RBAC: dashboard:write) zapíše acknowledged_at a acknowledged_by do řádku spuštění. Dashboard dotaz filtruje potvrzené řádky a udržuje tak přehled zaměřený na položky stále vyžadující pozornost. Uživatelské rozhraní zpřístupňuje akci „Označit jako prověřeno" v panelu detailu selhání.
• Watchdog pro zaseknuté Entra přihlašovací údaje — Nový background watchdog (RecoverStuckEntraCredentials) běží každých 5 minut a resetuje Entra přihlašovací údaje zaseknuté ve stavu rotating nebo pending_verification déle než 30 minut. Zabraňuje nekonečným stálům způsobeným restartem backendu nebo zrušením goroutiny uprostřed rotace. Každé zotavení zapíše stuck_watchdog_recovered_at do záznamu přihlašovacích údajů pro auditní sledovatelnost.
• Stav Entra přihlašovacích údajů — pending_verification — Constraint entra_credentials_status_check byl rozšířen o hodnotu pending_verification, kterou zapisuje RotateCredentialWithRequest po každé rotaci, jsou-li nakonfigurované downstream propagační cíle. Bez tohoto rozšíření by jakákoli rotace s propagací produkovala porušení constraintu a zanechávala by přihlašovací údaje v nekonzistentním stavu.
• CA účet — počet přiřazených certifikátů — Odpovědi pro seznam a detail CA účtu nyní obsahují assigned_certificates_count, tedy počet aktivních certifikátů vydaných přes šablony certifikátů svázané s daným CA účtem. Operátoři tak okamžitě vidí aktivní záběr CA účtu bez dalšího dotazu.
• Terraform Provider — User, User Role, Keytab, Project Settings, Shared Secret — Pět nových Terraform zdrojů doplňuje pokrytí providera o správu uživatelů a konfigurace projektů: mazevault_user (CRUD platformních uživatelů), mazevault_user_role (přiřazení rolí uživatelům v organizaci), mazevault_keytab (správa Kerberos keytab souborů připojených k projektu), mazevault_project_settings (projektová konfigurační nastavení) a mazevault_shared_secret (secrets sdílené napříč více projekty).

Vylepšení

• Rotation Problems — filtr potvrzených selhání — Stránka Rotation Problems a služba platformního přehledu nyní vylučují potvrzená spuštění z počtů selhání a seznamů, a to s využitím partial indexu idx_rotation_executions_unacknowledged zavedého migrací 000170.

Databázové migrace

• 000169_entra_credentials_status_pending_verification — Rozšiřuje constraint entra_credentials_status_check o hodnotu pending_verification.
• 000170_rotation_execution_acknowledgement — Přidává acknowledged_at TIMESTAMPTZ a acknowledged_by UUID REFERENCES users do rotation_executions. Obsahuje partial index idx_rotation_executions_unacknowledged pokrývající pouze nepotvrzené řádky.
• 000171_entra_credential_stuck_watchdog — Přidává stuck_watchdog_recovered_at TIMESTAMPTZ do entra_credentials. Přidává partial index idx_entra_creds_stuck_watchdog přes (lifecycle_state, updated_at) pro dva in-flight stavy.

---

Verze 1.0.50

Datum vydání: 2026-06-21

Nové funkce

• Šablony konfigurace rotace (Rotation Config Templates) — Nový katalog v rozsahu organizace umožňuje operátorům evidovat opakovaně použitelná nastavení rotace (interval, lead days, retention window, max. počet opakování, timeout). Spravuje se přes pět API endpointů GET|POST /api/v1/rotation/templates a GET|PUT|DELETE /api/v1/rotation/templates/{id} s RBAC (rotation:read / rotation:write). Nový Terraform zdroj mazevault_rotation_template umožňuje správu katalogu přes IaC. Šablony se na konfigurace rotace automaticky neaplikují. Frontend zpřístupňuje plnou CRUD stránku na /rotation/templates. Migrace 000168 přidává tabulku rotation_config_templates a cizí klíč template_id na rotation_configs.
• Sync Rule — obousměrný režim a strategie konfliktu — SyncRuleModal nyní zobrazuje konfigurovatelný směr synchronizace (pull / push / bidirectional) a synchronizační režim (incremental / full_sync). Oba atributy jsou persistovány na straně serveru a zdokumentovány v novém Terraform zdroji mazevault_sync_rule. Operace pull-sync nyní zapisují last_pulled_at, link_purpose a external_secret_path do secret_integration_links (migrace 000167), čímž umožňují zobrazení stavového odznaku synced_from_external u secrets vytažených z externího poskytovatele.
• Dry-run pro rotaci certifikátů — Záložka Rotace certifikátů nyní obsahuje tlačítko „Dry Run" vedle existující akce „Trigger Rotation Now". Dry-run provede kompletní validaci workflow rotace — včetně preflight post-rotačních akcí a gateway probing — bez potvrzení jakýchkoli změn. Příznak dry_run je propagován end-to-end přes API a všechny kroky rotace.
• Post-rotační akce — přímé napojení na gateway a přepsání prostředí — PostRotationAction nyní přijímá volitelné pole gateway_id, které připne akci na konkrétní gateway a obchází routing na základě prostředí. Doprovodné pole target_environment přepisuje kontext prostředí při rozlišování cílové gateway. Obě pole jsou dostupná v Go SDK (PostRotationActionWF) i v Terraform zdroji mazevault_rotation_workflow.
• Terraform Provider — Sync Rules a Rotation Templates — Dva nové Terraform zdroje pokrývají kompletní životní cyklus create/read/update/delete: mazevault_sync_rule (směr synchronizace, strategie konfliktu, transformace klíče, prefix cesty) a mazevault_rotation_template (interval, lead days, retence, politika opakování). Oba jsou registrovány v provideru a zdokumentovány v docs/resources/.
• Rotation Problems — detail zobrazení selhání — Stránka Rotation Problems nyní zobrazuje detailní tabulku neúspěšných spuštění s drill-down na jednotlivé zdroje, koláčový graf rozložení podle druhu zdroje a přehled chybějících secrets. Navigace v postranním panelu zvýrazňuje sekci ikonou varování.

Vylepšení

• Distribuovaný synchronizační semafor přes Redis — SyncRuleService nyní používá distribuovaný zámek podporovaný Redis (SET NX PX) prostřednictvím nového páru TryAcquireLock / ReleaseLock na CacheService. Pokud Redis není dostupný, služba přejde na in-process zámek pomocí sync.Map. Tím se zabraňuje duplicitním souběžným synchronizacím pro stejné pravidlo v deploymentech s více replikami.
• Dry-run guard ve všech krocích rotace — Všech sedm vestavěných kroků rotace (generátor hesel, Azure Key Vault, Spring Actuator, agent command, shell script, IIS recycle, Kubernetes secret) nyní kontroluje příznak dry_run před jakýmkoli mutujícím externím voláním a místo toho vrátí náhledový výsledek.
• Rozšířený rozsah validace připojení — Krok rotace connection_validation byl rozšířen na pokrytí typů providerů mimo databáze (Azure Key Vault, Kubernetes, LDAP, GitHub, GitLab, generický webhook), čímž jsou zajištěny pre-execution kontroly konektivity i pro secrets napojené na tyto integrace.
• Guard pro secrets s names_only storage mode — Orchestrátor rotace nyní odmítá požadavky na rotaci secrets s storage_mode = names_only s jasnou chybovou zprávou, čímž zabraňuje zavádějícím záznamům o spuštění pro secrets, jejichž životní cyklus hodnoty je zcela řízen externím poskytovatelem.
• Stav synchronizace secretu — indikátor synced_from_external — GetSecretSyncStatus nyní vrací synced_from_external, pokud byl secret úspěšně vytažen z externího poskytovatele. Záložka Secrets zobrazuje tuto informaci jako informační odznak „Synced from KV".
• Compliance report — statistiky pokrytí nasazení a synchronizace — PasswordPolicyStats je rozšířen o čítače secrets_with_deployment_target, secrets_with_external_sync a secrets_with_template. Compliance report service je shromažďuje v jediném dalším DB průchodu.
• Gateway Task Service — přímé připnutí na gateway ID — GatewayTaskService.CreateTask nyní přijímá volitelný GatewayID, který při nastavení zcela přeskočí vyhledávání v routing service a odešle úlohu přímo na pojmenovanou gateway. Tím jsou podpořeny připnuté post-rotační akce bez nejednoznačnosti routingu.
• Čitelnost kódu — Pole struct interních služeb a modelů byla přeformátována pro konzistenci. Parametry resolveRotationResourceIncidentTarget byly zjednodušeny odstraněním redundantních mezilehlých proměnných.

Opravy chyb

• Dashboard Dismiss — TypeScript zúžení typů — Obslužná rutina dismiss pro položky akciovatelných rotací nyní správně zužuje item.status z 'overdue' | 'failed' | 'running' na serverem přijímaný union 'overdue' | 'failed' před odesláním požadavku, čímž opravuje TypeScript chybu kompilace, která se objevila po přidání 'running' do typového výčtu stavů položky.
• Chybějící routes pro Rotation Templates po refaktoru — Pět registrací routes /api/v1/rotation/templates bylo neúmyslně odstraněno při průchodu formátováním kódu. Všech pět routes bylo obnoveno s RBAC middleware (rotation:read / rotation:write).
• Swagger path drift pro Rotation Templates — Swagger anotace @Router v handlers_rotation_templates.go nesprávně používaly /rotation-templates místo skutečné gin cesty /rotation/templates. Všech pět anotací bylo opraveno a OpenAPI spec byl vygenerován znovu.
• Chybějící audit logging pro operace se Secret Links — Handlery CreateSecretLink a DeleteSecretLink nyní emitují záznamy auditního logu SECRET_LINK_CREATED a SECRET_LINK_DELETED se správným typem zdroje, ID a IP volajícího.

Databázové migrace

• 000167_secret_integration_links_pull_tracking — Přidává sloupce last_pulled_at TIMESTAMPTZ, link_purpose VARCHAR(64) a external_secret_path VARCHAR(512) do secret_integration_links. Obsahuje unikátní constraint uq_sil_secret_integration a partial index pro aktivní linky.
• 000168_rotation_config_templates — Přidává tabulku rotation_config_templates s kompletními CRUD sloupci (název, popis, org scope, výchozí příznak, interval rotace, lead days, retention days, politika opakování, timeout). Přidává template_id UUID REFERENCES rotation_config_templates do rotation_configs.

---

Verze 1.0.49

Datum vydání: 2026-06-20

Nové funkce

• Panel akciovatelných rotací na dashboardu — Přehledový dashboard nyní obsahuje vyhrazený panel „Rotation operations", který zobrazuje rotační zdroje po splatnosti nebo ve stavu selhání vyžadující okamžitou pozornost. Každá položka ukazuje druh, projekt a stavový odznak a podporuje jednoklikové odložení (Dismiss) s auditní poznámkou. Zobrazuje se nejvýše pět položek, seřazených podle stáří (po splatnosti) a aktuálnosti (selhání).
• Expirující certifikáty na dashboardu — filtr 30 dnů — Sekce „Direct actions" na přehledovém dashboardu nyní filtruje expirující certifikáty na příštích 30 dní, čímž je seznam okamžitě akciovatelný místo zobrazení všech budoucích expirací. Sekce se nyní jmenuje „Expiring certificates (next 30 days)". Endpoint GET /api/v1/dashboard/certificates/expiring přijímá nový volitelný parametr days (1–3650) pro omezení rozsahu; vynechání parametru vrátí všechny budoucí expirace (zpětně kompatibilní).
• Entra — staged rotace a dry-run — Rotace Entra přihlašovacích údajů nyní podporuje staged rotaci (staged_rotation_enabled) s konfigurovatelným soak window (soak_window_hours). Obě pole jsou persistována v metadatech rotačního zdroje a správně se přenášejí při GET/PUT cyklu rotační konfigurace. Dry-run cesta validuje workflow rotace vůči živému Entra tenantu bez aplikace jakýchkoli změn.
• Entra integrace — Instance ID a verzování protokolu — Entra integrace nyní nesou identifikátor instance a pole verze protokolu, umožňující přesnější cílení a budoucí kompatibilitu ve scénářích s více tenanty a delegovanou orchestrací.
• Rotation scheduler — obnova zaseknutých položek — Rotation scheduler nyní detekuje zdroje zaseknuté ve stavu „running" nebo „approval-pending" po překročení konfigurovatelného limitu a resetuje je do znovu spustitelného stavu, čímž zabraňuje tichým nekonečným stálům. Orchestrace obnovení rovněž získala explicitní koordinační logiku pro zdroje procházející oknem obnovení.
• Rotace certifikátů — výpočet příštího data splatnosti — Logika výpočtu data splatnosti rotace certifikátů je nyní pokryta dedikovanými unit testy. Příští datum splatnosti je počítáno z efektivní politiky lead days napříč vrstvami certifikátu, šablony a CA účtu, čímž je zajištěno konzistentní chování okna obnovení.

Vylepšení

• Odolnost načítání dat dashboardu — Načítání dat dashboardu nyní používá Promise.allSettled místo Promise.all. Selhání jednotlivých widgetů (síťová chyba, 401, 404) již nezahazují data ze všech ostatních widgetů. Každé selhání je logováno přes strukturovaný logger pro observabilitu.
• RBAC oprávnění pro rotační endpointy — Oprávnění pro čtení a zápis rotačních zdrojů jsou nyní konzistentně aplikována na všech nových dashboard a rotačních endpointech, včetně filtrování archivovaných zdrojů v dotazech servisní vrstvy.
• Dashboard — vyloučení archivovaných zdrojů — Dotazy platformního přehledu rotací a akciovatelných rotací nyní explicitně vylučují archivované zdroje, čímž se brání nafukování počtů po splatnosti nebo ve stavu selhání historickými daty.

Opravy chyb

• Editace Entra rotační konfigurace — regrese zakázaného stavu — Editace existující rotační konfigurace Entra přihlašovacích údajů již nezobrazuje všechna pole jako zakázaná pro ne-primární přihlašovací údaje. GET odpověď nyní vrací rotation_enabled z uložené uživatelské preference (metadata.rotation_enabled) namísto ze scheduler gate (resource.Enabled = RotationEnabled && IsPrimary), která byla vždy false pro ne-primární přihlašovací údaje.
• Entra rotační konfigurace — staged pole se neobnovovala při editaci — staged_rotation_enabled a soak_window_hours jsou nyní zahrnuty v metadatech projektoru rotačního zdroje a jsou proto správně obnoveny při otevření existující rotační konfigurace pro editaci.
• Entra scope binding — Tenant ID není povinné — Vytvoření Entra scope bindingu již nevyžaduje tenant_id, pokud integrace používá autentizaci managed identity. Backend validace i frontend průvodce byly aktualizovány tak, aby tenant_id bylo pro managed identity flow volitelné.

Infrastruktura

• Step-CA network policy — Přidáno pravidlo network policy umožňující příchozí provoz na Step-CA na portu 9000 z interního clusteru, čímž se odblokují ACME issuance flow na stagingu routované přes interní Step-CA provisioner.

---

Verze 1.0.48

Datum vydání: 2026-06-16

Nové funkce

• Domain Control Validation (DCV) pro objednávky externích CA — Poskytovatelé externích CA (DigiCert CertCentral v2, SSLMarket), kteří vyžadují doklad vlastnictví domény před vydáním certifikátu, nyní mají plnou podporu životního cyklu DCV. Nová tabulka certificate_dcv_tokens (migrace 000166) ukládá ověřovací tokeny pro každou doménu. Backend automaticky načítá tokeny po odeslání objednávky, přepne položku ve frontě obnovení do stavu pending_dcv a provádí polling každých 5 minut. Frontend komponenta DCVStatusPanel zobrazuje detaily výzvy pro každou doménu (název/hodnota DNS TXT záznamu, cesta/obsah HTTP souboru nebo e-mail schvalovatele) s tlačítky pro kopírování do schránky, indikátorem průběhu a ručním spuštěním ověření. Nové API endpointy GET /api/v1/renewal-queue/{id}/dcv a POST /api/v1/renewal-queue/{id}/dcv/retry zpřístupňují stav DCV s RBAC (certificate:read / certificate:write).
• ADCS čekající na schválení — neblokující DCOM odeslání — Metoda ADCS DCOM již neblokuje goroutinu HTTP handleru smyčkou 5 × 5 s opakovaných pokusů, pokud správce CA ještě neschválil požadavek (stav ADCS 5). Nyní okamžitě vrátí ErrADCSPendingApproval; stávající background job ADCSApprovalPoller zajistí asynchronní načtení certifikátu po schválení.
• Možnosti kompatibilního profilu PFX — Export certifikátu do PFX nyní podporuje výběr kompatibilního profilu (legacy / modern), který řídí šifrovací a MAC algoritmy použité v PKCS#12 kontejneru. legacy cílí na OpenSSL 1.x, nástroje Java KeyStore a starší Windows endpointy; modern cílí na OpenSSL 3.x, .NET 6+ a aktuální Go runtime.
• Žádost o certifikát — rozšířená pole Subject DN — Modal Žádost o certifikát nyní nabízí volitelná pole Subject DN: Organizace (O), Organizační jednotka (OU), Lokalita (L), Stát/Provincie (ST) a Země (C). Vyplněné hodnoty jsou odeslány jako strukturovaný objekt requested_subject v payload CSR požadavku.
• Žádost o certifikát — přepis algoritmu klíče — Pro páry klíčů generované MazeVault mohou operátoři nyní přepsat algoritmus klíče (RSA, ECDSA, Ed25519) a velikost klíče přímo v modalu Žádost o certifikát. Výběr je odeslán jako requested_key_algorithm a requested_key_size v payload CSR.

Vylepšení

• Redakce logů — zachování původní URL požadavku — Middleware redakce logů nyní uchovává původní RequestURI v Gin kontextu před jakýmkoli přepisováním nebo normalizací cesty. Tím se zajistí, že auditní a strukturované log záznamy odráží URL, kterou klient skutečně odeslal, nikoli artefakt po-zpracování. Regresní test pokrývá kontrakt zachování URL.
• Stahování binárních souborů — ArrayBuffer a odložené odvolání URL — Stahování certifikátů a binárních souborů agentů nyní používá typ odpovědi arraybuffer a oddaluje odvolání object URL dokud stahování není spolehlivě doručeno do prohlížeče, čímž se eliminuje race condition na pomalých připojeních, kde odvolání proběhlo dříve než dokončení stahování.

Aktualizace závislostí

• form-data a hasown — Aktualizovány balíčky form-data a hasown na nejnovější patch vydání, řeší drobná upozornění na kompatibilitu s aktuálními verzemi Node.js runtime.

---

Verze 1.0.47

Datum vydání: 2026-06-14

Nové funkce

• Sdílené Entra rollout akce a readiness kontroly — Rotace Entra přihlašovacích údajů nyní podporuje seřazené rollout akce nad sdílenou rotační platformou, včetně Azure Key Vault, Kubernetes Secretů, agentem spravovaných runtime souborů, Spring refresh a webhook doručení a recycle IIS app poolu na Windows cílech. Dry-run a preflight kontroly validují stejné runtime cesty ještě před produkčním execution.
• Per-certifikátová politika obnovy klíče — Operátoři nyní mohou pro každý certifikát určit, zda obnova vygeneruje nový privátní klíč, nebo pokud to provider a custody cesta dovolí, znovu použije stávající klíčový materiál. Pořadí zpracování rotačních cílů je nově zachováno explicitně v renewal workflow.
• Silnější validace autentizační konfigurace Entra integrace — Integration Wizard i backend nyní společně validují interaktivní a background Entra autentizační nastavení, takže už nelze uložit konfiguraci, která by nefungovala pro background sync, dry-run nebo post-rotation execution.

Vylepšení

• Sjednocený pohled na readiness v Project Rotations — Pohled Project Rotations nyní zobrazuje inline readiness a preflight stav pro Entra přihlašovací údaje, zdroje obnovy certifikátů i deployment zdroje certifikátů, včetně čitelnějšího surfacování stavů manual review required u rollout cílů, které nelze ověřit automaticky.
• Sladění rolí a kontraktů pro rotační operace — RBAC migrace a permission kontroly na projektových surface byly sladěny s rozšířenými rotačními a konfiguračními workflow, takže se snižuje počet situací, kdy operátor otevře obrazovku bez oprávnění potřebných k dokončení akce.
• Obnova Swaggeru a provozních signálů — Generovaný Swagger nyní odráží rozšířenou slovní zásobu severity stavů a lepší práci s host konfigurací, zatímco kontroly zdraví certifikátů a databáze vracejí přesnější diagnostiku pro rotation readiness a exportní cesty.
• Obnovený kontrakt Secret Rotation API — Secret rotation API i generovaný Swagger nyní přesněji popisují explicitní lifecycle create/edit/delete, včetně perzistence post-rotation akcí a čisté reset cesty po odstranění rotace secretu.

Opravy chyb

• Konzistentní cleanup Entra lifecycle záznamů — Smazání Entra integrace nebo lokálně spravované registrace aplikace nyní ve stejné lifecycle operaci odstraní i související rotační zdroje Entra přihlašovacích údajů. Upgrade migrace 000155 navíc odstraňuje historické osiřelé řádky a repository čtení obranně skrývá zastaralé entra_credential záznamy, které cleanup předcházely.
• Výchozí chování rotace certifikátů po importu — Pokud je importovaný certifikát způsobilý pro spravovanou obnovu, MazeVault nyní připraví rotační konfiguraci bez tichého zapnutí automatizace. Počáteční lead days se navíc určují z efektivní politiky certifikátu, šablony a CA účtu místo přepsání modelovým defaultem.
• Robustnější validace rolloutu a exportu — Validace kroků s agent_id versus přímým agent_url je přísnější a exporty certifikátů nyní vracejí čitelnější chyby pro PFX a soukromé klíče místo částečně maskovaných selhání.
• Mazání a znovuvytvoření secret rotace — Smazání secret rotace nyní odstraní rotační konfiguraci, kanonický secret rotation resource i navázané rotační integrace, aniž by smazalo samotný secret. Po smazání zobrazují secretové status surface stav Rotation not configured a opětovné otevření modalu zůstává v create režimu, dokud operátor explicitně neuloží novou konfiguraci.

---

Verze 1.0.46

Datum vydání: 2026-06-09

Nové funkce

• Základ pro External CA Order Poller — MazeVault přidal background polling pro externě vydávané objednávky certifikátů, takže asynchronní workflow třetích stran mohou dokončit issuance a propsat změnu do životního cyklu certifikátu bez ručního sledování.

Poznámky

• Upřesnění release notes — Entra rotation rollout, sjednocení UI rotace certifikátů a související readiness a preflight práce, které byly dříve rozepsané pod v1.0.46, byly dokončeny až po tagu a jsou proto zdokumentovány pod v1.0.47.

---

Verze 1.0.45

Datum vydání: 2026-06-09

Nové funkce

• Registr rotačních zdrojů a rozšíření platformního vlastnictví — Rotační platforma se rozšiřuje z certifikátové orchestrace na model zdrojů postavený nad registry. Nové control-plane služby zavádějí druhy zdrojů, registry cílů a sdílené vlastnictví plánování rotací, takže budoucí rotace secrets, certifikátů i Entra přihlašovacích údajů budou stát na stejných platformních primitivech.
• Discovery policy bundle pro agenty a perzistentní index konfigurací — Agenti nyní dostávají discovery policy bundle generovaný backendem z aktivních konfiguračních šablon. Filesystem discovery ukládá lokální metadata index a znovu používá kešované nálezy konfigurací i certifikátů mezi běhy, aniž by se ztrácela autorita změn politik.
• Odesílání výsledků konfigurační discovery — Agenti nyní umí odesílat výsledky discovery konfigurací zpět do backendu včetně klasifikace a metadat rewrite plánu s využitím stávajícího modelu discovery výsledků.
• Deduplikace kódů certifikátových šablon a řešení konfliktů — Správa certifikátových šablon na úrovni organizace nyní deduplikuje kódy šablon a blokuje nejednoznačné konflikty. Migrační krok zároveň normalizuje existující duplicity, aby routování šablon a issuance zůstaly deterministické.
• Klasifikace systémových certifikátů — Certifikáty nyní nesou příznak is_system pro interní mTLS a identity-management materiál. MazeVault tyto certifikáty může nadále používat interně, aniž by se míchaly do běžného operátorského inventáře.
• Integrační skupiny — Projekty nyní podporují pojmenované integrační skupiny mapující logická seskupení na integrační cíle se strukturovanou JSONB konfigurací. Skupiny lze vytvářet, prohlížet, aktualizovat a mazat prostřednictvím nových API endpointů /api/v1/projects/{id}/integration-groups a /api/v1/integration-groups/{id} (migrace 000152).
• Reálné Slack notifikace incidentů — Správa incidentů nyní odesílá real-time Slack notifikace prostřednictvím nakonfigurovaného Incoming Webhooku. Při vzniku incidentu u projektu s aktivní Slack integrací platforma odešle typ incidentu a název zdroje do nakonfigurovaného kanálu.
• Testy konektivity GCP Secret Manager a Kubernetes — Kontroly zdraví integrace nyní ověřují živé připojení k GCP Secret Manager API (výpis secrets v daném projektu) a dosažitelnost Kubernetes API serveru pomocí in-cluster nebo kubeconfig přihlašovacích údajů, doplňují tak stávající testy providerů.
• Operace s klíči HSM — HSM provideři (PKCS#11, AWS CloudHSM, GCP Cloud HSM, Azure Managed HSM) nyní poskytují úplné lifecycle operace s klíči: GetPublicKey (rekonstruuje RSA/EC PKIX DER z hardware), DeleteKey (zničí všechny objekty klíče na zařízení), ListKeys (výpis všech spravovaných key handle) a GetKeyInfo (vrací typ, velikost a příznak exportovatelnosti klíče).
• Vault PKI – úplný lifecycle — HashiCorp Vault CA provider nyní implementuje kompletní CA rozhraní: RenewCertificate, GetCertificateStatus (kontrola časového razítka revokace), ListIssuedCertificates (výpis přes PKI list endpoint), GetOrderStatus a CancelOrder (revokuje podkladový certifikát).
• ADCS – načtení odloženě vydaného certifikátu — ADCS (WCCE) provider nyní načítá certifikáty vydané CA asynchronně prostřednictvím SOAP Renew požadavku. Dříve nevyřízené certifikáty jsou po dokončení issuance načteny a vráceny ve formátu PEM.
• Venafi VaaS – úplný lifecycle — Venafi CA provider nyní implementuje RenewCertificate, GetOrderStatus (načítá stav pick-up z VaaS) a CancelOrder.
• Hlášení rate limitů DigiCert — Provider DigiCert nyní dotazuje živé rate limit hlavičky (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) a zpřístupňuje je přes rozhraní GetRateLimits.
• Injekce konfigurací s živými hodnotami secretů — Verzování konfigurací nyní při vytváření snapshotu nahrazuje tokeny ${VAULT:<placeholder>} skutečnými hodnotami MazeVault secretů, takže injektované konfigurační soubory obsahují reálné přihlašovací údaje, aniž by byly ukládány do historie verzí konfigurace.

Vylepšení

• Projektově vázané politiky viditelnosti zdrojů — Azure discovery endpointy nyní aplikují filtrování resource_visibility_policy v kontextu vybraného projektu. Výběr v Integration Wizardu tak odpovídá scope projektu i pro ne-admin operátory.
• Auditovatelnost správy konfigurace — Workflow správy konfigurace nyní zaznamenávají auditovatelné aktivity rewrite plánů, takže provozní změny jsou dohledatelné stejně jako ostatní lifecycle události platformy.
• Metadata generovaného CSR a custody klíče — Certificate request flow nyní nese metadata o generovaném CSR a custody soukromého klíče dál do dalších lifecycle kroků, takže je zřejmé, zda MazeVault klíč vlastní, znovu používá, nebo musí zachovat externí správu.
• Delegovaný krok synchronizace secretu přes agenta — Rotační a execution pipeline nyní mají explicitní krok synchronizace secretu přes agenta, což zlepšuje soulad mezi platformní orchestrací a tím, co agent skutečně aplikuje na cílových systémech.
• Navigace certifikátů na vlastnické surface — Odkazy na certifikáty z hlavního dashboardu, projektových rotací i certifikátového inventáře nyní vedou přímo na vlastnickou surface. Projektové certifikáty otevírají detail v projektu, zatímco nezařazený inventář otevírá Discovered Certificates přes lookup podle managed_certificate_id, čímž se nahrazuje duplicitní legacy flow /certificates.
• Konzistence dat na Secrets Dashboardu — Záložka Secrets Overview nyní používá sdílené dashboard API, znovu zpřístupňuje drill-in pro chybějící secrets a drží overview počty i dešifrované názvy v souladu s hlavní dashboard datovou vrstvou.
• Filtr lookupu objevených certifikátů — Discovery API a generovaná Swagger dokumentace nyní podporují filtrování podle managed_certificate_id, což umožňuje cílené deep linky z certifikátových přehledů na odpovídající discovered certificate záznam.

Opravy chyb

• Převzetí vlastnictví plánování rotací — Scheduling obnov se přesouvá pod sdílený model platformního vlastníka rotací, aby navazující workflow pracovaly s aktuálním certifikátovým zdrojem místo zastaralých anchorů před obnovou.
• Konzistence project contextu v discovery — Integration discovery helpery nyní konzistentně předávají project context, čímž mizí prázdné nebo příliš široké Azure discovery výsledky při zapnutém filtrování viditelnosti zdrojů.
• Autentizace Detect Drift — POST /api/v1/secrets/drift/detect se nyní vykonává uvnitř autentizované secrets route group, což opravuje 401 chyby způsobené chybějícím auth kontextem při detekci driftu.
• Regrese dashboard drill-in odkazů — Opraveny zastaralé odkazy na certifikáty mířící na odstraněnou globální stránku certifikátů a obnoveny odkazy na chybějící secrets v Secrets Dashboard overview.

---

Verze 1.0.44

Datum vydání: 2026-05-25

Nové funkce

• Post-akce po rotaci certifikátu — Rotace certifikátů nyní podporuje explicitní řetězení post-rotation akcí včetně webhooků a dalších registrovaných post-processing kroků, takže po úspěšné obnově nebo deploymentu lze spustit navazující refresh a rollout workflow.
• Delegovaná obnova a publish kontroly rotace — Orchestrace obnov získala delegované execution cesty, runtime probe validace a publish-gate ochrany, které lépe oddělují readiness validaci od side-effecting deployment práce.
• Lifecycle enforcement Archive Centeru — Obnova z archivu a permanentní mazání jsou nyní chápány jako centralizované archive-lifecycle operace s admin-only vynucením v runtime RBAC i při editaci rolí.
• Rozšířené pokrytí binárek agentů — Distribuce MazeVault agentů nyní zahrnuje širší ARM64 pokrytí a silnější build validaci pro heterogenní Windows i Linux prostředí.

Vylepšení

• Sledování key custody u objevených certifikátů — Adoptované discovered certifikáty nyní zachovávají explicitní stav key custody, takže MazeVault tiše nepřebírá vlastnictví privátních klíčů během obnovy nebo deploymentu.
• Vyšší robustnost issuance a renewal certifikátů — Flows vydávání certifikátů, zpracování CSR a obnov nyní používají silnější locking, normalizované post-action payloady a jasnější actor attribution napříč cross-project secret operacemi.
• Širší pokrytí providerů pro CA účty — Správa CA účtů a EAB přihlašovacích údajů nyní pokrývá více inicializačních cest providerů včetně Smallstep fallback polí používaných při zakládání a validaci účtu.

Opravy chyb

• Inicializace Smallstep CA účtu — Vytváření Smallstep CA účtu nyní správně fallbackuje na credential pole jako server_url a metadata provisioneru místo selhání ještě před kontaktem s CA.
• Sladění kontraktu rotačních akcí — Certificate post-action handling nyní nabízí jen typy akcí podporované certificate rotation executorem, takže se v UI neobjevují neplatné volby a nesoulad názvů kroků.

---

Verze 1.0.43

Datum vydání: 2026-05-11

Nové funkce

• Podpora Managed Identity pro Azure Key Vault — Integrace Azure Key Vault nyní podporují Managed Identity a Workload Identity jako způsob autentizace vedle Service Principal. Při výběru Azure Key Vault v průvodci integrací se metoda autentizace pro synchronizaci na pozadí automaticky nastaví na managed_identity. Konkrétní klientské ID managed identity nastavte přes AZURE_MANAGED_IDENTITY_CLIENT_ID, nebo proměnnou ponechte prázdnou — platforma identitu rozpozná z prostředí (AZURE_FEDERATED_TOKEN_FILE + AZURE_CLIENT_ID + AZURE_TENANT_ID pro workload identity).
• Instalace agenta jako systemd služba — Instalační skript agenta nyní nasazuje MazeVault agenta jako správnou systemd službu. Automaticky se vytvoří dedikovaný systémový uživatel mazevault-agent a adresáře se omezujícími oprávněními (/etc/mazevault, /var/lib/mazevault, /var/log/mazevault) s vlastnictvím a právy 0750. Služba je nakonfigurována s automatickým restartováním při selhání. Stávající nasazení by měla znovu spustit deployment skript pro získání aktualizované service unit.
• Endpoint pro stažení binárního souboru agenta — Nový endpoint vázaný na deployment GET /deployments/:id/agent-binary obsluhuje binární soubor agenta pro dané nasazení. UUID deploymentu slouží jako autentizační token (náhodný 128-bitový identifikátor, který nelze uhodnout), shodně s endpointy /script a /config. Starší pravidla přepisu pro stahování agenta v reverzní proxy byla odstraněna.
• Podpora více endpointů Redis — Správa Redis připojení nyní podporuje konfiguraci více adres endpointů pro nasazení s vysokou dostupností a záložním přepínáním. Primární endpoint se konfiguruje přes REDIS_URL, záložní adresy přes REDIS_FALLBACK_URLS (oddělené čárkou, středníkem nebo novým řádkem). Klient automaticky přechází na další dostupný endpoint při výpadku, a pokud jsou nedostupné všechny Redis endpointy, přepne se na in-memory fallback.
• Politika složitosti hesel v nastavení organizace — Nastavení organizace nyní obsahuje vyhrazený editor Politiky složitosti hesel. Pravidla jsou vynucována při změně hesla (minimální délka, požadavky na třídy znaků, hloubka historie). Při upgradu jsou organizace automaticky migrovány ze zastaralého pole secret_complexity_policy.

Vylepšení

• Historie rotace Entra přihlašovacích údajů — Operace rotace Entra ID přihlašovacích údajů nyní vytvářejí trvalý záznam historie rotace pro každou událost. Historie zachycuje typ rotace, staré a nové identifikátory klíčů, workflow a execution ID, průběh po krocích, finální stav, případné chybové detaily a trvání. Umožňuje plnou sledovatelnost životního cyklu rotace Entra přihlašovacích údajů.
• Sladění RBAC oprávnění — Oprávnění rolí aktualizována dle dohodnuté produktové politiky:
  • secret_manager — přidáno keytab:read a config:read (stránky Správa KeyTab a Správa konfigurace jsou nyní přístupné)
  • certificate_manager — přidáno config:read (stránka Správa konfigurace je nyní přístupná)
  • auditor — odebráno keytab:read (Správa KeyTab již není viditelná pro auditní role; pro auditní přístup ke KeyTab přiřaďte explicitně oprávnění keytab:read)
• Rozšíření typů referencí admin přihlašovacích údajů — Admin přihlašovací údaje k databázi nyní podporují dva nové typy referencí: mazevault (přihlašovací údaje uložené jako MazeVault spravované tajemství) a external (obecné externí reference). Úplná sada podporovaných typů: internal, mazevault, external, keyvault, aws_sm.
• Asynchronní seedování synchronizace tajemství s přehledem stavu — Operace seedování synchronizace nyní běží asynchronně a ihned vrací odkaz na průběh s detailním přehledem stavu (tajemství vytvořena, aktualizována, přeskočena, selhala). Zablokované seed incidenty jsou nyní zobrazeny na stránce Řešení konfliktů.
• Vydávání certifikátů propojeno s agentem — Certifikáty vydané registrovanému agentovi jsou nyní při vydání propojeny se záznamem vydávajícího agenta, čímž je životní cyklus certifikátu propojen s agentem v dashboardu a rotační orchestraci.
• Bezpečnostní vylepšení — obsluha bootstrap a KeyTab — Handlery pro aktualizaci a mazání KeyTab nyní vynucují kontrolu vlastnictví organizace (ochrana proti IDOR): přístup ke KeyTab patřícímu jiné organizaci vrátí 404. Endpoint pro změnu hesla při bootstrapu je uzamčen po dokončení prvotního bootstrapu a odmítá další volání s kódem 403 Forbidden. Do CI pipeline byl přidán DAST (Dynamic Application Security Testing) workflow.
• Aktualizace kontaktu pro obnovu licence — Kontaktní e-mail pro obnovu licence je nyní info@mazevault.com ve všech notifikačních bannerech a modalech exspirace.

Opravy chyb

• SSO Provider Modal: zachování ID poskytovatele při uložení — Opravena chyba, při níž uložení stávající konfigurace SSO poskytovatele způsobilo ztrátu ID poskytovatele, což vedlo k vytváření duplicitních poskytovatelů při dalším uložení.
• Zpětné doplnění politiky složitosti hesel — Organizace, které měly nakonfigurovanou politiku složitosti tajemství přes starší pole secret_complexity_policy, byly chybně vyhodnoceny jako nemající žádnou politiku hesel, což způsobovalo falešná selhání kontrol souladu s PCI-DSS 8.3. Politika je nyní při upgradu automaticky propagována do vyhrazeného pole politiky složitosti hesel. Organizace bez jakékoliv nastavené politiky navíc při upgradu obdrží bezpečnou výchozí politiku (minimálně 16 znaků, všechny třídy znaků povinné, historie 10 hesel, rotace každých 30 dní).

---

Verze 1.0.42

Datum vydání: 2026-05-11

Nové funkce

• Metadata certifikátů — Certifikáty nyní podporují tři uživatelsky editovatelné pole metadat dostupná z detailu certifikátu a přes PUT /api/v1/certificates/:id:
  • Tagy — Volně zadávatelné textové štítky pro seskupování a filtrování certifikátů. Tagy nastavené při importu jsou nyní uloženy a zůstávají editovatelné po importu. Odešlete prázdné pole pro smazání všech tagů.
  • URL dokumentace — Volitelný odkaz (http/https) na externí dokumentaci, runbooky nebo záznamy CMDB pro certifikát. Maximálně 500 znaků.
  • Poznámky — Krátká volně editovatelná anotace (maximálně 256 znaků). Odešlete prázdný řetězec pro smazání poznámky.
  • Všechny změny metadatových polí jsou zaznamenány do auditního logu.

Vylepšení

• Vynucení kanonizace prostředí při vytváření úkolů — Vytváření gateway úkolů nyní vynucuje kanonizaci slugů prostředí. Všechny gateway úkoly jsou ukládány s malými písmeny slugů prostředí bez ohledu na velikost písmen volajícího, navazujíc na kanonizační infrastrukturu zavedenou ve v1.0.41. Proměnná MAZEVAULT_ENV_CANONICAL_ENFORCE (nastavením na true se přejde do fail-closed režimu pro nekanonické vstupy) platí pro vytváření úkolů od tohoto vydání.

---

Verze 1.0.41

Datum vydání: 2026-04-26

Vylepšení

• Synchronizace dokumentace — Komplexní aktualizace dokumentace pro soulad s kódovou základnou v1.0.41. Reference proměnných prostředí rozšířena o pět nových sekcí: Registrace licence/organizace, Režim Orchestrátora, ACME DNS-01, Správa KeyTab a Proxy binárních souborů agenta. Všechny stávající sekce doplněny o dosud chybějící proměnné.
• Opraven název proměnné Office 365 — Opraven nesprávný název proměnné O365_ENABLED → O365_EMAIL_ENABLED v celé dokumentaci. Zdokumentována kompletní konfigurace autentizace Office 365 (metody: client secret, certifikát a managed identity).
• Reference API pro KeyTab — Zveřejněna kompletní dokumentace API pro všech 14 endpointů správy KeyTab. Viz API pro KeyTab.
• Reference API pro reporty — Zveřejněna kompletní dokumentace API pro týdenní reporty exspirace. Viz API pro reporty.
• Synchronizace verze platformy — Všechny stránky dokumentace aktualizovány tak, aby odrážely aktuální verzi platformy.

---

Verze 1.0.40

Datum vydání: 2026-04-25

Nové funkce

• Vynucení nonce OIDC — Nový příznak MAZEVAULT_ENFORCE_OIDC_NONCE povoluje přísné ověření nonce v OIDC tokenech. Při nastavení na true jsou tokeny bez platného nároku nonce odmítnuty, což chrání před útoky opakovaným přehráním tokenu. Doporučeno pro všechna produkční prostředí.
• Řízení trust store agenta — Nové proměnné prostředí MAZEVAULT_AGENT_INSTALL_CHAIN_TO_TRUSTSTORE a MAZEVAULT_AGENT_TRUST_STORE_PATH řídí, zda agent MazeVault nainstaluje interní řetězec CA do systémového úložiště důvěryhodných certifikátů a umožňují přepsat výchozí cestu trust store na Linuxu.

Vylepšení

• Stav synchronizace cílů rotace certifikátů — GET /api/v1/certificates/:id/targets/:targetId/status nyní vrací úplné detaily výsledků každého kroku, což usnadňuje diagnostiku neúspěšných synchronizací cílů.
• Stabilita registrace gateway — Vylepšená logika opakování pro výměnu bootstrap tokenů snižuje počet neúspěšných registrací způsobených přechodnými síťovými problémy při prvním nastavení gateway.
• Validace URL OCSP — Proměnná OCSP_URL nyní ověřuje formát URL při spuštění, aby se zabránilo tichému selhávání OCSP v důsledku špatné konfigurace.

Opravy chyb

• Opravená rezoluce AGENT_VERSION=latest, aby vždy načítala nejvyšší označenou verzi namísto nejnovějšího commitu.
• Opraveno překrývání zobrazení v modalu importu certifikátů v režimu Orchestrátora při současné viditelnosti sekcí keytab i soukromého klíče.

---

Verze 1.0.39

Datum vydání: 2026-04-22

Nové funkce

• Řízení distribuce binárních souborů agenta — Nové konfigurační proměnné umožňují podrobné řízení distribuce aktualizací agenta. AGENT_ROLLOUT_PERCENTAGE omezuje, které procento agentů dostane notifikaci o aktualizaci (0–100), což umožňuje postávkové zavedení. AGENT_MAX_CONCURRENT_DOWNLOADS omezuje paralelní stahování binárních souborů.
• Proxy binárních souborů agenta — MazeVault nyní může zprostředkovávat stahování binárních souborů agenta z privátního repozitáře GitHub, čímž odpadá požadavek na přímý přístup hostů agenta k veřejnému GitHub Releases. Konfigurujte přes AGENT_BINARY_GITHUB_TOKEN, AGENT_BINARY_CACHE_DIR, AGENT_DOWNLOAD_BASE_URL a AGENT_VERSION.
• Semenáření prostředí primárního backendu — Nová proměnná MAZEVAULT_PRIMARY_ENVIRONMENTS před-nasévá seznam prostředí obsluhovaných přímo primárním backendem při prvním spuštění, což zjednodušuje počáteční konfiguraci nasazení s více prostředími.

Vylepšení

• Obnovování dashboardu KeyTab — Opraven graf souladu šifer, který se neaktualizoval po importu keytabu se zastaralými šiframi.
• Spolehlivé vícekanálové doručení týdenního reportu — Opravena podmínka plánovače, která mohla tiše vynechat jeden doručovací kanál při současném povolení více kanálů.

Opravy chyb

• Opravena chyba, kdy časové razítko heartbeatu gateway nebylo správně aktualizováno po obnovení ze síťové partice.

---

Verze 1.0.38

Datum vydání: 2026-04-19

Nové funkce

• Správa KeyTab — kompletní životní cyklus Kerberos — Enterprise správa Kerberos KeyTab souborů s kompletní podporou životního cyklu. Import, discovery a správa keytab souborů napříč infrastrukturou. Klíčové schopnosti:
  • Import a parsování — Import MIT Kerberos v2 keytab binárních souborů s automatickou extrakcí principálů, realmů, verzí klíčů (KVNO) a šifrovacích typů. Podporuje nahrání v base64 kódování.
  • Discovery agentem — Agenti automaticky objevují .keytab soubory na spravovaných hostech, hlásí cestu k souboru, oprávnění, vlastníka a otisk šifrovacího typu. Objevené keytaby lze importovat do spravovaného inventáře jedním kliknutím.
  • Vynucování šifrovacích politik — Definujte šifrovací politiky na úrovni organizace s povolenými a zastaralými šifrovacími typy Kerberos. Tři režimy vynucení: audit (pouze reportování), warn (povolit s varováním), block (zakázat neshody). Výchozí politika blokuje starší šifry (DES, RC4-HMAC) a povoluje moderní AES a Camellia.
  • Historie verzí — Všechny aktualizace keytabů vytvářejí neměnitelné záznamy verzí se sledováním důvodu změny pro plný auditní soulad.
  • Dashboard a analytika — Vyhrazený dashboard KeyTab zobrazující celkový/aktivní/exspirovaný počet, rozpad souladu s šiframi (vyhovující/varování/kritický), prognózy exspirace a distribuci typů šifer.
  • Podpora režimu Orchestrátora — V režimu Orchestrátora se binární data keytab odesílají do externího poskytovatele; lokálně se ukládají pouze metadata.
• Týdenní report exspirací — Automatické týdenní reporty zobrazující certifikáty a secrets exspirující do 60 dnů, doručované na více kanálů současně:
  • Email — HTML formátovaný report na konfigurovaný seznam příjemců
  • Slack / Microsoft Teams — Notifikace přes webhook se souhrnem exspirací
  • JIRA — Automatické vytvoření úkolu s detaily exspirace pro sledování
  • Generický webhook — HTTP POST s kompletním payloadem reportu pro vlastní integrace
  • Reporty lze před odesláním zobrazit jako náhled a spustit ručně na vyžádání.
• Registrace lokální gateway — Primární backend se nyní může zaregistrovat jako lokální gateway, což umožňuje jednotné UI správy gateway pro lokální i vzdálené gateway. Unikátní omezení zajišťuje pouze jednu lokální gateway na nasazení.

Vylepšení

• Podpora více prostředí na gateway — Gateway nyní mohou obsluhovat více prostředí současně, čímž se odstraňuje předchozí omezení jedna-gateway-na-prostředí.
• RBAC oprávnění pro reporty — Nová oprávnění report:read a report:write poskytují jemné řízení přístupu k reportovacímu systému. Všechny standardní role (User, Certificate Manager, Secret Manager, Auditor) získávají report:read; Admin a Project Admin navíc získávají report:write.
• RBAC oprávnění pro KeyTab — Nová oprávnění keytab:read, keytab:write, keytab:delete a keytab:admin řídí přístup ke správě keytabů. Standardní uživatelé a auditoři získávají přístup pro čtení; operátoři a org admini získávají zápis a mazání; org admini navíc získávají admin přístup pro správu politik.

Opravy chyb

• Čistění pravidel synchronizace Entra — Odstraněna osiřelá sync pravidla ponechaná smazanými integracemi a vyčištěna duplicitní sync pravidla pro typ poskytovatele entra_id (nyní řešeno dedikovaným Entra Sync Schedulerem). Opravuje opakující se chyby „sync failed for rule" v produkčních prostředích.

---

Verze 1.0.37

Datum vydání: 2026-04-16

Vylepšení

• Šifrování payloadu úloh gateway — Citlivé payloady úloh vyměňované mezi primárním backendem a gateway jsou nyní šifrovány v klidu v databázi. Příznak payload_encrypted na úlohách gateway zajišťuje, že JSONB payloady obsahující přihlašovací údaje a soukromé klíče jsou chráněny i v případě kompromitace přístupu k databázi.
• Exponenciální backoff fronty zápisů — Fronta zápisů pro více datových center nyní sleduje časové razítko každého pokusu o opakování, což umožňuje správný výpočet exponenciálního backoff pro neúspěšné synchronizační operace. Zlepšuje spolehlivost a snižuje zbytečnou zátěž vzdálených gateway během výpadků konektivity.

Bezpečnostní aktualizace

• Šifrování payloadu gateway v klidu — Výsledky úloh a payloady ve frontě úloh gateway jsou nyní šifrovány před uložením do databáze, čímž se uzavírá potenciální vektor expozice dat v nasazeních s více datovými centry.

---

Verze 1.0.36

Datum vydání: 2026-04-15

Nové funkce

• Databázové schéma KeyTab — Nové databázové tabulky pro správu keytab: keytabs (šifrované úložiště keytab se sledováním souladu šifer), keytab_versions (neměnitelná historie verzí), keytab_cipher_policies (vynucování šifer na úrovni organizace) a discovered_keytabs (výsledky discovery agentů s detekcí zastaralých záznamů).
• RBAC oprávnění KeyTab — Nová sada oprávnění (keytab:read, keytab:write, keytab:delete, keytab:admin) přiřazená příslušným systémovým rolím pro správu životního cyklu keytab.

Vylepšení

• Vylepšení API tokenů gateway — Vylepšená autentizace gateway s dedikovanými API tokeny a podporou bootstrapového provisioningu.
• Discovery KeyTab agentem — Agenti nyní mohou objevovat Kerberos keytab soubory na spravovaných hostech a hlásit zjištění včetně cesty k souboru, oprávnění, vlastníka, typů šifrování a SHA-256 otisku.

---

Verze 1.0.35

Datum vydání: 2026-04-14

Opravy chyb

• PEM Import — Zachování soukromého klíče — Opravena kritická chyba, kdy import PEM souboru obsahujícího řetěz certifikátů a soukromý klíč tiše zahodil soukromý klíč. Systém správně detekoval klíč při náhledu souboru, ale ztratil ho během vlastního importu, což způsobovalo selhání následných exportů do PFX/JKS. Parser PEM bundlů nyní správně extrahuje PKCS#8, RSA a EC soukromé klíče.
• Import certifikátu — Název projektu v chybových zprávách — Při importu certifikátu, který již existuje, chybová zpráva nyní obsahuje název projektu, kde se duplikát nachází (např. „certifikát již existuje … project=MůjProjekt"), což usnadňuje identifikaci konfliktů.

Vylepšení

• Viditelnost soukromého klíče v UI — Certifikáty nyní zobrazují stav soukromého klíče ve všech pohledech:
  • Seznamy certifikátů zobrazují zelenou ikonu štítu, když je uložen soukromý klíč.
  • Dashboard certifikátů zobrazuje zelenou ikonu klíče u certifikátů se soukromým klíčem.
  • Detail certifikátu zobrazuje chip indikující, zda je klíč uložen lokálně, externě, nebo není k dispozici.

---

Verze 1.0.34

Datum vydání: 2026-04-10

Nové funkce

• Discovery skupin Identity Provideru — Nový API endpoint GET /identity-providers/{id}/groups načítá skupiny přímo z nakonfigurovaného poskytovatele identity (Entra ID přes Microsoft Graph, LDAP přes adresářové vyhledávání). Podporuje filtrování pomocí vyhledávání podle názvu skupiny pro snadné mapování rolí.
• Test pokrytí Identity Provideru — Přidáno komplexní pokrytí unit testy pro CRUD operace poskytovatele identity, test-connection flow a endpointy pro discovery skupin.

Vylepšení

• JKS Export — Čistá Go implementace — Nahrazena externí závislost na keytool (JDK) nativní Go implementací pomocí keystore-go/v4. Export JKS nyní funguje v jakémkoliv prostředí bez nutnosti Java runtime, obsahuje kompletní řetěz certifikátů a má komplexní pokrytí testy.
• Autentizace Gateway API tokenem — Nová tabulka gateway_api_tokens a middleware pro autentizaci gateway-to-backend API. Gateway se nyní mohou autentizovat pomocí dedikovaných API tokenů s automatickým provisioningem při bootstrapu.
• Fronta zápisů Gateway — Přidána tabulka gateway_write_queue pro bufferování zápisových operací z gateway, což umožňuje spolehlivou synchronizaci dat v nasazeních s více datovými centry.
• Posílení bootstrapu Gateway — Vylepšený bootstrap flow gateway s rozšířenou validací, kontrolami konektivity Azure SQL a spolehlivější počáteční registrací.
• Terraform pro Azure testovací prostředí — Nová konfigurace Terraformu pro automatizovaný provisioning Azure testovacího prostředí, včetně Entra ID enterprise aplikací, Key Vaultů a Azure SQL.

Bezpečnostní aktualizace

• Middleware autentizace Gateway — Nový dedikovaný middleware validuje API tokeny gateway se správnými kontrolami scope a propagací kontextu požadavku.

---

Verze 1.0.33

Datum vydání: 2026-04-09

Nové funkce

• Endpointy pro kontrolu Azure oprávnění — Přidány nové API endpointy pro validaci přístupů a viditelnosti zdrojů v Azure:
• POST /api/v1/admin/azure/mi-permissions-check
• GET /api/v1/azure/user-permissions-summary
• GET /api/v1/azure/subscriptions/{subscriptionId}/sql-servers
• Validace oprávnění Managed Identity — Nový kontrolní tok Managed Identity ověřuje přístup ke konfigurovaným Azure integracím a vrací stav po jednotlivých integracích.
• Souhrn uživatelských oprávnění — Přidán konsolidovaný přehled Azure zdrojů viditelných pro přihlášeného uživatele na úrovni subscription, včetně Key Vault a SQL server discovery.

Vylepšení

• RBAC integrace pro Azure permission checks — Endpointy kontroly Azure oprávnění jsou nyní chráněné MazeVault RBAC pomocí guardů integration:read a integration:write.
• Pokrytí Swagger schémat — Definice OpenAPI nyní obsahuje response modely pro Azure permission check (MIPermissionsCheckResponse, MICheckResult) pro přesnější generování API klientů.

Bezpečnostní aktualizace

• Sjednocení oprávnění rolí — Migrace 000109_add_audit_settings_permissions přidává oprávnění audit:read a project:write rolím certificate_manager a secret_manager pro konzistentní chování řízení přístupu.

---

Verze 1.0.32

Datum vydání: 2026-04-08

Nové funkce

• Integrace Azure Managed HSM — Plná podpora pro ukládání a manipulaci klíčů v Azure Managed HSM s automatickými aktualizacemi certifikátů a rotací klíčů. Všechny operace se soukromými klíči se provádějí v HSM s metadaty vrácenými do databáze.
• Zásady hesel na úrovni organizace — Definujte pravidla pro vynucování hesel (minimální délka, složitost, doba platnosti) pro všechny uživatele organizace. Pravidla se vynucují při vytvoření a změně hesla s kompatibilitou pro staré integrace.

Vylepšení

• Výkon synchronizace CRDT — Optimalizované řešení konfliktů pro datasety >100k záznamů, zlepšení rychlosti o 40% na setupech s více datovými centry.
• Rozšířené auditní protokoly — Komplexní zaznamenávání všech operací týkajících se hesel, certifikátů a administrativních akcí.

Opravy chyb

• Opraveno časování zneplatnění cache v clusterových nasazeních.
• Vyřešena selhání synchronizace s velkými CSR transakcemi.

---

Verze 1.0.31

Datum vydání: 2026-04-07

Nové funkce

• Režim Orchestrátora — Uchovávání klíčů externě — MazeVault nyní může běžet v režimu, kde jsou všechny soukromé klíče a tajemství ukládány výhradně v externích úschovnách klíčů (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). Místní databáze obsahuje pouze metadata.
• Sledování souladu s licencí — Dashboard zobrazuje stav licence v reálném čase, včetně použitých licencí, nadcházejících vypršení a stavů varování.

Vylepšení

• Migrace ze standardního režimu do režimu Orchestrátora — Nové příkazy CLI pro bezpečnou migraci existujících systémů v standardním režimu do režimu Orchestrátora.
• UI režimu Orchestrátora — Přepínač v průvodci onboardingem a v nastavení organizace.

Opravy chyb

• Opraveno selektivní kopírování certifikátů v režimu Orchestrátora.

---

Verze 1.0.30

Datum vydání: 2026-04-07

Nové funkce

• ACME Server — plná implementace RFC 8555 — MazeVault nyní funguje jako plně kompatibilní ACME certifikační autorita. Jakýkoliv standardní ACME klient (cert-manager, Certbot, acme.sh, Kubernetes) může přímo od MazeVault získávat a obnovovat certifikáty bez manuálního zásahu. Podporované typy výzev: HTTP-01, DNS-01, TLS-ALPN-01.
• External Account Binding (EAB) — Registrace ACME účtů lze omezit pouze na autorizované klienty pomocí předsdílených EAB přihlašovacích údajů (HMAC). Zabraňuje neoprávněnému vydávání certifikátů neznámými ACME klienty.
• Dashboard synchronizace — Nová sekce dashboardu zobrazuje stav synchronizace v reálném čase: přehled konfigurací, aktivní konflikty a selhání synchronizace s návodem pro řešení jednotlivých položek.
• Oprávnění sync:read — Nové oprávnění sync:read umožňuje členům projektů, auditorům a držitelům rolí přístup k stavovým endpointům synchronizace bez potřeby zvýšených oprávnění.

Vylepšení

• Posílení ACME Authorization Nonce — Vyhrazená tabulka nonce (acme_server_nonces) s TTL exspirací zajišťuje přísnou ochranu replay-nonce dle RFC 8555 §6.5.
• Indexování ACME challenge tokenů — Challenge tokeny nyní využívají vyhrazený indexovaný sloupec pro validaci s O(1) dotazy místo skenování JSON, čímž se zvyšuje propustnost při vysokém objemu ACME požadavků.
• RBAC — sjednocení oprávnění synchronizace — Role project_admin, certificate_manager, secret_manager, user a auditor nyní zahrnují sync:read pro konzistentní přístup ke sync dashboard endpointům.

Opravy chyb

• Opravena race condition v přechodech stavu ACME order při souběžných finalize požadavcích.
• Vyřešen problém s pořadím vytváření ACME authz tabulek (idempotentnost migrace).

---

Verze 1.0.29

Datum vydání: 2026-04-06

Nové funkce

• Rozhraní pro správu konfigurace — Nové záložkové UI pro správu životního cyklu konfiguračních souborů: discovery YAML/JSON/INI souborů napříč prostředími, přípravná oblast pro koncepty a propagace konfigurací do produkce. Poskytuje přehled o počtu discoveredvs. spravovaných konfigurací.
• Polymorfní konfigurace rotace certifikátů — Záznamy rotace nyní podporují jak rotaci secretů, tak certifikátů v unified modelu. Pole config_type rozlišuje oba typy, čímž eliminuje samostatné tabulky workflow.
• Sledování zdroje nastavení obnovení — Každý certifikát nyní zaznamenává, zda jeho nastavení obnovení pochází z projektové šablony (template) nebo bylo nastaveno ručně (manual), což poskytuje jasnou auditní stopu pro chování rotace.

Vylepšení

• Organizační izolace žádostí o certifikáty — Žádosti o podpis certifikátů (CSR) jsou nyní vázány na organizaci původce. Pole organization_id je zpětně doplněno z projektových asociací, čímž se zabraňuje úniku CSR dat mezi organizacemi.
• Databázová schémata ACME serveru — Databázové schéma pro ACME serverový protokol (autorizační objekty a nonce tabulky) bylo připraveno pro vydání ACME serveru v 1.0.30.
• Čistění workflow rotace — Odstraněny zastaralé tabulky rotation_workflows a rotation_step_executions nahrazené unified modelem spuštění rotace.

Opravy chyb

• Opraveno přejmenování sloupce rotation_configs.next_rotation na next_rotation_at — dotazy plánovače nyní používají správný název sloupce.
• Vyřešeno omezení cizího klíče na rotation_executions.config_id, které bránilo polymorfním odkazům na konfiguraci rotace.

---

Verze 1.0.28

Datum vydání: 2026-04-05

Nové funkce

• Zásady pojmenování secretů — Definujte celoorganizační konvence pojmenování secretů pomocí regex pravidel se třemi úrovněmi vynucení: block (zakáže vytvoření), warn (povolí s varováním) a disabled (informativní). Zásady jsou spravovány jako konfigurační šablony a validovány v reálném čase při vytváření secretu.
• Dashboard souladu s pojmenováním — Nová záložka v Secrets Dashboardu zobrazuje heat mapu porušení zásad, míru souladu na úrovni jednotlivých pravidel a automaticky generované návrhy pravidel na základě existujících vzorců pojmenování secretů.
• Framework konzistence — Vytvořte skupiny konzistence pro ověření existence specifikovaných secretů ve všech požadovaných prostředích. Endpoint POST /projects/{id}/consistency/groups a záložka dashboardu povrchně zobrazují chybějící hodnoty a mezery v prostředích s podporou resolve-warning pro dokumentované výjimky.
• Výchozí nastavení zabezpečení databáze — Organizace nyní mohou konfigurovat TLS/šifrování pro databázové integrace na úrovni prostředí. Produkční prostředí výchozím nastavením vyžaduje přísné TLS (verify-full, encrypt, TCPS); neprodukční prostředí využívají permisivní výchozí nastavení. Podporovatelé: Oracle, MSSQL, PostgreSQL, MongoDB, MySQL.
• Vylepšené sdílené secrety — Sdílené secrety nyní podporují volitelnou ochranu heslem (bcrypt), recipient_email pro sledování záměru, automatické označení typu obsahu (secret nebo certificate) a atribuci zdroje rotace (source_type, source_id) pro automatizovanou distribuci po rotaci.

Bezpečnostní aktualizace

• Oprávnění RBAC pro konzistenci — Nová oprávnění consistency:read a consistency:write řídí přístup ke skupinám konzistence a řešení varování. Přiřazena rolím project_admin, certificate_manager, secret_manager, user a auditor.
• Zpřesnění role auditora — Role auditor již nemá přístup k deployment dashboardu ani obecným dashboard pohledům, čímž se role striktně zaměřuje na audit logy, správu uživatelů, stav gateway a agentů — redukuje útočnou plochu účtů pouze pro čtení.

Opravy chyb

• Opraveno ukládání zásad pojmenování secretů: zásady jsou nyní persistovány v config_management_templates místo zastaralého JSONB sloupce organizations.secret_complexity_policy.

---

Verze 1.0.27

Datum vydání: 2026-04-04

Nové funkce

• Nové role: Certificate Manager a Secret Manager — Dvě nové specializované role poskytují jemné řízení přístupu bez udělení viditelnosti napříč doménami:
• certificate_manager — Plná správa životního cyklu certifikátů, CA účtů, šablon, discovery a deploymení. Bez přístupu k secretům.
• secret_manager — Plná správa životního cyklu secretů, rotace, deploymení a integrací. Bez přístupu k certifikátům.
• Vzor autorizačního kódu SSO — Přístupové tokeny se již nepředávají přes URL parametry při SSO callbacku. Callback nyní doručuje krátkodobý kód (sso_code, 60sekundová TTL), který frontend vymění za tokeny prostřednictvím POST /auth/sso/exchange. Eliminuje se tím expozice tokenů v historii prohlížeče, serverových přístupových lozích a hlavičkách Referer. Platí pro poskytovatele SSO: Entra ID, GitHub a GitLab.
• Konsolidace mapování skupin Entra — Mapování skupin Entra ID na role jsou nyní uložena v unified tabulce group_role_mappings se sloupcem source (local nebo entra). To umožňuje konzistentní správu skupin z lokálních LDAP skupin i cloudových skupin Entra ID z jednoho rozhraní.

Bezpečnostní aktualizace

• Validace OIDC Nonce — OAuth2 stav nyní nese serverem generovaný nonce validovaný při výměně tokenu. Zabraňuje CSRF/únosu tokenu prostřednictvím cross-site OAuth substituce stavu.
• Odebrání zastaralých rolí — Starší role (operator, developer, org_admin, secret_editor, secret_viewer, certificate_admin, system_admin) byly odebrány. Stávající uživatelé s těmito rolemi byli automaticky migrováni: operator → project_admin, developer → user. Integrace používající zastaralé názvy rolí v API voláních musí být aktualizovány.
• Integrita dat uživatelských rolí — Opravena korupce primárního klíče s nulovou UUID v tabulce user_roles způsobená chybějícím hookem BeforeCreate. Byl přidán kompozitní unikátní index k zabránění duplicitním přiřazením rolí. Postižené záznamy byly zpracovány deduplikací během migrace.
• Index soft-delete emailu uživatele — Omezení unikátnosti emailu je nyní partial index (WHERE deleted_at IS NULL). Soft-smazaní uživatelé již neblokují vytvoření nového účtu ani SSO registraci se stejnou emailovou adresou.

Opravy chyb

• Opravena duplikace mapování skupin Entra po opětovném přihlášení SSO.
• Vyřešena selhání přiřazení rolí pro uživatele vytvořené prostřednictvím LDAP group sync.

---

Verze 1.0.26

Datum vydání: 2026-04-03

Nové funkce

• Vylepšení importu PFX/PKCS#12 — Vylepšený import PFX certifikátů s lepším parsováním a validací
• Opravy šablon certifikátů — Vyřešeny problémy s konfigurací šablon ovlivňující workflow enrollmentu certifikátů
• Úpravy mapování rolí — Aktualizovaná logika mapování skupin na role pro lepší SSO integraci
• Rozšíření auditních logů — Rozšířené auditní logování s dalšími typy událostí a vylepšenou sledovatelností

Bezpečnostní aktualizace

• Komplexní remediace zranitelností — Vyřešeno 18 z 24 identifikovaných zranitelností napříč všemi komponentami platformy prostřednictvím systematického skenování a aktualizace závislostí
• Oprava obejití SAML podpisu (KRITICKÉ) — Opravena kritická zranitelnost obejití XML podpisu v SAML SSO autentizačním toku (goxmldsig v1.3.0 → v1.6.0)
• Oprava HTTP/2 CONTINUATION flood (KRITICKÉ) — Vyřešena aktivně zneužitelná HTTP/2 denial-of-service zranitelnost v Kubernetes Operátoru (golang.org/x/net v0.19.0 → v0.52.0)
• Oprava obejití autorizace gRPC — Opraveno obejití autorizace gRPC přes chybějící lomítko v cestě (google.golang.org/grpc → v1.80.0)
• Opravy JOSE/JWE Denial-of-Service — Vyřešeny 3 samostatné DoS zranitelnosti v JSON Web Encryption (go-jose/v3 v3.0.0 → v3.0.4)
• Kritická oprava Node.js SDK — Eliminováno 8 kritických Handlebars.js advisories včetně JavaScript injection a prototype pollution
• Posílení bezpečnosti CI/CD — Připnutí Trivy security scanneru na konkrétní verzi (ochrana supply chain), povolení bezpečnostního skenování na všech CI událostech

Vylepšení

• Přepracování Kubernetes Operátoru — Velká aktualizace závislostí na controller-runtime v0.22.5 a k8s.io/* v0.34.3 s vylepšením kvality kódu včetně extrahovaných reconciliačních metod, konfigurovatelných intervalů obnovení, správné propagace watch a strukturovaného logování
• Oprava Terraform Provideru — Opravena chyba kompilace a aktualizovány všechny závislosti na nejnovější stabilní verze (terraform-plugin-framework v1.19.0, grpc v1.80.0)
• Vylepšení Go SDK — Přidáno pole Environment do modelu Project pro vylepšenou správu projektů
• Posílení Docker obrazů — Připnutí základního obrazu OCSP Responderu na alpine:3.21 (reprodukovatelné buildy), přepnutí Frontendu na npm ci pro deterministickou instalaci závislostí
• Sjednocení závislostí — Sjednocení golang.org/x/crypto, golang.org/x/net a dalších standardních knihoven napříč všemi 7 Go moduly na nejnovější stabilní verze

---

Verze 1.0.25

Datum vydání: 2026-04-01

Nové funkce

• Přepracování Swagger API dokumentace — Kompletní regenerace Swagger/OpenAPI dokumentace s úplným pokrytím endpointů, vylepšenými definicemi schémat a přesnými příklady požadavků/odpovědí
• Konfigurace prostředí Entra ID SSO — Nové proměnné prostředí pro konfiguraci Entra ID SSO a Azure Managed Identity v .env.example pro zjednodušené nasazení

Vylepšení

• Konfigurace LDAP a OAuth poskytovatele — Vylepšené nastavení SSO poskytovatele s lepším zpracováním LDAP bind DN a konfigurací OAuth2 flow
• Endpoint stavu emailů — Nový endpoint GET /api/v1/system/email-status pro monitorování stavu doručení emailových notifikací
• Handlery rotace certifikátů — Nové API handlery pro provádění rotace certifikátů a sledování stavu
• Vylepšení integrace agentů — Vylepšené handlery pro discovery a integraci agentů s lepším hlášením chyb
• Správa SSH klíčů — Rozšířená služba SSH klíčů s vylepšeným importem a rotačními schopnostmi

Bezpečnostní aktualizace

• Aktualizovaná autentizační služba s vylepšenou validací tokenů a správou sessions
• Vylepšený Entra ID Graph klient s dodatečnými bezpečnostními hlavičkami

---

Verze 1.0.24

Datum vydání: 2026-03-30

Opravy chyb

• Oprava Entra ID SSO — Vyřešen kritický problém s autentizací Entra ID SSO ovlivňující přihlašovací flow a obnovu tokenů
• Vyčištění kódu — Odstraněn zastaralý kód handlerů a nepoužívané endpointy mapování Entra pro čistší codebase

Vylepšení

• Aktualizované modely schématu s dodatečnými definicemi polí pro lepší integritu dat

---

Verze 1.0.23

Datum vydání: 2026-03-30

Vylepšení

• Šablony certifikátů a správa expirace — Vylepšená konfigurace šablon certifikátů s lepším sledováním expirace, optimalizacemi plánovače a lepšími indikátory stavu CA integrace
• Validace importu certifikátů — Vylepšená služba importu certifikátů s přísnější validací řetězce a lepšími chybovými zprávami
• Synchronizace SSLmarket CA — Rozšířený poskytovatel SSLmarket CA s vylepšenou synchronizací produktů a sledováním stavu certifikátů
• Rozšířené logování — Vylepšené logování napříč certifikátovými službami pro lepší troubleshooting a audit trail

Opravy chyb

• Opravena kalkulace stavu certifikátu v X.509 utility funkcích
• Vyřešeny problémy se zobrazením dashboardu pro expirující certifikáty
• Opraven modal editace certifikátu zachovávající nesprávné hodnoty při uložení

---

Verze 1.0.22

Datum vydání: 2026-03-30

Nové funkce

• Podpora multi-gateway prostředí — Nová databázová migrace a servisní vrstva pro multi-gateway nasazení s konfigurací gateway specifickou pro prostředí, monitorováním zdraví a prováděním úloh
• Monitor zdraví gateway — Real-time monitorování zdraví gateway s sledováním heartbeatu, automatickou detekcí failoveru a Prometheus metrikami
• Služba routování gateway — Inteligentní routování požadavků napříč více instancemi gateway s load balancingem a povědomím o prostředí
• Exekutor úloh gateway — Distribuovaný framework pro provádění úloh gateway s retry logikou a sledováním stavu
• Správa identity providerů — Nové API handlery pro konfiguraci a správu identity providerů

Vylepšení

• Posílení cipher key resolveru — Kompletní testovací pokrytí pro rozlišení cipher klíčů s 715+ řádky nových testů eliminujících nekonzistence duálního úložiště
• Kontroly zdraví databáze — Aktualizované očekávané tabulky a sloupce pro nové databázové schéma související s gateway
• Průvodce integrací — Nové vícekrokové UI průvodce integrací pro konfiguraci CA providerů, správců secrets a externích integrací
• Oprava derivace klíčů — Vyřešen problém s derivací klíčů ovlivňující šifrovací operace

Bezpečnostní aktualizace

• Eliminována zranitelnost duálního úložiště cipher klíčů prostřednictvím migrace 000089
• Vylepšená autentizační služba s lepší správou sessions

Opravy chyb

• Opraveny selhání testů v orchestrátoru certifikátů a službách správy konfigurace
• Vyřešen problém s přesměrováním EntraID SSO na některých konfiguracích prohlížeče

---

Verze 1.0.21

Datum vydání: 2026-03-26

Nové funkce

• Azure Resource Discovery — Nové API handlery pro discovery cloudových zdrojů Azure s enumerací Key Vault, certifikátů a secrets
• UI průvodce integrací — Vícekrokový průvodce pro konfiguraci integrací s CA providery a správci secrets, včetně výběru typu, konfigurace poskytovatele a kroků revize

Vylepšení

• Služba CA účtů — Vylepšená správa CA účtů s lepším zpracováním chyb a sledováním stavu
• Aktualizace schémat modelů — Aktualizované datové modely napříč SSH klíči, MFA, OAuth, CRL a zero-trust moduly pro lepší konzistenci a validaci
• Testovací pokrytí — Rozšířené testovací pokrytí pro poskytovatele integračních služeb, službu offloadu klíčů a operace offloadu secrets

Opravy chyb

• Opravena nekonzistence modelu audit událostí certifikátů
• Vyřešeny problémy se zarovnáním polí modelu objevených certifikátů

---

Verze 1.0.20

Datum vydání: 2026-03-23

Nové funkce

• Office365 OAuth2 emailové notifikace — Odesílání emailových notifikací přes Microsoft Graph API pomocí OAuth2 client credentials flow místo legacy SMTP; podpora 3 autentizačních metod (client secret, certifikát, managed identity); využívá existující Entra ID infrastrukturu s cachováním spojení a retry logikou; transparentní náhrada — všech 6 email trigger bodů (upozornění na expiraci, incidenty, týdenní reporty, selhání rotace, souhrny discovery, testovací notifikace) funguje automaticky; nový endpoint GET /api/v1/system/email-status a frontend status indikátor v System Outputs → záložka Notifications
• SmallStep CA poskytovatel — Integrace open-source step-ca jako backend certifikační autority s podporou provisioners JWK, X5C a OIDC; mTLS autentizace, podepisování, obnova, revokace certifikátů a podepisování CRL s ověřením otisku kořenového certifikátu; ideální pro zero-trust architektury s krátkodobými certifikáty
• Multi-target rotace certifikátů — Nasazení certifikátů na 5 typů cílů: Secret Managers (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault), Kubernetes Secrets (TLS/Opaque), Agent Keystores (JKS, PKCS12, Windows), Agent Files (PEM) a Database Wallets (Oracle OCI); výběr režimu obsahu (veřejný, veřejný+řetězec, kompletní řetězec s klíčem, pouze klíč), automatická detekce formátu, politiky opakování s konfigurovatelným počtem pokusů a prodlevami, spouštění post-install příkazů
• Enterprise Entra ID správa životního cyklu přihlašovacích údajů — Kompletní správa životního cyklu se stavy (vytvořen, aktivní, expirující, expirovaný, odvolaný, grace period), konfigurovatelná lhůta odkladu (výchozí 30 dní), sledování historie rotace se starými/novými ID klíčů a trasováním workflow, dashboard monitoringu expirace, ochrana idempotence proti duplicitním rotacím a řešení synchronizačních konfliktů lokálního vs. vzdáleného stavu
• Prohlížeč compliance reportů — Generování a zobrazení compliance reportů s formátováním na základě šablon, analýza shody certifikátů na úrovni organizace a exportovatelný výstup reportů
• Historie provádění rotace — Detailní historie rotace per certifikát s časovými značkami provádění, sledováním stavu (úspěch/selhání/čekání) a vizualizací stavu synchronizace na úrovni cíle
• Sledování fáze životního cyklu certifikátu — Nové fáze životního cyklu (stabilní, obnovování, rotace, revokace) brání duplicitním CA požadavkům během probíhajících operací; nezávislé na stavu certifikátu, certifikáty zůstávají platné během přechodů fází

Vylepšení

• Cíle audit streamů — Nový Elasticsearch cíl se správou index šablon, podpora cluster módu a CosmosDB; nový Syslog cíl s TCP/UDP transportem, podporou formátů CEF a Syslog; rozšířená služba log streamů s validací konfigurace specifickou pro jednotlivé cíle
• Vylepšení LDAP autentizace — Rozšířená LDAP služba s vylepšeným zpracováním bind DN, rozlišením členství ve skupinách, flexibilitou konfigurace schématu a lepší diagnostikou chyb připojení
• Redesign plánovače notifikací — Vylepšená logika plánování notifikací o expiraci certifikátů s podporou dávkování pro snížení zahlcení výstrahami, integrace JIRA pro vytváření incidentních tiketů a vylepšení e-mailových notifikací
• Služba týdenních reportů expirace — Přepracované generování reportů se správou příjemců, přizpůsobitelným obsahem a zlepšenou spolehlivostí doručení
• Vylepšení šablon projektů — Rozšířená konfigurace šablon s integrací konvencí pojmenování, pokročilými výchozími nastaveními a vylepšeným workflow aplikace šablony na projekt
• Služba konvencí pojmenování — Rozšířený engine konvencí pojmenování s podporou dalších vzorů, validačních pravidel a propojení konvencí se šablonami pro automatické vynucování
• Prometheus metriky — Nové histogram a counter metriky pro rotaci certifikátů, compliance reporting a monitorování výkonu audit streamů
• CI/CD pipeline — Nový GitHub Actions workflow pro automatizovaný build, testování a nasazení
• SSO Provider Modal — Přidána konfigurace LDAP poskytovatele se serverem, bind DN a nastavením schématu přímo z rozhraní konfigurace SSO
• WebLogic Deploy krok rotace — Nový typ kroku rotace pro nasazení keystore na Oracle WebLogic Server s automatickou aktualizací konfigurace domény

Bezpečnostní aktualizace

• Rotace přihlašovacích údajů Entra ID s kompletním audit trailem — každá rotace zaznamenána s aktérem, časovým razítkem, starými/novými ID klíčů a stavem provádění
• Operace SmallStep CA logovány do audit streamu s kompletními metadaty požadavku/odpovědi
• Fáze životního cyklu certifikátu brání souběžným CA operacím, eliminující race conditions ve workflow obnovy a rotace
• Detekce synchronizačních konfliktů Entra s automatickým sledováním nesrovnalostí lokálního vs. vzdáleného stavu

---

Verze 1.0.19

Datum vydání: 2026-03-20

Nové funkce

• Nasazení Azure Gateway — Multi-regionální infrastruktura Azure Gateway s Terraform moduly pro AKS, Key Vault, PostgreSQL, Redis, síťování, monitoring a správu identit; Helm chart values pro konfiguraci gateway; Azure DevOps CI/CD pipeline pro automatizované nasazení
• Key Vault RBAC služba — Granulární řízení přístupu na základě rolí pro operace Azure Key Vault s oprávněními na úrovni jednotlivých tajemství a certifikátů
• Key Vault Watch Connector — Real-time synchronizace mezi MazeVault a Azure Key Vault s detekcí změn a automatickou aktualizací tajemství
• Engine konvencí pojmenování — Doménově specifická pravidla pojmenování s wildcard pattern matchingem, řazením priorit a vynucováním na úrovni šablon pro konzistentní pojmenování zdrojů napříč projekty
• Dashboard záložka reportů — Přepracovaný dashboard reportů se statistikami přehledu certifikátů, interaktivními grafy a exportovatelnými daty reportů
• Node.js SDK — Oficiální MazeVault SDK pro Node.js s TypeScript definicemi, podpora autentizace (SRP), organizací, projektů a správy tajemství

Vylepšení

• Audit log scoping na projekt — Auditní události nyní obsahují vazbu na projekt pro efektivní filtrování per projekt a compliance reporting; existující události zpětně doplněny z vazeb entit
• Oprava storage mode pro Orchestrator Mode — Normalizovány nekonzistentní hodnoty storage mode pro nasazení Orchestrator Mode, vyřešeny porušení omezení
• Entra Group Mappings — Vylepšená spolehlivost mapování skupin na role s lepším zpracováním chyb a zpětnou vazbou v UI
• Zpevnění šifrování konfigurace — Rozšířená služba šifrování konfigurace s dodatečným pokrytím testy a vylepšeným zpracováním chyb pro okrajové případy
• Validace importu certifikátů — Vylepšená služba importu certifikátů s přísnější validací řetězce
• Aktualizace Go SDK — Aktualizované definice projektů a modelů pro konzistenci s nejnovějším API
• Aktualizace Python SDK — Zarovnání modelů s nejnovějším API schématem

Opravy chyb

• Opraveno zbytečné vytváření prostředí pro nepoužívané projekty
• Vyřešen problém s přesměrováním SSO přihlášení Entra ID na určitých konfiguracích prohlížečů
• Opraven modál šablony projektu nezachovávající vazby na prostředí při uložení

---

Verze 1.0.18

Datum vydání: 2026-03-14

Vylepšení

• Zákaznická dokumentace aktualizována — Kompletní návod pro automatizaci certifikátů pomocí ACME s postupem nastavení Kubernetes krok za krokem, příklady cert-manager ClusterIssuer, směrování ACME profilů, řešení problémů a kompletní end-to-end YAML příklady; aktualizovaná API reference certifikátů s ACME endpointy a správou EAB; poznámky k verzím přeformátovány na správné verzovací schéma 1.0.x
• Vylepšená integrace Azure Entra ID — Vylepšené zpracování obnovení tokenů, spolehlivější mapování skupin na role, rychlejší přihlašování SSO se sníženou latencí přesměrování a lepší chybové hlášky pro špatně nakonfigurovaná nastavení tenanta

---

Verze 1.0.17

Datum vydání: 2026-03-14

Nové funkce

• ACME Server (RFC 8555) — MazeVault nyní funguje jako plnohodnotná ACME certifikační autorita, umožňující automatické vydávání certifikátů přes cert-manager a další ACME klienty
• External Account Binding (EAB) — Bezpečná registrace clusterů pomocí jednorázových přihlašovacích údajů propojujících ACME klienty s organizacemi a projekty
• Směrování ACME profilů — Mapování názvů profilů cert-manageru na šablony certifikátů MazeVault pro automatický výběr CA backendu (cert-manager v1.18+)
• Pravidla domén — Konfigurace pravidel pro směrování domén na šablony s podporou wildcardů a priorit
• Automatické schválení interních domén — Certifikáty pro domény .local, .internal, .lan a .corp jsou vydány okamžitě bez HTTP-01 výzvy
• ADCS most přes ACME — Vydávání certifikátů z Microsoft Active Directory Certificate Services přes standardní ACME protokol
• Vylepšení ADCS agenta — DCOM logika opakování pro čekající žádosti o certifikáty s konfigurovatelným intervalem
• UI pro správu EAB přihlašovacích údajů — Generování, výpis a odvolání EAB přihlašovacích údajů z webového rozhraní s příklady YAML pro cert-manager

Vylepšení

• ACME directory endpoint s meta profily pro automatické vyhledávání klienty
• JWS middleware s ověřením podpisů ES256 a RS256
• Ochrana proti opakování na bázi nonce dle RFC 8555 §6.5
• Doručení kompletního PEM řetězce certifikátů pro ACME klienty
• Tabulka EAB přihlašovacích údajů se sledováním stavu (Dostupný / Použitý / Odvolaný)
• Kopírování jedním kliknutím pro URL ACME adresáře a vygenerované přihlašovací údaje

Bezpečnostní aktualizace

• EAB HMAC klíče šifrovány v úložišti pomocí AES-256-GCM
• EAB přihlašovací údaje jsou jednorázové a podporují expiraci a odvolání
• Ověření JWK Thumbprint (RFC 7638) pro vazbu účtu
• Všechny ACME operace zaznamenány v auditním logu

---

Verze 1.0.16

Datum vydání: 2026-02-28

Vylepšení

• Redesign nastavení organizací s navigací pomocí záložek
• Karty účtů certifikačních autorit se stavovými indikátory synchronizace
• Vylepšené zjišťování produktů CA a spouštění synchronizace přes UI
• Optimalizace intervalu heartbeatu agentů pro velké flotily
• Ladění pool připojení k databázi pro nasazení s vysokou souběžností

Opravy chyb

• Opravena validace řetězce certifikátů pro intermediate CA certifikáty
• Vyřešen race condition při souběžném plánování rotace tajemství
• Opravena invalidace cache OCSP responderu při revokaci certifikátu

---

Verze 1.0.15

Datum vydání: 2026-02-14

Vylepšení

• Import PFX/PKCS#12 s konfigurovatelným úložištěm klíčů (software / HSM)
• Podpora přepsání šablony certifikátu pro výchozí hodnoty na úrovni CA účtu
• Vylepšená logika opětovného připojení agenta po přerušení sítě
• Rozšířené filtrování auditního logu podle typu události a časového rozsahu

Opravy chyb

• Opraven export certifikátu s řetězcem pro cross-signed intermediate
• Vyřešeno neukládání nastavení šablony projektu po uložení
• Opravena deduplikace zjišťování SSH klíčů pro rotované klíče

---

Verze 1.0.14

Datum vydání: 2026-01-31

Vylepšení

• Vylepšení správy SSH klíčů — sledování a zjišťování autorizovaných klíčů
• Vylepšení spouštěčů rotace s ošetřením referenční integrity
• Sdílení tajemství po rotaci s automatickým přešifrováním
• Vylepšené chybové hlášky pro selhání ověření proxy agenta

Opravy chyb

• Opraveno zpracování časových zón plánovače rotace pro instalace mimo UTC
• Vyřešen nesoulad počtu certifikátů na dashboardu po hromadném importu
• Opravena kontrola expirace API tokenu pro servisní identity

---

Verze 1.0.13

Datum vydání: 2026-01-24

Vylepšení

• Modernizace React importů — optimalizované MUI importy pro tree-shaking
• Snížení velikosti frontend buildu (~15% menší bundle)
• Vylepšené vyhledávání certifikátů s wildcard SAN matchingem
• Rozšířené Prometheus metriky monitoringu s histogram buckety

Opravy chyb

• Opravena kontrola RBAC oprávnění pro vnořená prostředí projektů
• Vyřešeno formátování Terraform exportu pro komplexní hodnoty tajemství
• Opraven health check endpoint vracející zastaralý stav Redis

---

Verze 1.0.12

Datum vydání: 2026-01-17

Vylepšení

• Integrace skenování kontejnerových obrazů Trivy v CI/CD pipeline
• Remediace bezpečnostních zranitelností v řetězci závislostí
• Vylepšená konfigurace TLS cipher suite s profilem Mozilla Intermediate
• Rozšířený rate limiting s algoritmem posuvného okna

Opravy chyb

• Opraveno plánování obnovy certifikátů s vlastní platností
• Vyřešen konflikt synchronizace pro současně editovaná tajemství mezi datacentry
• Opravena validace registračního tokenu agenta pro znovu registrované agenty

---

Verze 1.0.11

Datum vydání: 2026-01-10

Vylepšení

• Monitoring zdraví připojení PostgreSQL s automatickým opětovným připojením
• Vylepšení architektury obousměrné synchronizace pro multi-region nasazení
• Opravy instalačního skriptu agenta pro air-gapped prostředí
• Vylepšení onboarding procesu pro scénáře vzdáleného nasazení

Opravy chyb

• Opraven rollback databázové migrace při selhání upgradu
• Vyřešena synchronizace LDAP skupin nereflektující změny členství
• Opravena paginace seznamu certifikátů pro projekty s > 1000 certifikáty

---

Verze 1.0.10

Datum vydání: 2026-01-03

Vylepšení

• Rozšířená detekce externích změn pro certifikáty spravované CA
• Vylepšená dokumentace hodnot Helm chartu s inline komentáři
• Dávkování notifikací o expiraci certifikátů pro snížení únavy z alertů
• Aktualizované Go závislosti s bezpečnostními záplatami

Opravy chyb

• Opraven CRDT merge pro souběžné vytváření verzí tajemství
• Vyřešena logika opakování synchronizace Azure Key Vault pro přechodné selhání
• Opraven OCSP responder vracející nesprávný stav pro obnovené certifikáty

---

Verze 1.0.9

Datum vydání: 2025-12-15

Nové funkce

• Systém šablon certifikátů — Předkonfigurované certifikátové profily pro běžné případy použití (Web Server, Client Auth, Code Signing, Email/S-MIME)
• Hromadné operace s certifikáty — Import a správa certifikátů hromadně přes PEM bundly
• Vylepšené zjišťování agentů — Automatické zjišťování certifikátů v infrastruktuře spravované agenty
• Vylepšení synchronizace — CRDT synchronizace mezi více datacentry s vylepšeným řešením konfliktů
• Export do Terraform — Export konfigurací projektů jako Terraform HCL pro infrastructure-as-code workflow

Vylepšení

• Vylepšená validace importu certifikátů a hlášení chyb
• Zvýšený výkon OCSP responderu s cachováním odpovědí
• Aktualizovaný RBAC s granulárními oprávněními pro správu certifikátů
• Vylepšené auditní logování se strukturovaným JSON výstupem
• Rozšířené endpointy kontroly zdraví se stavem na úrovni komponent

Bezpečnostní aktualizace

• TLS 1.3 jako výchozí protokol
• Vylepšená CSRF ochrana s double-submit cookie pattern
• Rozšířený rate limiting s konfigurací per endpoint
• Aktualizované kryptografické závislosti

---

Verze 1.0.8

Datum vydání: 2025-11-20

Nové funkce

• Integrace s externí CA — Propojení s DigiCert, Venafi, Microsoft ADCS a dalšími externími certifikačními autoritami
• Podpora HSM — Integrace Hardware Security Module pro ochranu klíčů (PKCS#11, Azure Managed HSM)
• ACME protokol — Automated Certificate Management Environment pro automatizované vydávání certifikátů
• Vícefaktorová autentizace — MFA založená na TOTP pro zvýšenou bezpečnost účtů

Vylepšení

• Přepracované rozhraní pro správu certifikátů
• Vylepšené plánování rotace tajemství
• Rozšířený API rate limiting
• Rozšířená integrace s Azure Key Vault

---

Verze 1.0.7

Datum vydání: 2025-09-10

Nové funkce

• Zero-Knowledge šifrování — Šifrování na straně klienta pro tajemství osobního trezoru
• Podpora SCEP protokolu — Simple Certificate Enrollment Protocol pro správu certifikátů zařízení
• Podpora EST protokolu — Enrollment over Secure Transport pro moderní registraci certifikátů
• Proxy agenta — Agenti mohou zprostředkovat přístup k tajemstvím pro lokální aplikace

Vylepšení

• Vylepšený systém databázových migrací
• Rozšířené logování a monitoring
• Aktualizované manifesty pro Kubernetes nasazení
• Vylepšení výkonu pro velká úložiště certifikátů

---

Verze 1.0.6

Datum vydání: 2025-06-15

Nové funkce

• Synchronizace více datacenter — Obousměrná synchronizace mezi instalacemi MazeVault
• Azure Entra ID SSO — Single Sign-On s Azure Active Directory
• RBAC na úrovni projektů — Granulární řízení přístupu na základě rolí per projekt
• Distribuce CRL — Automatizované generování a distribuce Certificate Revocation List

Vylepšení

• Vylepšený dashboard s aktualizacemi stavu v reálném čase
• Rozšířené vyhledávání a filtrování certifikátů
• Aktualizovaná API dokumentace se specifikací OpenAPI 3.0
• Vylepšená bezpečnost kontejnerových obrazů

---

Verze 1.0.5

Datum vydání: 2025-03-20

Nové funkce

• OCSP Responder — Real-time Online Certificate Status Protocol responder
• Verzování tajemství — Kompletní historie verzí s možností rollbacku
• Správa agentů — Centralizovaná registrace a monitoring agentů
• LDAP integrace — Podpora autentizace přes adresářové služby

---

Verze 1.0.4

Datum vydání: 2024-12-10

Nové funkce

• Interní certifikační autorita — Kompletní PKI s podporou root a intermediate CA
• Správa životního cyklu certifikátů — Žádost, schválení, vydání, obnova a revokace certifikátů
• Helm charty — Standardizované nasazení v Kubernetes přes Helm

---

Verze 1.0.3

Datum vydání: 2024-09-15

Nové funkce

• Integrace s Azure Key Vault — Synchronizace tajemství s Azure Key Vault
• Rotace tajemství — Automatizovaná a manuální rotace tajemství
• Kubernetes nasazení — AKS nasazení s Terraform

---

Verze 1.0.2

Datum vydání: 2024-06-20

Nové funkce

• Řízení přístupu na základě rolí — Uživatelské role a oprávnění
• Správa projektů — Organizace tajemství do projektů
• API v1 — Kompletní REST API pro správu tajemství

---

Verze 1.0.1

Datum vydání: 2024-03-01

Úvodní vydání

• Šifrované úložiště tajemství s AES-256-GCM
• Webové správcovské rozhraní
• PostgreSQL backend s Redis cachováním
• Docker Compose nasazení
• Lokální autentizace s SRP protokolem

---

Zásady podpory

MazeVault podporuje aktuální verzi a jednu předchozí minor verzi. Zákazníkům na starších verzích doporučujeme provést upgrade pro získání bezpečnostních aktualizací a nových funkcí.