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
Related
I'm working on a Slack app which will have to store access token per each customer using the app (ex. 1000 teams using it = 1000 tokens). Token enables the app to access Slack API for customers workspace and will be used frequently every day.
App will be running on AWS, using Lambda's and DynamoDB.
What would be the best practice to store those access tokens securly?
I cannot find any strict recomendation for this scenario. Was thinking initially to put those in DynamoDB in a dedicated table but thinking now if I should use other AWS services for that use case. I've checked Secrets Manager but looks like a rather expensive option and not sure if it applies to my scenario.
Appreciate any suggestions.
I would probably use a dedicated DynamoDB table for this purpose. At a minimum, I would configure it to use a KMS CMK to encrypt the data at-rest, and also restrict access to the table through fairly granular IAM permissions in your AWS account. If you also wanted to encrypt each value separately you could look into client-side encryption.
Your findings on the Secrets Manager costs are a good point. You could also look at Systems Manager Parameter Store as an alternative that is generally cheaper than Secrets Manager. Secrets Manager does have the added security of being able to set an IAM resource policy on the secret itself.
Ultimately it's up to you to determine how secure your solution needs to be, and how much you are willing to pay for that. You could even spin up an AWS HSM to encrypt the values, but that would increase the cost by quite a bit.
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.
One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.
Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?
I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.
AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.
In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.
Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.
The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.
Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.
As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.
From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.
Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.
Links:
[1] https://cloud.google.com/docs/authentication/getting-started
[2] https://cloud.google.com/docs/authentication/
For local development (including other team members) should we be using application default credentials for our apps, or service accounts when authenticating and using Google Cloud Platform services?
I was thinking that being able to control the individual user permissions instead of a random service account would be better, as it also prevents us from having to revoke the whole service account key if someone leaves the team. Whereas if we used ADC, it would just work as we'd disable their account and remove its permissions. However, the documentation in the Authentication overview contains this note:
Important: For almost all cases, whether you are developing locally or
in a production application, you should use service accounts, rather
than user accounts or API keys.
What is the correct authentication method to use for local development?
From the same page:
All GCP APIs support service accounts. For most server applications that need to communicate with GCP APIs, we recommend using service accounts, as they are the most widely-supported and flexible way to authenticate.
In this sense, the randomness of the service account is determined only on your way of managing it.
For your scenario, when someone leaves the team, it would indeed be easier to revoke the user account('s permissions), instead of revoking the key, affecting all using it. In my opinion, both ways are correct and the best way would be the one that best suits your context. The documentation pushes for service accounts as it is a Google account, as opposed to a specific user, and it can be used for authentication regardless of where your code runs.
I am a longtime Amazon.com customer, and now I am interested in using Amazon Web Services (AWS). So I have a question on creating an AWS account.
Do I have an option to create an AWS account that's completely separate from my Amazon.com account (with different email addresses)?
What would happen if I use the same email address for AWS and Amazon.com?
Soooo..... Ages ago... I made an AWS account, it will not let me log in to normal amazon.com with that account telling me every time my password is incorrect which it is not.... attempting to create a new account with same email asks me if i want to disable my old account..... so yea it seems the answer is:
YES: simply create the account from AWS.
If creating accounts at amazon.com THEN aws with same e-mail, you will have one linked account to log in to both.
On the other hand if both are created seperately on different e-mails, and somehow one gets compromised the other doesn't, but then you have two different logins to deal with.
So as it turns out they lied about it disabling my aws account, I decided to try it, and now I have two accounts under the same e-mail, with different passwords... So if you want that, create on aws first, then create with same email on amazon.com and when it says it will disable the other account, don't worry it won't, however it will require you to choose a different password.
Oh and one last thing... If I try to log into AWS with Amazon.com password it brings me to create a new AWS account and it's a pain to get out of that screen...
My Amazon Retail account was compromised last week. I closed it and guess what - no access to my Amazon AWS account. On querying this I was told (by Amazon) that you have to have an Amazon Retail account and that it has to be THE SAME account as your AWS one.
So a service that is a honeypot for criminals gives them the keys to your Web based business, and Amazon have zero interest in separating the two. That is nuts - sites are moving next week, can't take the risk.
People have been shouting about it on the Amazon forum for years, so I think that whilst there may be workarounds the fundamental principle must be correct. I can't risk playing about with workarounds for something as dumb as this.
These are both great questions
First,
Yes, you can and SHOULD create an aws root account email that is unique for your AWS account(s). While approaches may vary, and your email server may filter out what would otherwise be perfectly applicable emails, here is how I do it
I create an email account that is ONLY for my AWS root accounts.
AWS Requires EVERY AWS account to have a unique email
here is my pattern: myname.aws.accts#gmail.com
I have an admin (Organization) account, so I use the following email: myname.aws.accts+admin#gmail.com
I have one prod, one test and one dev account. Here are the following email patterns:
myname.aws.accts+prod#gmail.com; myname.aws.accts+test#gmail.com; myname.aws.accts+dev#gmail.com.
I've also used the pattern: myname.aws.accts+123456789012#gmail.com where 123456789012 represents the AWS Account number.
These are all interpreted as unique by AWS but route to the same email account: myname.aws.accts#gmail.com
One last comment. I have another client who uses MS Exchange and for some reason the email+extension#mybiz.com has the 'extension' portion filtered out, and these emails do NOT process. In this biz we worked around this by creating alias' emails that are still unique to AWS and aliased them in the exchange server to the awsadmin# email. does the job. probably not best practice, but in a pinch...
Second
Yes. You can link your AWS and amazon.com accounts to the same root user email.
DON'T DO IT
This is generally an anti-pattern. NOT best practice, and fraught with problems...
I know of no good reason to do this. Once done, it is nigh near impossible to convince AWS - AMAZON to unlink these accounts. You WONT be able to separate them yourself - they are strongly coupled once the link is made. you might succeed in separating your AWS and AMAZON account if you are a paying customer of AWS business or Enterprise level support, and even then, they may tell you to just delete the AWS account if you don't want AWS and amazon shared.
Once the two accounts - store and AWS - are created with the same email account, I believe they are forever linked via a single master Amazon account, and there seems to be no way to separate them: If you change the password or email address on one, it reflects in the other.
When my only AWS use was an unimportant VM with a website, it was no big deal, but once I start hosting higher-value stuff, it gets a lot more scary.
As far as I can tell, the only way to separate them is to create a new AWS account (with different email address) and transfer your resources from the old to the new.
This appears to be a painful exercise, you can't directly move an EC2 instance, though you can transfer a snapshot of an image, but everything else I don't know about yet. I would be surprised if I could transfer a fixed Elastic IP, which means changing an IP address I've been using for a long time.
In the short term - as far as I can tell - the only way to secure AWS from your consumer account compromise is to put MFA on the AWS account and then use IAM for access. That's not a bad idea anyway.
I'll be creating a new AWS account (with different email address) for all stuff going forward, and transitioning old-to-new as I get to it, but this looks like a miserable (and unbillable) exercise.
It's just crazy that Amazon doesn't appear to have a way to address this.
Yay for me being an early adopter?
EDIT: It might be possible to link two accounts via "Organizations"; that might give some options for migration that are a bit less painful. Not sure yet.
EDIT Nov 2022: Amazon appears to have rolled out split credentials: when I logged into my unified account - same email for store and AWS - it invited me to create a diff password for the AWS stuff. This is wonderful!
So your AWS and Amazon are the same accounts so you cannot create a separate retail account with the same address. (Though you can get around it by doing email+SOMETHING#domain.toplevel) So if your amazon.com account gets compromised, they theoretically have access to your AWS account.
To keep your AWS account secure, there are a few things you can do. Firstly and probably most importantly, you need to make sure you have MFA setup on the account. In fact, you should do this whether you use amazon.com with the same account or not.
I heavily suggest looking at the Trusted Advisor Best Practice Checks on AWS' website.
The rule of thumb here: they are not interchangeable.
If you created AWS account it will not allow you to login automatically to Amazon.com.
The same with consumer account, it doesn't provide access to AWS by default, because AWS has separate verification process.
Amazon Music account means access to consumer Amazon.com but not to AWS.
Though, I never tried to delete AWS and don't know what happens if you delete either of them, whether this causes deletion of the other or not.