From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id F23061FF136 for ; Mon, 20 Apr 2026 13:18:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 754E025D3E; Mon, 20 Apr 2026 13:18:50 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 20 Apr 2026 13:18:45 +0200 Message-Id: Subject: Re: [PATCH proxmox/yew-pwt/datacenter-manager/installer v3 00/38] add auto-installer integration From: "Lukas Wagner" To: "Dominik Csapak" , "Lukas Wagner" , "Christoph Heiss" , X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty References: <20260403165437.2166551-1-c.heiss@proxmox.com> <8079685a-be9c-4e28-954c-bd1debe7ce7d@proxmox.com> <52dc9715-66dc-4dc2-a3dc-4216f62f33f2@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776683842086 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.054 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 4GMHGY72V2U2OZAW2GVER2OTOK75AR4Y X-Message-ID-Hash: 4GMHGY72V2U2OZAW2GVER2OTOK75AR4Y X-MailFrom: l.wagner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon Apr 20, 2026 at 12:08 PM CEST, Dominik Csapak wrote: > > On 4/20/26 11:52 AM, Lukas Wagner wrote: >> On Fri Apr 17, 2026 at 1:53 PM CEST, Dominik Csapak wrote: >>>>>> Check out my response to v2, which is (I think) the main reason why = it >>>>>> is implemented like it is right now: >>>>>> >>>>>> https://lore.proxmox.com/all/DETMUXY1Q877.32G593TWC52WW@proxmox.com/= T/#u >>>>>> >>>>> >>>>> ok i see, but i have some counter arguments to that, for brevity, her= e >>>>> is part of your response from that mail: >>>>> >>>>> --- >>>>> I think this is dangerous. >>>>> >>>>> While the answer-file does not leak any passwords (seems like the roo= t >>>>> password is hashed), it still contains semi-sensitive data (email add= ress, >>>>> SSH key, FQDN, etc.). Also, since each POST creates a new entry in th= e >>>>> installations JSON file, an unauthenticated user could abuse this to >>>>> make the PDM system run out of disk space (or simply disturb operatio= ns >>>>> by creating bogus entries). >>>>> --- >>>>> >>>>> >>>>> We already had the requirement for a http endpoint to be unauthentica= ted >>>>> so for a secured and protected network, this should be a non issue >>>> >>>> Yes, but I think it's a big difference if we integrate something like >>>> this into PDM natively. There will always be users who, against our >>>> recommendations, expose the PDM web interface directly to the internet >>>> or other untrusted network environments. I would very much argue >>>> against returning any kind of (semi)-sensitive information from the AP= I >>>> without proper access controls, even if it is opt-in. >>> >>> why is it different? previously we *needed* the admin to expose >>> it unauthenticated if he wanted to use, it, i proposed >>> making authentication optional, it's still a win from a security pov? >>=20 >> I'd argue it is different in the sense that PDM might be more widely >> exposed in the network than a homebrew answer-file responder. >>=20 >> By including the feature in PDM, we advertise this method of automated >> installations, and due to the sheer size of our userbase, there will >> undoubtedly be leakage at some point if we include the unauth'd version. >> If we can make this impossible with a design decision now, even at a >> slight UX penalty, I'm all for it. >>=20 >>> >>> IMO this boils down what we choose, neither options is more correct her= e. >>> >>> do we trust the admin to properly configure his environment? >>> if yes, then we can leave it up to their choice if they want to protect >>> these endpoints with a tokenA >>=20 >> If this was any other feature, would we even discuss returning sensitive >> information from the API without authentication for an usability >> improvement, even as an opt-in? I highly doubt it. >>=20 >> To me, the fact that answer-file servers were completely unauth'd before >> is not a very good reason why we should handle it the same way in PDM. >>=20 >> I think I'd rather try to make it as simple as possible to use the >> token-based solution (as you mentioned, the UX could be improved), >> and then only if there are enough requests for the less secure variant >> in the forum or BZ, consider making the unauth'd variant an (advanced) >> option. >>=20 > > After reading your response and thinking it over, i agree that it's > better to require full auth now, as long as the UX is better than it is > currently. I'm glad we could find consensus on this. Thank you for the discussion! > > Basically I'd try to reuse regular auth token, and maybe make > the cli command copyable (not sure how to handle the token > secrets here in a good way for the gui, though) Apart from the slightly increased amount of code needed to implement the feature, do you see any big draw-back from using distinct tokens for this feature? I think I wrote it in my original response for v2, the main reason why I suggested using distinct tokens is to also eliminate one source of user error. If we use regular tokens here, there will surely be a small share of users who don't want to deal with ACLs and just use a full admin-token for the ISO. Most users probably don't consider an ISO to be worth protecting, as embedding secrets is indeed a very rare thing to do. The ISO might end up on NAS shares, might be included in backups, etc., without people realizing that it contains a key to all of their infra. Also, if we add support for generating ISOs in PDM, or display the command needed to generate the ISO, we would violate our 'rule' of never returning tokens from the API, after they have been initially created, that is. >>From my point of view, both points can be solved by using distinct tokens. The first point is solved by making the new type of token unusable in any other context by design. For the second issue, I think due to the fact that the token is *only* usable in this context, we could afford to return it from the API or as a downloadable ISO, assuming the user has high-enough permissions. What do you think? Regarding the 'custom token' itself, one thing that we could do is to make the token a regular parameter on the POST call, instead of using the 'Authorization' header. This would avoid API users from being confused about why there is one API route that uses a *different* token for no clearly visible reason. Ultimately, I don't think anybody would call this endpoint except our own installer, but it would still make things a tiny bit more clear, I think.