Hi Pearl, Thanks that helped a lot! Although the ListResourceDetailsCmd does not have a ResponseView, I was able to use the calling context and check the requested resourcetype to specifically deny access if not a root admin. This seems to work well in some light testing and is a good approach to the problem I think.
Thanks again! Tom. > On Oct 22, 2024, at 14:32, Pearl d'Silva <pearl.dsi...@shapeblue.com> wrote: > > Hi Tom, > > You could try using the logic : > https://github.com/apache/cloudstack/blob/main/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1159-L1165. > Essentially, there are 2 response views - Restricted and Full, and based on > the user role, you could set the appropriate response view . This way you > should be able to hide ObjectStoreDetails from being returned for users who > aren't Root Admin. > > > Hope this helps. > > Regards, > Pearl > > > > > > > > ________________________________ > From: Tom O'Dowd <tpod...@cloudian.com.INVALID> > Sent: October 22, 2024 1:06 AM > To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> > Subject: Re: Updating Object Store Configuration > > Hi guys, > > Really could do with some feedback here. > > I got editing object store details working fully. However, I think there is a > problem regarding permissions. I am using the `ListResourceDetailsCmd` API. > Using this API from the vue file, I can get the details that I need and > provide a way to edit them. > > However, it seems that the `ListResourceDetailsCmd` API can by ANY user and > not just administrators. This is a problem as objectStoreDetails are > sensitive and contain secrets. My question is: > > 1. Is there a way to restrict ObjectStoreDetails to only when an admin calls > the API? If so, can you explain that here so I can try it out? > > 2. If not, then I guess I’ll disable ObjectStoreDetails from being returned > by ListResourceDetailsCmd and instead I’ll create another admin API to get > the ObjectStoreDetails. I presume this sounds ok? > > Thanks, > > Tom. > >> On Oct 17, 2024, at 21:51, Tom O'Dowd <tpod...@cloudian.com> wrote: >> >> I spent more time trying to understand the code today. What I said before >> was an incorrect understanding of what was happening. Anyway, I found an API >> called `ListResourceDetailsCmd` which I can call with a resourceid of the >> object store and a resourcetype of ‘objectstore’. This doesn’t work out of >> the box but just a few changes and I was able to get it to return details >> for the particular object store. >> >> My question however is if it is ok to do this as looking at the signature of >> ListResourceDetailsCmd, it doesn’t seem to have any setting values for >> authorized… this implies I think that anyone can call this API and not just >> Admins? If this is true, then maybe I should not add support for >> ObjectStorageDetails via the ListResourceDetailsCmd as authorization >> information is kept there and it would be better to have a custom API that >> is only allowed by the admin to retrieve this information. Or should >> ListResourceDetailsCmd actually be more restricted? I’m not clear what all >> the use cases are for what this API is used for. Actually, I didn’t find any >> users of the API in the UI code so maybe it would be no harm to lock it >> down? Please advise. >> >> Then again, I also noticed that none of the API commands for objectstorage >> pools currently restrict the roles that can call those APIs? I do think the >> default is open so perhaps this is wrong and I can also fix that. >> >> Another question. the interface for the driver has a listBuckets() function: >> >> public interface ObjectStoreDriver extends DataStoreDriver { >> ... >> List<Bucket> listBuckets(long storeId); >> ... >> } >> >> I can only find 1 caller to this function and that is from the >> UpdateObjectStoragePoolCmd API call which uses that driver function to >> validate the new URL (and soon other settings)… I’m not sure what the >> original purpose of that command is but there is no real reason to return a >> list of buckets to validate if the storage is working. My idea is to add a >> new “lighter” function called something like >> >> boolean isConnectionValid(long storeId); >> >> This is more obviously named in its purpose and should provide a better >> check of the different parts of the system that the updated settings cover. >> For HyperStore for example, I need to validate connectivity to 3 urls (2 of >> which I don’t use to listBuckets). >> >> Thanks, >> >> Tom. >> >>> On Oct 11, 2024, at 21:15, Tom O'Dowd <tpod...@cloudian.com> wrote: >>> >>> Hi Vishesh/all, >>> >>> I had a go at this but I need a bit of help/guidance I think. >>> >>> I figured out how to create and hook in a updateObjectStorage.vue file. I >>> wanted to get a basic one working first. >>> >>> The issue I’m having next is I cannot get the “details” map out to the GUI >>> as part of UpdateObjectStoragePoolCmd.java as that command is defined like >>> this: >>> >>> @APICommand(name = UpdateObjectStoragePoolCmd.APINAME, description = >>> "Updates object storage pool", responseObject = ObjectStoreResponse.class, >>> entityType = {ObjectStore.class}, >>> requestHasSensitiveInfo = false, responseHasSensitiveInfo = false, >>> since = "4.19.0") >>> public class UpdateObjectStoragePoolCmd extends BaseCmd { >>> public static final String APINAME = "updateObjectStoragePool"; >>> >>> >>> The key here seems to be the EntityType which is ObjectStore.class. >>> >>> If I understand correctly, that is an interface that only has the basic >>> properties such as name, providerName, url, id. So even if I add a map >>> parameter to the API, I think that will only be for when the api is called >>> to update? >>> >>> If I log the resource in the js console I get: >>> >>> this.resource: Proxy(Object) {id: 'fcad9cc0-7985-483b-aa31-988a03815db6', >>> name: 'Cloudian', url: 'https://s3-admin.name.or.jp:19443', providername: >>> 'Cloudian HyperStore', key: 0} >>> >>> What should I do to get the details map? Perhaps there are 3 ways? >>> 1. Add details (yuck?) to ObjectStore? >>> 2. Create another type of object just for this? >>> 3. Call another API that pulls the details from the vue script on loading - >>> involves creating another API for this also? >>> >>> I’m not really a front end guy so struggling with the js/vue stuff also but >>> am making my way through it. Also just looking at the API stuff for the >>> first time so new to that also. >>> >>> Any help appreciated. >>> >>> Tom. >>> >>>> On Oct 10, 2024, at 17:47, Vishesh Jindal <vishesh.jin...@shapeblue.com> >>>> wrote: >>>> >>>> Hi Tom, >>>> >>>> This is the right place for the discussion. >>>> >>>> I think what you are suggesting makes sense. If the user wants to update >>>> the accessKey and secretKey, it should be allowed. >>>> >>>> We can create a validation function for the Storage Plugins as per the >>>> selected provider to validate the details map. And if for some reason, the >>>> provider doesn't support the update for a particular key, the request will >>>> fail. >>>> >>>> If you raise a PR for the changes, I can review it. >>>> >>>> Regards >>>> Vishesh >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> From: Tom O'Dowd <tpod...@cloudian.com.INVALID> >>>> Sent: Thursday, October 10, 2024 11:02 AM >>>> To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> >>>> Subject: Updating Object Store Configuration >>>> >>>> I have a question about updating the Object Store Information. >>>> >>>> The current code only allows updating either the Name or the Object Store >>>> URL. >>>> >>>> https://github.com/apache/cloudstack/blame/d6181d542108d02cca31daa758234bb29e1b317a/server/src/main/java/com/cloud/storage/StorageManagerImpl.java#L4180 >>>> >>>> I think it is necessary to also update the other fields, namely accessKey >>>> and secretKey of the admin user of the different object stores. Currently >>>> there is no way to update them. I’m sure MinIO and Ceph will need this as >>>> well as Cloudian. >>>> >>>> For our Cloudian implementation I would also like to be able to update >>>> other store details which are the S3 URL and the IAM URL and whether or >>>> not the SSL Certificate should be validated. >>>> >>>> When the object store is first created, this information is sent in a >>>> “details” map. Therefore, it might make sense to ask the object store that >>>> is being updated for its “details" Map, the GUI can be changed to allow >>>> editing these and new details then passed back to this method which asks >>>> the object store to set and validate them (rather than what it is doing >>>> here where the update method itself is actually updating the store with >>>> potentially bad data, then checking if it works before reverting it on >>>> failure. >>>> >>>> So something like: >>>> >>>> User clicks Edit Object Storage >>>> GUI requests Object Storage Info (url, name, details map etc) >>>> (should ask the Object Storage Implementation for its configuration >>>> information new function - details map) >>>> displays the fields appropriate to the providerName (similar to create >>>> Object Storage) using the details map. >>>> When GUI updates, the details map is also posted along with the URL and >>>> name. >>>> a new Object Storage Implementation update configuration function is >>>> called which validates and saves the information if good. >>>> >>>> Anyway this probably needs some kind of formal discussion to make >>>> progress? Is that this thread or does that happen elsewhere? >>>> >>>> Thanks, >>>> >>>> Tom. >>>> >>>> >>> >> >
