Bluemix Account vs. Bluemix User. Is there difference? - ibm-cloud

In SoftLayer, there's concept of Account and multiple users can be created under that account. Is there similar concept in Bluemix? Is there like Bluemix account that gets created then multiple users can be created under the same account such that when these users subscribe to new services the account gets billed?
I know that in Bluemix there's Organization and space. And I can invite another user/org/account(?) to share my resources. But can that invited user subscribe to a service on behalf of the organization that invited the user? (i.e. the invited organization gets billed?)

If I am understanding your question correctly, I think that you want to be sure that the individual is given the Developer role in the space. As stated in the docs, here is the definition of the Developer role:
Space developers can create, delete, and manage applications and
services within the space. Some of the managing tasks include
deploying apps, starting or stopping apps, renaming an app, deleting
an app, renaming a space, binding or unbinding a service to an
application, view the number or instances, service bindings, and
resource use for each application in the space. In addition, the space
developer can associate an internal or external URL with an
application in the space.
This information came from this URL:
https://console.ng.bluemix.net/docs/admin/users_roles.html

Related

GCP: what is the Robot Service Account in GKE

I'm trying to improve my knowledge in GCP-GKE as a newbie and in the way to do that, I found out a little concept that I don't quite understand yet. In GKE, there is a Service Account called service-PROJECT_NUM#container-engine-robot.iam.gserviceaccount.com (where the PROJECT_NUM is the ID of our project) and after several hours googling, I couldn't find any article or definition about this stuff. So could you guys please explain to me
What is this Service Account ? How was it created (by who)?
What is this thing for? How important is it in GKE?
What happens if we delete it ? Could we re-created it manually ?
In fact, I found out that in GCP, we have some Service Account that have a "robot" suffix: ...robot.iam.gserviceaccount.com/ (like #gcf-admin-robot.iam.gserviceaccount.com/, #serverless-robot-prod.iam.gserviceaccount.com, etc). What could we say about this, please ?
If I misunderstand something, please, point it out for me, I really appreciate that.
Thank you guys !!!
Service Accounts aka "robots" contrast with user ("human") accounts and represent two forms of Google identity.
NOTE Robots was the original name for Service Accounts and is a more colorful description of the intent of these accounts, to run software.
(Google) User accounts include consumer (Gmail) e.g. you#gmail.com and you#employee.com (Workspace) accounts. User accounts are used by humans to interact with Google services and must be used (or a suitable delegate) to acccess user-owned content such as Workspace docs, sheets etc.
Software ("robots") generally should run as a Service Account not as a User account. In part, you can't easily run software using User accounts because the User OAuth flow is 3-legged and requires interacting with an OAuth Consent Screen to permit an app access to data.
There are two flavors of Service Account: Google-created|managed and User-created|managed. The difference is essentially the owner. If you create applications, generally you should create a Service Account for each app and run the app using its Service Account.
User-managed Service Accounts take the form {something}#{project}.iam.gserviceaccount.com where you get to define the value of {something} and the Google Project in which the Service Account is created (the project that owns the Service Account) is represented by {project} (actually the Project ID).
When Google provides app functionality, it also creates Service Accounts and often, Google "binds" these Service Accounts to your projects that use them in addition to defining the role that the Service Account has in your project.
Google-managed Service Accounts take the form {something}#{label}.iam.gserviceaccount.com. Unlike User-managed Service Accounts, Google uses more descriptive labels ({label}) to help explain the role of the Service Account.
NOTE With Google-managed Service Accounts {something} often includes the Project Number (not ID) of (your!) project for which the Google-managed account has been created.
You cannot delete Google-managed Service Accounts because you(r Google account) does not own the Service Account.
You can (but should not) delete the role binding between one of your projects and a Google-managed Service Account. It may be possible for you to revert (recreate) the binding but you may not have permission to do this.

How to resolve endpoint for an Android app aimed at multiple customers?

First let me explain the problem:
We have an Android app and multiple customers. Each customer has their own endpoint (Kubernetes cluster of microservices basically) that the app should communicate with. To prevent us from having to deploy multiple versions of the app (one for each customer) we are looking for a solution that will use one app but allow for multiple endpoints.
I am interested in knowing if, and if so how, others have solved this.
We have tried:
Automatic endpoint resolution within the app based on user's domain. This fails our requirements because we then need to build a new app for every customer, which is not optimal with 10's of customers appearing every week.
Microservice that gives the user and endpoint based on user's domain. This fails because it creates a Catch 22 problem... how do we know the endpoint to this microservice?
Keycloak User Attributes. We use Keycloak for SSO. Using the REST API in Keycloak requires an admin user, but we do not want to expose such an admin user from any external application.
Manual endpoint insertion in the app. Highly user-unfriendly!

How Do I Know What Each Azure AD App Registration Is For?

When I create a service principal it also creates an App in Active Directory.
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/123456a1-a1b2-1234-12ab-12a3b4cdef67"
If I go to the Azure Portal - Active Directory - App registrations it shows all the applications registered.
I have managed to find the service principal I use for terraform by matching the terraform client_id with the Azure "Application (client) ID". It also had a human readable display name (although not the best since I still had to look via client id!)
However, there are several others where the display name is just "project_subscription".
They look like they must have been generated automatically when setting up a pipeline registering a web app in the portal or something.
I can't tell if they are actually used or if they were just created for experimenting and are then left over.
How do I know what they are for and if they are still used or not?
Is it possible to search Azure for the id or anything?
Is it possible to add a description to these to identify what they are used for beyond just the display name?
e.g. I only identified the terraform one by matching up the id with my code
App registration can be used for many scenarios, the app registrations in your AAD tenant should be created by different users. There is no such thing as a description of them.
To see if they are used, it needs to combine the context, as in AAD, there are different usages for them. For example, there are no sign-in logs of the AD App's corresponding service principal, but you cannot make sure if it was used as a client app. For the details, you may need to check the Audit logs.
For more details about AD App(App Registration) and service principal, you could check this doc - https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

Does Salesforce's REST API have a service accounts

I'm trying to interact with the Salesforce REST API for an organisation, and was wondering if it had any notion of Service Accounts or Application Owned Accounts. I can't find any mention of it in the documentation, but maybe they use different nomenclature.
I'd like to enable some form of domainwide delegation of authority, so users aren't faced with the pop up requesting access to their data. This is an internal app, only for this particular organisation.
No, there are not service accounts. There are 'Chatter' user licenses that are free but have reduced functionality: http://www.salesforce.com/chatter/getstarted/?d=70130000000tRG7&internal=true#admin
FAQ: http://www.salesforce.com/chatter/faq/

Downloading of Facebook IDs within terms of service?

I have an app where people login to our site, search for FB groups based on keyword, and then download a text file of UIDs (generated by the API, not by scraping), for the purpose of creating a custom audience in the Power Editor and uploading it back.
Is that allowed?
It is okay to do so, as long as it is strictly for the functionality for your app and your users that will be downloading the lists of ids have agreed to keep them confidential. These are the specific items from the Facebook platform policy which address what you cannot do with user ids:
II
6) You will not directly or indirectly transfer any data you receive from
us, including user data or Facebook User IDs, to (or use such data in
connection with) any ad network, ad exchange, data broker, or other
advertising or monetization related toolset, even if a user consents
to such transfer or use. By indirectly we mean you cannot, for
example, transfer data to a third party who then transfers the data to
an ad network. By any data we mean all data obtained through use of
the Facebook Platform (API, Social Plugins, etc.), including
aggregate, anonymous or derivative data.
7) User IDs for any purpose outside your application (e.g., your
infrastructure, code, or services necessary to build and run your
application). Facebook User IDs may be used with external services
that you use to build and run your application, such as a web
infrastructure service or a distributed computing platform, but only
if those services are necessary to running your application and the
service has a contractual obligation with you to keep Facebook User
IDs confidential.
Make sure that your app doesn't break either of those rules or any other rule in the Platform Policy.