You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yunikorn.apache.org by Craig Condit <cc...@apache.org> on 2022/10/31 23:26:56 UTC
[DISCUSS] Removal of configmap update logic via REST API
Hello everyone,
I’d like to open a discussion around the idea of removing the current logic that supports writing a new scheduler configuration via the REST API.
Currently, this logic is disabled in two different ways (and has been for several releases). First, it is turned off if config auto-refresh is enabled (the default). Second, it doesn’t work unless a non-standard and elevated set of permissions is granted to the service account running YuniKorn. This happened as part of YUNIKORN-997: Use K8s fine-grained access control for YuniKorn scheduler [1]. So, it has not been easily activated since 1.0.0 shipped.
This functionality was originally created to workaround potential delays in configmap update detection and allow for more predictable updates since it’s possible that a kubelet doesn’t refresh the on-disk copy of the configmap in a timely manner. However, this hasn’t been true by default in modern Kubernetes versions and no instances of this have been reported in quite some time, and config auto-refresh has been active by default for many releases.
Additionally, this functionality is extremely insecure, as the REST API has no security on it. Any user who can talk to the REST API could upload any configuration they want, and this was why YUNIKORN-997 disabled this functionality.
With the upcoming design for YUNIKORN-1221: Configuration V2 [2], we’d like to remove this functionality once and for all as it greatly simplifies configuration handling moving forward.
Let me know if you have any concerns,
Craig Condit
[1] https://issues.apache.org/jira/browse/YUNIKORN-997 <https://issues.apache.org/jira/browse/YUNIKORN-997>
[2] https://issues.apache.org/jira/browse/YUNIKORN-1221 <https://issues.apache.org/jira/browse/YUNIKORN-1221>
Re: [DISCUSS] Removal of configmap update logic via REST API
Posted by Weiwei Yang <ab...@gmail.com>.
+1
Sounds good. The new config consolidation also looks nice, thanks for moving this forward.
Some minor comments added to the design doc, we can discuss offline for that.
Thanks
Weiwei
> On Oct 31, 2022, at 9:08 PM, Wilfred Spiegelenburg <wi...@apache.org> wrote:
>
> +1 I am for removing this functionality just from a security point alone.
>
> The change also includes watching the configmap and reloading directly in
> the shim [1]. We would no longer rely on the mounted file to be changed by
> the kubelet. This will also minimise latency between changing and applying
> the change to the core. It will probably be faster and much simpler than
> using the file watch we have now and rely on the kubelet process.
>
> Wilfred
>
> [1] https://issues.apache.org/jira/browse/YUNIKORN-1365
>
> On Tue, 1 Nov 2022 at 10:27, Craig Condit <cc...@apache.org> wrote:
>
>> Hello everyone,
>>
>> I’d like to open a discussion around the idea of removing the current
>> logic that supports writing a new scheduler configuration via the REST API.
>>
>> Currently, this logic is disabled in two different ways (and has been for
>> several releases). First, it is turned off if config auto-refresh is
>> enabled (the default). Second, it doesn’t work unless a non-standard and
>> elevated set of permissions is granted to the service account running
>> YuniKorn. This happened as part of YUNIKORN-997: Use K8s fine-grained
>> access control for YuniKorn scheduler [1]. So, it has not been easily
>> activated since 1.0.0 shipped.
>>
>> This functionality was originally created to workaround potential delays
>> in configmap update detection and allow for more predictable updates since
>> it’s possible that a kubelet doesn’t refresh the on-disk copy of the
>> configmap in a timely manner. However, this hasn’t been true by default in
>> modern Kubernetes versions and no instances of this have been reported in
>> quite some time, and config auto-refresh has been active by default for
>> many releases.
>>
>> Additionally, this functionality is extremely insecure, as the REST API
>> has no security on it. Any user who can talk to the REST API could upload
>> any configuration they want, and this was why YUNIKORN-997 disabled this
>> functionality.
>>
>> With the upcoming design for YUNIKORN-1221: Configuration V2 [2], we’d
>> like to remove this functionality once and for all as it greatly simplifies
>> configuration handling moving forward.
>>
>> Let me know if you have any concerns,
>>
>> Craig Condit
>>
>>
>> [1] https://issues.apache.org/jira/browse/YUNIKORN-997 <
>> https://issues.apache.org/jira/browse/YUNIKORN-997>
>> [2] https://issues.apache.org/jira/browse/YUNIKORN-1221 <
>> https://issues.apache.org/jira/browse/YUNIKORN-1221>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: dev-help@yunikorn.apache.org
Re: [DISCUSS] Removal of configmap update logic via REST API
Posted by Wilfred Spiegelenburg <wi...@apache.org>.
+1 I am for removing this functionality just from a security point alone.
The change also includes watching the configmap and reloading directly in
the shim [1]. We would no longer rely on the mounted file to be changed by
the kubelet. This will also minimise latency between changing and applying
the change to the core. It will probably be faster and much simpler than
using the file watch we have now and rely on the kubelet process.
Wilfred
[1] https://issues.apache.org/jira/browse/YUNIKORN-1365
On Tue, 1 Nov 2022 at 10:27, Craig Condit <cc...@apache.org> wrote:
> Hello everyone,
>
> I’d like to open a discussion around the idea of removing the current
> logic that supports writing a new scheduler configuration via the REST API.
>
> Currently, this logic is disabled in two different ways (and has been for
> several releases). First, it is turned off if config auto-refresh is
> enabled (the default). Second, it doesn’t work unless a non-standard and
> elevated set of permissions is granted to the service account running
> YuniKorn. This happened as part of YUNIKORN-997: Use K8s fine-grained
> access control for YuniKorn scheduler [1]. So, it has not been easily
> activated since 1.0.0 shipped.
>
> This functionality was originally created to workaround potential delays
> in configmap update detection and allow for more predictable updates since
> it’s possible that a kubelet doesn’t refresh the on-disk copy of the
> configmap in a timely manner. However, this hasn’t been true by default in
> modern Kubernetes versions and no instances of this have been reported in
> quite some time, and config auto-refresh has been active by default for
> many releases.
>
> Additionally, this functionality is extremely insecure, as the REST API
> has no security on it. Any user who can talk to the REST API could upload
> any configuration they want, and this was why YUNIKORN-997 disabled this
> functionality.
>
> With the upcoming design for YUNIKORN-1221: Configuration V2 [2], we’d
> like to remove this functionality once and for all as it greatly simplifies
> configuration handling moving forward.
>
> Let me know if you have any concerns,
>
> Craig Condit
>
>
> [1] https://issues.apache.org/jira/browse/YUNIKORN-997 <
> https://issues.apache.org/jira/browse/YUNIKORN-997>
> [2] https://issues.apache.org/jira/browse/YUNIKORN-1221 <
> https://issues.apache.org/jira/browse/YUNIKORN-1221>
>
>