Service enabled for other orgs fails to stop the applications after the idle-duration

[cloudfoundry-community]

Service enabled for other orgs fails to stop the applications after the idle-duration

[gberche-orange]

Hi @PadmaB

I confirm your expected behavior documented and tested at https://github.com/Orange-OpenSource/autosleep/blob/develop/acceptance/4_application_autobind.robot#L13-L20

Which version of the autosleep service are you using ?
Can you please check the autosleep app logs, especially for failures to connect to the cloudfoundry API as reported in #171

If you try against the latest head on the "develop" branch, the failure should prevent the autosleep at start.

[PadmaB]

Hi,

Sorry for the delay on this!
I think I understand what is the issue here, the user [cf.client.username] that is used while provisioning the service is not the SpaceDeveloper where the above raised issue has popped up.
How is this expected to work?
Normally the service is provisioned [deployed] is some 'central org' and then the service access is enabled for all the organizations which would need autosleep functionality. In such a scenario, it is unlikely that the user [cf.client.username] will have SpaceDeveloper role in every org/space where the service is enabled. Also, there could arise security concerns.
Is there any alternative approach to this?
What are your thoughts on this?

Thanks and Kind Regards,
Padma

[gberche-orange]

@PadmaB

Currently, the prerequisite CC API account either:
1- needs to be a space developer for each managed space as documented onto https://github.com/Orange-OpenSource/autosleep/blob/develop/doc/publish.md#prepare-your-manifest in the prereq "a CC API user with cloudcontroller.read and cloudcontroller.write scopes, and role "SpaceDevelopper" on the enrolleable autosleep spaces" part.
2- needs to have cloudcontroller.admin scope

We are considering future support for an admin to specify a set of spaces to be managed within an organization, or a set of organizations within a CF instance. As part of this feature, it could be envisaged to require the CC API account to have OrgManager role on each of the managed role, and use this to dynamically add itself as space developer on each of the managed space (as the CLI is curently doing when creating a space).

Until then, the recommended usage is to script the autosleep service instance creation in spaces, along with adding space developper membership to the CC API account provided to autosleep app.

With respect to security impact of having an autosleep CC API account be given space developer role on each managed space, I had suggested the related Service Broker User delegation during provisionning which I encourage you to read and comment.

BTW, are you attending the cf summit next week ? Would be great to exchange more together on the use-cases you see for autosleep.

[PadmaB]

@gberche-orange
Unfortunately, I am not attending CF Summit but I will interested to know the roadmap for autosleep, especially the autowakeup feature that is under implementation. It is very interesting and will make the autosleep solution more complete.

Thanks for sharing the above details, will go through the details and revert back for further queries/feedback.

Thanks,
Padma

[gberche-orange]

closing in favor of #201

Please reopen/comment if I missed something