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 0CD8D1FF136 for ; Mon, 20 Apr 2026 12:09:12 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5DD39244C6; Mon, 20 Apr 2026 12:09:11 +0200 (CEST) Message-ID: Date: Mon, 20 Apr 2026 12:08:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH proxmox/yew-pwt/datacenter-manager/installer v3 00/38] add auto-installer integration To: Lukas Wagner , Christoph Heiss , pdm-devel@lists.proxmox.com References: <20260403165437.2166551-1-c.heiss@proxmox.com> <8079685a-be9c-4e28-954c-bd1debe7ce7d@proxmox.com> <52dc9715-66dc-4dc2-a3dc-4216f62f33f2@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776679661850 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.050 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: BDBI6CGHTO6KTXLPQLTMEYWG4XDPNIZI X-Message-ID-Hash: BDBI6CGHTO6KTXLPQLTMEYWG4XDPNIZI X-MailFrom: d.csapak@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 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, here >>>> 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 root >>>> password is hashed), it still contains semi-sensitive data (email address, >>>> SSH key, FQDN, etc.). Also, since each POST creates a new entry in the >>>> installations JSON file, an unauthenticated user could abuse this to >>>> make the PDM system run out of disk space (or simply disturb operations >>>> by creating bogus entries). >>>> --- >>>> >>>> >>>> We already had the requirement for a http endpoint to be unauthenticated >>>> 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 API >>> 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? > > 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. > > 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. > >> >> IMO this boils down what we choose, neither options is more correct here. >> >> 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 > > 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. > > 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. > > 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. > 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. 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) > >> >> (for example, we allow the migration traffic to be unencrypted too, >> but only if the admin decides that) >> >> we could print a big warning that this info is publicly exposed if >> no token restriction is used, or something like this. >> >> but as i said this is more of choice, not a purely technical argument >>> >>>> >>>> also i'm not for making it unauthenticated for all responses, but >>>> make it the admins choice. >>>> >>>> as for the DOS vector of pdm, we could check if the user was >>>> authenticated, and only generate the data then. >>> >>> There is no user information available when the installer requests the >>> answer file, how would we check it? >>> >>> Sorry, maybe I'm misunderstanding your proposal here :) >>> >> >> how it currently works is that the iso must be prepared with a token, >> i'd propose leaving that in, but only as an option if the admin >> wants to do the authentication, but not as a requirement >> >> the api could check if there is a user in the rpcenv anyway and check >> their permissions against the available prepared answers >> >>>> >>>> but how much data is that really? e.g. each api call (authenticated or >>>> not) creates a new line in the access log. so with enough api calls, >>>> i can fill up the disk too... >>> >>> You're right about the access log. That being said, an unauthenticated >>> user would still be able to create bogus entries installation entries >>> that would show up in the UI. >>> >> >> btw. most of the pain with the authentication imho here comes >> from having separate api tokens just for the automated installs >> and the lack of guidance what the user should do. > > Yes, I agree, the UX can be improved at the moment. > >> >> if we e.g. can autogenerate the 'proxmox-auto-install-assistant' >> cli command with the gui and make it copyable, makes this probably >> a lot less cumbersome > > Yes, this would be a nice addition indeed. Maybe we could also explore > having the option to generate the ISO directly in PDM, so that a user > could easily get the correct ISO for a prepared answer. IMO that would be the best action (long-term) since it's the least amount of work for the admin, for a thing that can be probably easily automated. Nothing for now of course, the scope is already quite big as it is.