I have an architecture I am using service catalog to trigger lambda backend resource (lambda backed cloud formation resource).
does the service catalog allow resource policy to be applied to a product or do I have to control access using the IAM role to the user only?
Related
Can I use the IBM IAM console to create a new ServiceID with an api key, for the purpose of accessing an IBM Cloudant instance?
Yes you can!
The IBM IAM service allows you to create a ServiceID, which is a machine-usable 'persona'. Then you can create an API key for it and give it permissions to access one or more IBM services, like Cloudant.
Start at https://cloud.ibm.com/iam and then:
Create a new ServiceID
Under Access Policies, click Assign Access. Here you can choose the service that you want to access and what roles you want to authorise (e.g. Reader, Writer, etc). Here you can assign more than one service to the same ServiceID.
Under API Keys, choose Create. This will create an API key which you can download.
Now you can use the API key in your application and you should be able to access your service.
Individual IBM services normally offer their own access mechanisms. But the advantage of this method is that you can use the same API key to access multiple services (e.g. Cloudant, Cloud Object Storage) from your application.
I have an existing instance of Db2 Warehouse on Cloud which is deployed to an org and space. Now, I would like to bind that service to an app for deployment with IBM Cloud Code Engine.
ibmcloud ce application bind --name henriks-app --service-instance myDb2
myDb2 does not exist as IAM resource because it is a CF resource. How would I bind the two together? It seems that I would need to create some form of custom wrapper.
The best way to manually connect services to your Code Engine application is to add service credentials to a Code Engine secret, and then attach that secret to your application using environment variables or volume mounting.
While you're correct that Db2 Warehouse isn't a typical IAM-Enabled service type, based on the IBM Cloud Db2 Warehouse docs, it's possible to create a client connection with Db2 Warehouse using an IAM Service ID & API Key.
Here's how I'd "bind" the Db2 instance to a Code Engine app:
Create a new service ID from the IAM Service IDs page
Under "Assign Access" > "Access service ID additional access" > "IAM Service", you'll find "Db2 Warehouse" as an option, and you can configure exact permissions from there (e.g. which instance(s) to grant permissions to, which roles, etc)
Finish the configuration by clicking "Assign access"
Using the CLI, log in to your account and generate a new API Key, e.g. ibmcloud iam service-api-key-create mydb2key SERVICE_ID_NAME --output JSON > mydb2.json where SERVICE_ID_NAME is the name of the service ID created in Step 1
Target your Code Engine project, then create a new secret using the API Key JSON, e.g. ibmcloud ce secret create --name mydb2 --from-file MYDB2=mydb2.json
Attach the secret to your application as an environment variable, e.g. ibmcloud ce app update --name myapp --env-from-secret mydb2
After the app update goes through, your application will have access to an environment variable named MYDB2, which will have the value of a JSON object string containing your API Key.
You'll find more information about creating secrets and using secrets with applications in the Code Engine docs.
There are 2 commands I am confused for some time:
gcloud iam service-accounts get-iam-policy
gcloud iam service-accounts set-iam-policy
from the --help command, these 2 commands treat service account as a resource, most often I use service account as an identity, for example, in a project, set policy by binding role with service account so this service account can operate on something in that project.
Can someone please point out what is the usage to attach the policy to service account? how does service account act as a resource rather than an identity?
As explained in this below part of the official documentation Managing service accounts
:
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
So, use it as a resource has to goal for you to manage who can use and control the service account. To provide some additional details, as in this example here, with the policies attached to them, you can configure the level of access that different users can have within service accounts - as mentioned there, you can configure that some users have viewer access, while others have editor level.
To summarize, the functinality of attaching policies to a service account is for you to set different levels of access and permissions to users who can access the service account.
I'm following the instructions on how to connect from GKE to Cloud SQL: https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine
It talks about YOUR-GSA-NAME. Google cloud creates "Compute Engine default service account" by default. Should I pick this one or create another service account for GKE only? What is the recommended way?
The Compute Engine default service account won't be able to connect to Cloud SQL out of the box, you'll have to add permissions to it (Cloud SQL Client role) for it to be able to connect.
I would create a new one however, as you likely don't want all GCE instances to be able to connect to Cloud SQL, and for permissions, best practice is to limit access. So just create a new SA (service account) with the Cloud SQL Client role (and any other permissions you might need GKE to access) and use that one.
This is all found in IAM -> Service Accounts in the console.
I have a project whose resources spanned across 3 resource groups. I want to create a Service connection scoped to all those resource groups so that i can manage access at one place through that service connection. Currently i created 3 service connections scoped to each resource group. I don't want to scope it to subscription since there are other teams handling projects in that subscription. It will give me maintenance and audit issues in the future.
If i create a service principal and assign it to 3 resource groups and then attach this service principal to service connection then would it be good design?
Is there any better way to achieve this ?
When you create a new Service Connection in the Azure DevOps, it will create an Azure AD app registration, and a new service principal will be created for the Resource Group you choose.
So you can just go to any resource group and then add a principal using the Access control (IAM). Select the Add role assignment option and then select the role as a contributor in the role grid, press next. From the next screen, select user, group, or service principal as the option for Assign access to. Click on the + Select members, search for our AD Registered app name, the display name and then select the same from the result, click on the select button. Finally, click the Review + assign button.
I have written a detailed article to explain the steps, you can read that here.
You don't have to create the service principal manually. You can use the interface to create the service principal, grant permissions on the first resource group and configure the connection automatically for you.
Then once it's done, look at the service connection to identify the service principal in use, and give it permissions on the other resource groups.
And yes it is a good design, the only drawback compared to 3 service principals is that you have less granularity over who in Azure DevOps has access to each of these 3 resource groups via permissions on the service service connection(s) (as you only have one and not 3)