I have a question what is the difference if I just use a Oracle/MySQL service provided by PCF without binding it? What difference will it create. I can anyway access DB using the credentials
There are two differences that come to mind:
When you create a service through the Cloud Foundry marketplace, that will create backing resources for the service but in most cases it does not create credentials. The act of binding a service to your app, in most cases with most service brokers, will actually create service credentials for you. When you unbind, again with most brokers, the service credentials are destroyed. This makes it easy to regenerate your service credentials, just unbind/rebind the service and restart your app. The net result is that if you don't bind, there are no credentials.
Most people do not want to include credentials with the actual application (see https://12factor.net/ for details why). They want to be able to provide configuration external to the app. On Cloud Foundry this commonly amounts to binding a service.
Having said that, how do you want to provide the credentials to your application?
Service bindings are there to try and make life as a developer easier but you don't have to use them. If you want to pass in the configuration some other way, like via environment variables, a config file, or using a config service (Spring Cloud Config Server or Vault) those are fine options too.
If you do not want to bind a service to your app, the only thing you'll need to do is to create a service key instead. A service key is like a binding, but not associated with an application. It will also generate a set of unique credentials. You can then take the credentials from your service key and feed them to your app in the way that works best for you.
Ex:
cf create-service-key service-instance key-name
cf service-key service-instance key-name
The first command creates the service key, the second will display its credentials.
Related
I'm trying to connect an automated build. In the app I connect to a google api and in Cloud Run I access secrets both using different service accounts. It's just a test app so nothing major but I keep getting hung up with cloud build using the service account that I use to access the api to run the app. Anybody know of a way to dictate which service account is used to run the app while still using the key to access the api. My thinking is it has to be done in the build process with something in my cloudbuild.yaml or maybe can't be done?
The cloud build process is carried out by a special service account that handles everything. You can delegate the auth to other accounts but there really isn't any need. Running the container in cloud run and choosing a service account to access secrets is easy (from Cloud Run choose edit and deploy => security tab) and that service account has no bearing on how you access other api's with creds.json you add at runtime.
I have googled quite heavily the last couple of hours to see if I could use Google Secret Manager from an external service like AWS Lambda or my local PC. I could not find anything helpful, or something that describes properly the steps to do so.
I do not want to play with the APIs and end up doing the authenticating via OAuth myself, I wish to use the client library. How would I go about doing so?
I have so far referred to the following links:
https://cloud.google.com/secret-manager/docs/configuring-secret-manager - Describes setting up secret manager, and prompts you to set up Google Cloud SDK.
https://cloud.google.com/sdk/docs/initializing - Describes setting up the cloud SDK (doesn't seem like I get some kind of config file that helps me to point my client library to the correct GCP project)
The issue I have is that it doesn't seem like I get access to some form of credential that I can use with the client library that consumes the secret manager service of a particular GCP project. Something like a service account token or a means of authenticating and consuming the service from an external environment.
Any help is appreciated, it just feels like I'm missing something. Or is it simply impossible to do so?
PS: Why am I using GCP secret manager when AWS offers a similar service? The latter is too expensive.
I think that your question applies to all GCP services, there isn't anything that is specific to Secret Manager.
As you mentioned, https://cloud.google.com/docs/authentication/getting-started documents how to create and use a Service Account. But this approach has the downside that now you need to figure out to store the service account key (yet another Secret!)
If you're planning to access GCP Secret Manager from AWS you can consider using: https://cloud.google.com/iam/docs/configuring-workload-identity-federation#aws which uses identity federation to map an AWS service account to a GCP service account, without the need to store an extra Secret somewhere.
Is it possible for an app bound to a service to update this service? Or is it something only an admin Cf can do ?
For instance, I would like to execute the following command
cf update-service test_db -c '{"data":{"serviceStopped":true}}'
What I have in mind: create an app bound to test_db to update the value of the dictionnary.
Is it possible for an app bound to a service to update this service? Or is it something only an admin Cf can do ?
Yes, but it requires credentials. The application on CF itself has no permissions, so you would need to supply the credentials of a user or client that has permissions that the application can use to update the service.
Any user or client that is in the same org and space as the service with the SpaceDev role will have access to update the service.
If you want to have an application make calls to the Cloud Controller, like to update a database, you can do that by embedding the cf CLI and invoking it, you can use a library like the cf-java-client, or you can use the REST API directly.
Does anyone have an idea, how I can access the email address of the service account, which is running my cloud run service, at runtime?
When deploying the service to gcloud, I use a specific service account for running the service.
During runtime I need the email/ID of this service account, in order to do blob signing using IAMCredentialsService.
Is there a possibility to get the service account ID somehow? The ComputeCredential object I have at hand doesn't provide this information. Right now I have to set an environment variable which contains the service account email address, which I can use at runtime within the service.
In your cloud run container, you need to reach this URL (a GET)
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email
With this header
Metadata-Flavor: Google
If you have difficulty getting the value, provide your language and I will see if I can provide a code sample for you.
See more in documentation https://cloud.google.com/run/docs/reference/container-contract#metadata-server
Container instance metadata server
Cloud Run container instances expose a metadata server that you can use to retrieve details about your container instance, such as the project ID, region, instance ID or service accounts. It can also be used to generate tokens for the runtime service account.
You can access this data from the metadata server using simple HTTP requests to the http://metadata.google.internal/ endpoint with the Metadata-Flavor: Google header: no client libraries are required. For more information, see Getting metadata.
What is the use of service key in cloud foundry ? Today i create one cleardb service and then pick the VCAP_SERVICES credentials . Then easily connect the cleardb through HeidiSQL tool with these credentials.
Also tried the same things through ssh without service key and its connect successfully .
https://docs.cloudfoundry.org/devguide/deploy-apps/ssh-services.html
Please let me know the importance of service key .
Regards
Mukul K
Service keys allow you to get a set of (new) credentials for an app/use case outside of running CF apps. For example, you could get a new temporary ClearDB URI and pass it to mysqlsh on your laptop.
It is preferred to generate new creds for each use case/user rather than borrowing the creds from an app’s VCAP_SERVICE