Re: S3 Object Storage - secret key handling
Hi Min, I'm not familiar with all the use cases of Cloudstack so let me just ask anyway... If you create another user as an admin can that user see the S3 secret key? Is there is any use case where another admin should not see the secret key then I think we should hide it. If not, then I guess its ok to leave it. Tom. On Thu, Jul 4, 2013 at 10:09 AM, Min Chen wrote: > Tom, on second thought, I don't think that this is an issue at all. This > Infrastructure page UI is only available to cloud admin, who is the person > who set up S3 secondary storage, so he/she already knows S3 secret key. > Hiding or not hiding it will make no difference. This UI will not be > visible to end users, so should not expose security issue. > > Thanks > -min > > On 7/2/13 11:51 PM, "Thomas O'Dowd" wrote: > > >Hi guys, > > > >I created a bug regarding the handling of the S3 secret key information. > >My opinion is that it should be treated more carefully like a password > >and not displayed in the UI at least. > > > >https://issues.apache.org/jira/browse/CLOUDSTACK-3342 > > > >Tom. > >-- > >Cloudian KK - http://www.cloudian.com/get-started.html > >Fancy 100TB of full featured S3 Storage? > >Checkout the Cloudian® Community Edition! > > > >
Object Storage Framework integration for Cloudian HyperStore
Hi all, We (Cloudian) have been getting some inquiries requesting a new Cloudian HyperStore plugin to work with CloudStacks new Object Storage Framework. We currently have a different CloudStack plugin which adds integration between the CloudStack UI and our UI that works for both admin and users as well as providing secondary storage. I’ve been trying to find out more information regarding the new Object Storage Framework and see there is a Minio plugin and a simulator plugin. I’ve also just checked out the git repo and have found the relevant code. Is the API stable at this point and are you accepting new plugin contributions? Can I just implement the same base objects that the Minio plugin is implementing in order to get our own plugin working? I notice in the “Add Object Storage” UI, there are fields: Name Provider URL Access key Secret key I think that we would use an https URL, but some installations would probably have a self-signed cert so they might need the option to skip validation. Didn’t check how this was working with Minio yet. Currently, we do not use an access/secret key to connect to the administration API but rather a username and password. Once connected, this should be able to allocate users to match CloudStack accounts. I’d need to look at what mappings to use there. The users should have Access/Secret keys so I would expect all of the S3 bucket browser stuff will just work once its all connected. Development wise, I have followed the “Developers Guide” under https://docs.cloudstack.apache.org/en/latest/developersguide/developer_guide.html#prerequisites and got as far as connecting to the management server without the simulator. I’m currently running on Rocky8. I’m wondering if I’m going to run into trouble on this OS and if I should switch to Ubuntu 24.04 which it seems the instructions were for? I guess my first goal is to seem it working with Minio and then try to get it working with HyperStore. Any advice appreciated, Thanks, Tom.
Re: Object Storage Framework integration for Cloudian HyperStore
Hi guys, I’ve started working on the Object Storage plugin. One quick question which I can’t find yet in the docs… Once I have added an object store as the admin user, how do I remove it? ie, I just want to blow away the configuration for now so I can try re-add it repeatedly as I fix things? Maybe the opposite of deploydb will do? Thanks, Tom. > On Sep 6, 2024, at 18:55, Rohit Yadav wrote: > > Hi Tom, > > In addition to what has been answered and what you've found, here are some > useful links for reference: > > https://github.com/shapeblue/hackerbook/tree/main (self-learning dev material) > https://github.com/shapeblue/hackerbook/blob/main/2-dev.md#contributing-to-cloudstack > https://github.com/shapeblue/mbx (local CI/dev-test setup) > https://github.com/apache/cloudstack/commit/c3f0d14d31583fdf2570de2633db5c87a0f08fa4 > (learn from new and existing plugins as reference implementation) > https://github.com/apache/cloudstack/tree/main/plugins/storage/object/minio > (original minio plugin for reference) > > > Regards. > > > > > > From: Tom O'Dowd > Sent: Friday, September 6, 2024 14:37 > To: dev@cloudstack.apache.org > Subject: Re: Object Storage Framework integration for Cloudian HyperStore > > Sorry for the noise. I answered my own question (or rather I found a page > that did): https://cloudstack.apache.org/developers/ > > Thanks, > > Tom. > >> On Sep 6, 2024, at 17:06, Tom O'Dowd wrote: >> >> Hi Daan, >> >> I have made some progress. I have got CloudStack running on Ubuntu 24.04 >> now. I have installed Minio and configurated it out as the Object Storage >> Provider to understand how it being used from an Admin and Regular user’s >> perspective. Additionally, I have also enabled the existing Cloudian Plugin >> and tried that out to ensure that it's all working also. >> >> There is one small item that I would like to fix in the existing plugin >> relating to a path change in the default HyperStore URL that the SSO uses. >> That’s just a string change. Additionally, we have moved away from Puppet in >> recent HyperStore versions for configuration management and I’d like to >> update the documentation specific to that point. My question is which branch >> I should use as a base for my PRs for both cloudstack and >> cloudstack-documentation. >> >> Thanks, >> >> Tom. >> >>> On Sep 3, 2024, at 17:38, Daan Hoogland wrote: >>> >>> Tom, >>> You are welcome to submit a PR and we'll happily review it and help you >>> tackle problems. The framework is there to use and adjust to your needs. As >>> for the API, what level of stability do you require? I expect some changes >>> on behalf of you if you are serious about implementing it. The minio is a >>> PoC implementation and at least a ceph one is underway. >>> >>> On Tue, Sep 3, 2024 at 9:59 AM Tom O'Dowd >>> wrote: >>> >>>> Hi all, >>>> >>>> We (Cloudian) have been getting some inquiries requesting a new Cloudian >>>> HyperStore plugin to work with CloudStacks new Object Storage Framework. We >>>> currently have a different CloudStack plugin which adds integration between >>>> the CloudStack UI and our UI that works for both admin and users as well as >>>> providing secondary storage. I’ve been trying to find out more information >>>> regarding the new Object Storage Framework and see there is a Minio plugin >>>> and a simulator plugin. I’ve also just checked out the git repo and have >>>> found the relevant code. Is the API stable at this point and are you >>>> accepting new plugin contributions? Can I just implement the same base >>>> objects that the Minio plugin is implementing in order to get our own >>>> plugin working? >>>> >>>> I notice in the “Add Object Storage” UI, there are fields: >>>> >>>> Name >>>> Provider >>>> URL >>>> Access key >>>> Secret key >>>> >>>> I think that we would use an https URL, but some installations would >>>> probably have a self-signed cert so they might need the option to skip >>>> validation. Didn’t check how this was working with Minio yet. Currently, we >>>> do not use an access/secret key to connect to the administration API but >>>> rather a username and password. Once connected, this should be able to >>>> allocate users to match CloudSt
Re: Object Storage Framework integration for Cloudian HyperStore
Sorry. answering my own question again. I found I could delete from the object_store table in the cloud database directly so that works for me right now rather than dropping everything. One thing that I have noticed about the UI is that the secret key is “displayed” and “remembered” by the browser when configuring a new object storage. This should probably behave more like a password field where you cannot see the value normally and the browser doesn’t remember previously used values. Tom. > On Sep 11, 2024, at 16:56, Tom O'Dowd wrote: > > Hi guys, > > I’ve started working on the Object Storage plugin. One quick question which I > can’t find yet in the docs… > > Once I have added an object store as the admin user, how do I remove it? ie, > I just want to blow away the configuration for now so I can try re-add it > repeatedly as I fix things? Maybe the opposite of deploydb will do? > > Thanks, > > Tom. > >> On Sep 6, 2024, at 18:55, Rohit Yadav wrote: >> >> Hi Tom, >> >> In addition to what has been answered and what you've found, here are some >> useful links for reference: >> >> https://github.com/shapeblue/hackerbook/tree/main (self-learning dev >> material) >> https://github.com/shapeblue/hackerbook/blob/main/2-dev.md#contributing-to-cloudstack >> https://github.com/shapeblue/mbx (local CI/dev-test setup) >> https://github.com/apache/cloudstack/commit/c3f0d14d31583fdf2570de2633db5c87a0f08fa4 >> (learn from new and existing plugins as reference implementation) >> https://github.com/apache/cloudstack/tree/main/plugins/storage/object/minio >> (original minio plugin for reference) >> >> >> Regards. >> >> >> >> >> >> From: Tom O'Dowd >> Sent: Friday, September 6, 2024 14:37 >> To: dev@cloudstack.apache.org >> Subject: Re: Object Storage Framework integration for Cloudian HyperStore >> >> Sorry for the noise. I answered my own question (or rather I found a page >> that did): https://cloudstack.apache.org/developers/ >> >> Thanks, >> >> Tom. >> >>> On Sep 6, 2024, at 17:06, Tom O'Dowd wrote: >>> >>> Hi Daan, >>> >>> I have made some progress. I have got CloudStack running on Ubuntu 24.04 >>> now. I have installed Minio and configurated it out as the Object Storage >>> Provider to understand how it being used from an Admin and Regular user’s >>> perspective. Additionally, I have also enabled the existing Cloudian Plugin >>> and tried that out to ensure that it's all working also. >>> >>> There is one small item that I would like to fix in the existing plugin >>> relating to a path change in the default HyperStore URL that the SSO uses. >>> That’s just a string change. Additionally, we have moved away from Puppet >>> in recent HyperStore versions for configuration management and I’d like to >>> update the documentation specific to that point. My question is which >>> branch I should use as a base for my PRs for both cloudstack and >>> cloudstack-documentation. >>> >>> Thanks, >>> >>> Tom. >>> >>>> On Sep 3, 2024, at 17:38, Daan Hoogland wrote: >>>> >>>> Tom, >>>> You are welcome to submit a PR and we'll happily review it and help you >>>> tackle problems. The framework is there to use and adjust to your needs. As >>>> for the API, what level of stability do you require? I expect some changes >>>> on behalf of you if you are serious about implementing it. The minio is a >>>> PoC implementation and at least a ceph one is underway. >>>> >>>> On Tue, Sep 3, 2024 at 9:59 AM Tom O'Dowd >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> We (Cloudian) have been getting some inquiries requesting a new Cloudian >>>>> HyperStore plugin to work with CloudStacks new Object Storage Framework. >>>>> We >>>>> currently have a different CloudStack plugin which adds integration >>>>> between >>>>> the CloudStack UI and our UI that works for both admin and users as well >>>>> as >>>>> providing secondary storage. I’ve been trying to find out more information >>>>> regarding the new Object Storage Framework and see there is a Minio plugin >>>>> and a simulator plugin. I’ve also just checked out the git repo and have >>>>>
Re: Updating Object Store Configuration
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
> 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
> Sent: Thursday, October 10, 2024 11:02 AM
> To: 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.
>
>
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 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 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 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: &#x
Re: Updating Object Store Configuration
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 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 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
>> 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 parti
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.
Re: Updating Object Store Configuration
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 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
> Sent: October 22, 2024 1:06 AM
> To: 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 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 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.
Re: Object Storage Framework integration for Cloudian HyperStore
Hi all, I’ve been quietly working on implementing a Cloudian (an S3 Object Storage Vendor) plugin for the new Object Storage Framework in CloudStack. I’m getting there but I have some questions. If you are reading this and don’t have all the answers but know some of them or have an opinion on some of it, let me know. Firstly, I’m using the following mapping currently. CloudStack Domain is mapped to a HyperStore Group. CloudStack Account is mapped to a HyperStore User (in the domain appropriate group) CloudStack Projects will probably be automatically mapped to HyperStore Users also (haven’t tried it yet). We have 3 server endpoints to manage (for this plugin) 1. The Admin API endpoint 2. An S3 service endpoint 3. An IAM service endpoint I plan to look at changing the “Add new object storage” UI to accept those 3 different endpoints if Cloudian is choosen as the provider. I haven’t looked into that yet. The Object Storage “url” will be the Admin API endpoint. I’ll probably add the other endpoint urls to the “details” Map similar to how the accesskey and secretkey are set already. I think this should work. I’ll probably get to this part next week. I am thinking that the main idea for this plugin is to have all bucket management (creation and deletion in particular) done from the CloudStack UI. I say this because, when you look at the “Details” UI element for a bucket, you can find the Access Key and Secret Key for that bucket there. If you add those credentials to a 3rd party s3 application etc, then it is possible to create other buckets that CloudStack will not know about or manage under that user account. As this seems wrong to me, I am planning on creating an IAM user with a policy that grants bucket and object actions except for createBucket and deleteBucket. The IAM user credentials will then be displayed instead of the Root User credentials. The Root user credentials will be used by the plugin itself to manage the bucket. In this manner, Users created by CloudStack can only create and delete buckets via the CloudStack UI. I don’t see anywhere to update the credentials associated with the ObjectStorage providers in case they change or get rotated? Right now I have the following credentials: ADMIN API - user/password combination Each HyperStore Account - Root User Credentials (hidden from user but used by plugin) Each HyperStore Account - IAM User with Restricted Credentials -> visible as part of Bucket “Details" I noticed that if there are 2 or more object storages configured and one of them has an exception when collecting bucket usage stats, then the other one can be skipped. I have a fix for this coming also. One other thing that I have done differently is the “public” bucket policy option. Minio and Ceph currently enable public bucket listing (index of objects in the bucket). I have only enabled GetObject on the bucket’s objects. I could enable the same as Minio and Ceph but I think it is over permissive. I think the developer of Ceph just copied what Minio was doing so I figured I’d ask. Another difference that I noticed is that Minio has CORS enabled by default on it's buckets. This seems to be required for the S3 Javascript browser built into CloudStack. By default, Cloudian does not enable CORS (similar to AWS). I plan to enable it as part of the createBucket API so that the CloudStack browser functionality also works but I am wondering how to set the Allowed Origin. Mino uses “*” allowing any Origin. I have not checked Ceph but there is nothing explicity done in the code. Do you think using “*” is ok? If not, I’m currently stuck for where to get the correct setting for Origin given that there could be many management servers. Also there is no place in the UI to manage this right now should the origins change. So maybe “*” is the right direction here. Where should documentation regarding this go? I think an administrator would like to know how for the different providers types the Accounts are mapped to the Storage etc. Things I am not going to fix in my first PR (but should be fixed): 1. INFO level logging currently dumps S3 credentials in the log file. This happens in a few places. Just look for “secretkey”. This should be addressed so as not to log clear text “passwords". 2. The secret key is visible in the Bucket “Details” page. This should possibly be hidden with a click to “copy” type browser action in place. Thanks, Tom. > On Sep 11, 2024, at 17:17, Tom O'Dowd wrote: > > Sorry. answering my own question again. I found I could delete from the > object_store table in the cloud database directly so that works for me right > now rather than dropping everything. > > One thing that I have noticed about the UI is that the secret key is > “displayed” and “remembered” by the browser when configuring a new object > storage. This should probably behave more like a password fi
Re: Object Storage Framework integration for Cloudian HyperStore
Hi all, I have finished working on the plugin and have submitted a PR which is currently waiting on workflow approval. https://github.com/apache/cloudstack/pull/9748 One part of my changes that I am a little unsure of relates to maven edits to pom.xml. Please let me know if something looks amiss in that area. Thanks, Tom. > On Sep 21, 2024, at 17:21, Tom O'Dowd wrote: > > Hi all, > > I’ve been quietly working on implementing a Cloudian (an S3 Object Storage > Vendor) plugin for the new Object Storage Framework in CloudStack. I’m > getting there but I have some questions. If you are reading this and don’t > have all the answers but know some of them or have an opinion on some of it, > let me know. > > Firstly, I’m using the following mapping currently. > > CloudStack Domain is mapped to a HyperStore Group. > CloudStack Account is mapped to a HyperStore User (in the domain appropriate > group) > CloudStack Projects will probably be automatically mapped to HyperStore Users > also (haven’t tried it yet). > > We have 3 server endpoints to manage (for this plugin) > 1. The Admin API endpoint > 2. An S3 service endpoint > 3. An IAM service endpoint > > I plan to look at changing the “Add new object storage” UI to accept those 3 > different endpoints if Cloudian is choosen as the provider. I haven’t looked > into that yet. > > The Object Storage “url” will be the Admin API endpoint. I’ll probably add > the other endpoint urls to the “details” Map similar to how the accesskey > and secretkey are set already. I think this should work. I’ll probably get to > this part next week. > > I am thinking that the main idea for this plugin is to have all bucket > management (creation and deletion in particular) done from the CloudStack UI. > I say this because, when you look at the “Details” UI element for a bucket, > you can find the Access Key and Secret Key for that bucket there. If you add > those credentials to a 3rd party s3 application etc, then it is possible to > create other buckets that CloudStack will not know about or manage under that > user account. As this seems wrong to me, I am planning on creating an IAM > user with a policy that grants bucket and object actions except for > createBucket and deleteBucket. The IAM user credentials will then be > displayed instead of the Root User credentials. The Root user credentials > will be used by the plugin itself to manage the bucket. In this manner, Users > created by CloudStack can only create and delete buckets via the CloudStack > UI. > > I don’t see anywhere to update the credentials associated with the > ObjectStorage providers in case they change or get rotated? > > Right now I have the following credentials: > ADMIN API - user/password combination > Each HyperStore Account - Root User Credentials (hidden from user but used by > plugin) > Each HyperStore Account - IAM User with Restricted Credentials -> visible as > part of Bucket “Details" > > I noticed that if there are 2 or more object storages configured and one of > them has an exception when collecting bucket usage stats, then the other one > can be skipped. I have a fix for this coming also. > > One other thing that I have done differently is the “public” bucket policy > option. Minio and Ceph currently enable public bucket listing (index of > objects in the bucket). I have only enabled GetObject on the bucket’s > objects. I could enable the same as Minio and Ceph but I think it is over > permissive. I think the developer of Ceph just copied what Minio was doing so > I figured I’d ask. > > Another difference that I noticed is that Minio has CORS enabled by default > on it's buckets. This seems to be required for the S3 Javascript browser > built into CloudStack. By default, Cloudian does not enable CORS (similar to > AWS). I plan to enable it as part of the createBucket API so that the > CloudStack browser functionality also works but I am wondering how to set the > Allowed Origin. Mino uses “*” allowing any Origin. I have not checked Ceph > but there is nothing explicity done in the code. Do you think using “*” is > ok? If not, I’m currently stuck for where to get the correct setting for > Origin given that there could be many management servers. Also there is no > place in the UI to manage this right now should the origins change. So maybe > “*” is the right direction here. > > Where should documentation regarding this go? I think an administrator would > like to know how for the different providers types the Accounts are mapped to > the Storage etc. > > Things I am not going to fix in my first PR (but should be fixed): > > 1. INFO level logging currently dump
