To easier follow the principal of least privilege, is there a way to generate the necessary IAM policy based on a CloudFormation template?
You can indeed use cloudformation to create policies via AWS::IAM::Policy resource.
Here is the documentation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-policy.html
Related
If we have a role change in the team, I read that EKS creator can NOT be transferred. Can we instead rename the creator's IAM user name via aws cli? Will that break EKS?
I only find ways to add new user using configmap but this configmap doesn't have the root user in there.
$ kubectl edit configmap aws-auth --namespace kube-system
There is no way to transfer the root user of an EKS cluster to another IAM user. The only way to do this would be to delete the cluster and recreate it with the new IAM user as the root user.
Can we instead rename the creator's IAM user name via aws cli? Will that break EKS?
The creator record is immutable and managed within EKS. This record is simply not accessible using CLI and not amendable (including DELETE).
How do we know a cluster was created by IAM roles or IAM users?
If you cannot find the identity (userIdentity.arn) in CloudTrail that invoked CreateCluster (eventName) for the cluster (responseElements.clusterName) in last 90 days, you need to raise it to the AWS Support to obtain the identity.
is it safe to delete the creator IAM user?
Typically, you start with deactivate the IAM user account (creator) if you are not sure of any side effect. You can proceed to delete the account later when you are confident to do so.
As already mentioned in the answer by Muhammad, it is not possible to transfer the root/creator role to another IAM user.
To avoid getting into the situation that you describe, or any other situation where the creator of the cluster should not stay root, it is recommended to not create clusters with IAM users but with assumed IAM roles instead.
This leads to the IAM role becoming the "creator", meaning that you can use IAM access management to control who can actually assume the given role und thus act as root.
You can either have dedicated roles for each cluster or one role for multiple clusters, depending on how you plan to do access management. The limits will however apply later, meaning that you can not switch the creator role afterwards, so this must be properly planned in advance.
I am a newbie to AWS cloudformation, any help will appreciated.
I have a use case wherein I would like to write CFN to update already existing secret string. I was able to find a CFN to create a secret string but not to update.
I see the AWS CLI has aws secretsmanager update-secret --secret-id I was looking for similar option in Cloudformation.
Use cloud formation template for create secret but instead of creating stack, update the existing stack using change set.
but do it you must know the stack name which is created before to create secrets.
may be use the same template which used earlier just change the value and update stack
I would like to use a Secret inside a ConfigMap. Is this possible?
Example:
An example where this might be required is if you would like to write from Fluentd to S3. In the configuration you have to add your AWS credentials.
Alternatives:
Using environment variables on the cluster itself. I do not like this idea, because the variable would still contain the secret as plain text.
Passing the password during set-up. If you are using deployment tools it might be possible to pass the secret during the deployment of your application. This is also not a nice solution since you are still passing the secret as plain text to the deployment tool. An advantage of this approach is that you do not accidentally check-in your secret to git.
Try to avoid making use of aws credentials in kubernetes.
As you can see aws_key_id and aws_sec_key are the optional fields.
Make use of AWS IAM role and assign it to the kubernetes nodes.
And then try to run your fluentd application without aws credentials in its config.
Just give it a try.
Hope this helps.
Update:
This article explain different ways to use aws iam for kubernetes.
Kube2iam and many other tools like this, might help. Give it a try.
No, it is not possible. You should always use secret for your sensitive data.
By default, secrets are only base64 encoded content of files so you should use something like Vault to secure store you sensitive data.
I want to create a role with specified arn by cloudformation in aws. But I don't know how to do it. Because we can't specify a name for the role in the template file.
Assuming you are referring to an IAM role, this is not possible using CloudFormation. CloudFormation will automatically generate a name for your role based on the stack name and the logical resource ID. For example, arn:aws:iam::112233445566:role/myStackName-myRoleName-XXXXXXXXXXXXX.
Our CloudFormation template creates an autoscaling group with a random name. Right now we need to go to the CodeDeploy console and manually add the new autoscaling group to the deployment group - we would like to automate this process. For example, it would be nice if we could create a staging environment using the CloudFormation template and deploy code to it without any manual steps.
I can see two ways to do it:
Get CloudFormation to always assign the autoscaling group the same name, and just configure it ones in the CodeDeploy console
Have CloudFormation modify CodeDeploy with the new autoscaling group name.
It seems like CloudFormation doesn't allow either approach - any ideas how to do this?
Here's what I would do:
Put the name of the autoscaling group in the Outputs section of your template.
After creating the stack, call describe-stack to retrieve the autoscaling group name from Outputs.
Use the CodeDeploy API to add the autoscaling group to the deployment group.
If you put this in a simple script, you can easily create as many ad-hoc stacks/staging environments as you please. (And you probably want a similar script for removing the stack.)