I want to share a DB(PostgreSQL) service across the spaces in same cf Org.
I came across two options
User-Provided Service Instances (https://docs.cloudfoundry.org/devguide/services/user-provided.html)
Sharing Service Instance(https://docs-cloudfoundry-staging.cfapps.io/devguide/services/sharing-instances.html)
The shared service instances say, it improves the security, auditing, and provides a more intuitive user experience.
Can anyone throw some more detailed light on the advantages and disadvantages of both?
User provided services can do more than be used to share services, sharing services across org/spaces is just one use case for user provided services.
If you're looking to share services & your service broker supports it, you should use that option over user provided services.
User provided services are good for cases where the broker doesn't support sharing services or where you want to do something totally different like create a service where no broker exists.
Hope that helps!
Related
Following Coursera Architecting with Google Kubernetes Engine for switching to Service Account.
It says create and download a key file and authenticate using the key. Is this the common way in GCP? There will be many keys created by developers and downloaded to many laptops or servers scattering the keys in many places, which seems to be not secure manner.
Answering your question, yes. The service accounts are the common way to authenticate in GCP.
There are two different service account types, and the recommendation is to use the second one:
User Managed Service Accounts: to authenticate you will then need a “password” that comes in the form of Service Account Key (json file), and if you leak the service account key, the service account can be considered compromised.
Using keys implies that you are in charge of their lifecycle and security, and it’s a lot to ask because:
You need a robust system for secrets distribution.
You need to implement a key rotation policy.
You need to implement safeguards to prevent key leaks.
Google Managed Service Account: Google Managed Service Accounts, are SAs for which you don’t need to generate keys and your applications can just assume their identity. No keys are involved: the VM will continuously request short lived authorization tokens from the metadata service.
Documentation
NO, no and no, don't use service account key file. As you smell it, you are right, it's a terrible thing for the security.
Today, there are several way to prevent the service account key usage, even if, in some corner case, you need them.
I have wrote bunch of articles on that topics:
the limits
the service account credential API
and a fight against a Google dev advocate and one of his article
Because YES, even Google tutorials, courses, documentation (...) promote that bad practice for years and continue. It was my nightmare in my previous company, and I increased my knowledge and skill to prevent key usage and find workarounds. Let me know your use case, I will try to help your the most
Dear AWS and Cloud Gurus,
I am tasked with the design of a new AWS account structure that is to serve as a development and runtime environment for multiple development teams. The goal here is that multiple individual teams can work on different projects, each in their own AWS account but make use of some shared services and inherit certain elements from a top-level account.
An example for a shared service inherited from the top-level account would be billing. An example for a shared service on the same hierarchy would be authentication and authorisation services.
The projects the different teams work on are all accessible in the end through a unified platform / portal. The user logs onto that portal and can then execute different functions or even start complete applications which are actually developed by the different teams in their respective account.
Now my question is this: What would be a best practise approach on this? Should all teams work in a shared repository, or should each have their own code repository in their own account? Shall the deployment be done into a central account or should the teams deploy within their own account and the app is called from the portal from this account then?
I will try to picture this:
As you can see, there are essentially 5 different AWS Accounts:
The root/masdter Account holds the billing information and also allows for central administration of quotas
Then there are 4 AWS Accounts each with it's own Code Repository and independent access points. 3 of these hold different applications (developed as SPAs) while the forth provides a central navigation page (aka Dashboard) and also provides SSO to the other applications.
Is this setup feasible, given there are different, independent application development teams involved but the applications they provide are in the very end used from a central platform for the end user? How would you go about this?
With the kindest regards,
Chris
We are in the process of transferring what we currently have in our on-premises infrastructure to the cloud and taking advantage of what AWS has to offer. We are in the process of planning how we can make this process as smooth as possible, so one of the first things that came to mind was, What are the best possible solutions to implement what we currently have in our premises with users registered in AD and how we will be able to manage them, e.g. we create a new user in AD and automatically we can see that new user in our AWS environment so we don't have to manage them on premises as well as AWS and so they can sync?
The next question which I think the answer is Control Tower (and that's why I'm sending my question on this topic), but I would like to confirm and see if there are any other options out there that we might me missing.
As I said earlier, we are in the process of transferring our current on-site infrastructure to the cloud, so at this time we have three environments where we manage development: Development, Staging and Production. We thought of having each of them separated in their own AWS account so we can manage them individually but also we want a way to easy switch accounts between them and possibly get one consolidated bill for all of those three accounts but with the details in each account, and be able to easily make them communicate resources in one account to resources in another account. What would be the best solution for these challenges in AWS if someone can suggest best practices on these?
Thank you so much for your help!
For the AD connection, you can use the AWS AD Connector service. The official AWS blog has a tutorial: https://aws.amazon.com/blogs/security/how-to-connect-your-on-premises-active-directory-to-aws-using-ad-connector/
Billing for a multi-account organization is pretty straightforward, all sub-accounts pay through the root account so you won't have to worry about separation of billing.
Communicating between the environments (accounts), however, requires a bit more legwork. You can use a hub and spoke model and reach out to all environments from an individual environment, or, you can create trust relationships between roles and resources via IAM policy in different accounts and map them to one another.
I have seen many places in GCP documentation that service account based authentication is recommended over user account based. I couldn't find what is the actual reason behind it
Imagine that you have a service A running on compute A. You want service A to communicate with another service B running on compute B AND you want to use some form of protection (authorization) to only allow A and B to communicate and return errors for everything else.
If you use User Authentication, a person must be involved to authorize communication. Not practical for programs running on computers in the cloud.
Google implemented service accounts to provide authorization of machine to machine communication. The secrets are stored in a file. These secrets create a Token that is passed between services.
Do I need to set up an account and payment information for each provider I intend to use with libcloud? Are there any service offerings that allow you to sign up for payment once through them and interact with all libcloud listed providers easily?
Yes, you do. libcloud only offers an organized mechanism to interact with the public APIs of various cloud providers - it isn't a business of its own.
I've never heard of any company that lets you manage accounts across cloud service providers like you describe, other than reselling (like Heroku being built on AWS). You'll need to decide on what's valuable to you in a provider and do some research to see which one is the best fit for your needs!