How can we get the access log of Object storage on SoftLayer?
I would like to use swift based one.
Unfortunately this information is not available, I recommend to submit a ticket if it's really necessary to get this kind of information
Related
We’ve been trying to understand if Google Cloud can access data stored in Google Storage when using Google-managed encryption keys.
We want to understand if Google potentially has access to the data stored. If yes, is there a way to restrict such access?
Yes, Google can. No, you cannot restrict Google.
Google publishes data policy documents on its website on how/when/if they access your data. Data access is logged so that you can see such accesses. There is a process requiring approval. A Google employee cannot just poke around in your data. Similar to most legal documents, you must read the documents to understand the details and conditions.
Start with this privacy page:
Privacy Resource Center
Using access logging, as detailed here: https://cloud.google.com/storage/docs/access-logs, we can download and analyze usage patterns for our data. However, looking at the actual data, I noticed that there is no data relating which user (or service-account) performed the operation. The closest seeming attribute in the usage logs as described here: https://cloud.google.com/storage/docs/access-logs#format is the cs_user_agent attribute. However, this attribute seems to describe more about the tool performing the access (i.e., gsutil or gcloud) rather than the user.
Is it possible to obtain information that relates the activity to a user/service-account? Perhaps using the s_request_id attribute?
Is there a technical reason this is missing? Or is it intended as a privacy-preserving mechanism?
You can read about the access log schema in our docs. cs_user_agent tells you what kind of program made the request, while s_request_id is a unique id for the request. The closest thing to what you need would be c_ip, which is the IP address of the machine making the request. You could possibly tie those to users. If this doesn't suffice, you could have your clients make requests only through some code you yourself have written which will log - in parallel to sending the request - the URL, method, any headers / metadata desired, and the user / account making the request.
I want to use mongolab from client js. I aware that reading data from db will be accessible for anyone who knows my API key. But I must to forbid modifying of database. I can't search for actual information. Only old posts, that could be already outdated (I hope guys from mongolab improving their product). I think that it may be possible because we have different API keys for each account user.
So, is it possible at current time to set read only access for account user?
I use the Dropbox Datastore in an app that uses both the iOS and JavaScript SDKs. Aside from the 10MB datastore limit, it works pretty well.
But nearly every support request I get makes me wish I could have access to the user's data for debugging. Being able to see exactly what the user sees helps me to find and fix bugs very quickly.
Is there any way for me to access a user's data without logging into their account? Can I maybe store their access token and gain access to just their Dropbox Datastore data?
This is one of the attractive things about Parse: you can see all user data. While there is a lot of wisdom in sharding user data across Dropbox user accounts, it makes app debugging crazy-hard.
Any ideas? What do you do to get around this?
Dropbox datastores, like files, are considered the user's private data, and as such there isn't a way for an arbitrary party to gain access to said data without some sort of authorization (e.g., access to the account, having the data explicitly shared with them, etc.) Likewise, even the developer of an API app that a user happens to be using doesn't automatically get access to the data.
That said, if, as the developer of the app, you want to troubleshoot using your user's data, the most straightforward method would probably be to get an access token for that app/user pair from the user. That would replicate their setup most accurately. (Unfortunately, the Sync/Datastore SDK doesn't make it easy to extract/insert arbitrary access tokens like that though. So, in that case, this would be a bit of work to build some flow to get an access token, e.g., a small web app, and then some work to read data directly from the API.)
Alternatively, you may want to make it possible for the user to share the datastore with your own account.
In any case, it's very important that the user not be misled or confused as to what is happening or what the developer is requesting. That means being clear with user with regards to what the developer is requesting and what will be done with the data. In addition, apps should provide privacy policies in general.
I'm quite new to Cloud Storage solutions, and I'm currently researching options to upgrade our current solution (we currently just upload on a SVN server).
What I have is a native application running on client computers, which will upload data to the Cloud Storage. Afterwards, client should be able to download and browse their data (source is not set in stone, could be a website or from other applications). They should not be able to access other user's data.
I'm not sure how I'm supposed to proceed. As far as I understand, the native application will upload using a Native Application Credential, using JSON.
Do I need multiple credentials to track multiple users? That seems wrong to me. Besides when they come back as 'users' through the web interface, they wouldn't be using that authentification, would they?
Do I need to change the ACL of the uploaded files afterwards?
Should I just not give write/read access to any particular users and handle read requests through Signed URLs, dealing with permission details by myself using something else on the side? (not forcing a Google Account is probably a requirement)
Sorry if this is too many questions, and thanks!
Benjamin
The "individual credentials per instance of an app" question has come up before, and unfortunately there's not a great answer. If you want every user to have different permissions, you need every user to be associated with a different account.
Like you point out, the best current answer, other than requiring users to have Google accounts, is to have a centralized service that vends signed URLs to the end applications. That service would be the only owner of all of the objects and would give out permission to read or upload as needed.