2

TL;DR How can we automate the creation of per-user credentials to access COS buckets using the S3 compatibility layer?
The only documented way AFAIK is the CLI; but embedding command-line executions inside a web service is not very appealing!


The IBM online documentation for COS (Cloud Object Storage) shows 2 ways to create a "service key with HMAC credentials" for a given bucket and a given role [reference]

  • from the admin UI
  • with the CLI >> ibmcloud resource service-key-create ****** --parameters '{"HMAC":true}'

The point of these "HMAC creds" is to access the bucket as if it was stored in S3 (or any other appliance compatible with the S3 API).

Now, I assume the UI and the CLI both use some kind of API under the covers. Maybe they have to juggle with the IAM API and the COS API to expose that COS-specific feature as a "generic" security feature.

But I couldn't find anything relevant in the online docs for IAM API -- the only API call that specifies a "resource" and an "authorization policy" is about creating a temporary token, not a persistent key [reference]
I couldn't find anything relevant in the COS API either. Nothing about security there.
And I would try to dig into the source code of the CLI if it was Open Source but, alas, it is not.

I guess my only hope is to get "inside information" from the IBMers who actually developed the CLI... hence the tags below.

Samson Scharfrichter
  • 8,884
  • 1
  • 17
  • 36

1 Answers1

0

So when you create a Service Credential with HMAC keys, what is essentially happening there is that those persistent keys are being generated by COS (not IAM) and are bound to an IAM Service ID (ie a non-human user). When you send an S3 API request by creating a signature with those keys, COS figures out the associated Service ID and checks with IAM to see if that identity has sufficient privileges for the operation being requested. This allows you to use the persistent HMAC keys at the expense of needing to waste some CPU calculating all the HMAC signature stuff for each request. So while IAM is involved behind the scenes at the policy enforcement level, authentication is handled by COS directly.

Now, if you want to programmatically create Service Credentials, there's a REST API for that, but no published libraries, (although I suppose you could try and generate one from the OpenAPI spec). Essentially you just call that API and provide the {"HMAC":true} bit inside the "Parameters" object. Inside the response you'll find the credential with the HMAC keys.

All that being said, you don't want to use IAM tokens or HMAC signatures for your application's end users. Think about the Service ID that you've bound to the HMAC credentials as the executor of the operations being performed. Try and keep the user authentication piece isolated, and then when some end user is allowed to do something, then have the Service ID do the operation. Obviously all applications are going to be different and have their own challenges. One pattern that we've seen used (and I keep meaning to put together a tutorial for) is to have the application generate a pre-signed URL, and pass that to the client, avoiding any need to pass credentials outside of the application space.

Basically, IAM is intended for administrators, developers, and other cloud services to authenticate and authorize actions in the IBM Cloud (and thus aren't intended to scale past a few thousand access policies), but you should be looking to something like App ID for the end-user authz pieces.

What language/framework are you using? Are you using the COS SDKs? They abstract away the token management stuff for you if you'd rather use API keys.

Nick Lange
  • 857
  • 6
  • 8
  • 1
    Long story short: how to onboard a few **thousands** of Data Scientists on the IBM Cloud, via Domino DataLab and/or Dataiku and/or JupyterHub and/or PyCharm and/or VSCode, running custom Python and/or R code against COS buckets, with strong authentication & authorization, and reliable audit trails that can pass a GDPR audit? – Samson Scharfrichter Sep 15 '20 at 16:09
  • 1
    No way to "assume roles", AWS-style, so we are struggling to build a convincing "federated identity down to Cloud-native building blocks". And native IBM connectors to COS are not particularly sexy, either. – Samson Scharfrichter Sep 15 '20 at 16:13
  • Ahhh, yeah. I've been pushing for an 'assume role' sort of feature for a long time, pretty much for this exact use case. Would make things a lot easier. What is the scope of access for each of these data scientists? Will they be all be accessing a shared data pools, or does each user need their own isolated bucket? There are 'access groups' in IAM, so I'm thinking that each user could get their own service ID (and credentials), and then they could all be assigned to the same Access Group (or groups) and share the same authorization policies, and be set on the audit trail side of things. – Nick Lange Sep 15 '20 at 17:02
  • If each user needs to have sole control over a bucket, that's a lot trickier. – Nick Lange Sep 15 '20 at 17:02
  • 1
    _"each user could get their own service ID (and credentials)"_ > or a custom End User Cloud Creds service could manage temporary creds for each "federated" user, all linked to the same service ID -- except that there has to be a limit to the number of creds (S3 access keys automatically revoked / IBM temp token automatically renewed) attached to the same service ID. We're investigating that idea. If you know of a similar attempt by another IBM client, we would be interested in talking to them ;-) – Samson Scharfrichter Sep 16 '20 at 07:35
  • _"If each user needs to have sole control over a bucket"_ > that's the point of Robotic Process Automation: making tricky things (apparently) simple... – Samson Scharfrichter Sep 16 '20 at 07:39
  • 1
    Yeah, this should certainly be a lot easier to do. Seems like there's a limit of [2k service IDs](https://cloud.ibm.com/docs/account?topic=account-known-issues#iam_limits) so that's out. If you want to reach out to me directly(nicholas.lange[at]ibm.com), I can get you in touch with some offering management folks - they need to understand this is an important use case that we're having a hard time meeting. – Nick Lange Sep 21 '20 at 16:25