I was following railscasts to use rubber to deploy my rails app to ec2. I got the following problem:
$ cap rubber:create_staging
..... (omit successful part)
/Users/brian/.rvm/gems/ruby-1.9.3-p327/gems/excon-0.25.3/lib/excon/middlewares/expects.rb:10:in `response_call': SecurityGroupLimitExceeded => You have exceeded the number of VPC security groups allowed per instance. (Fog::Compute::AWS::Error)
how can I avoid this problem?
The issue is that by default Rubber is creating different security groups for each role. You will notice the console printing numerous "Creating Security Group #{x}" lines. The max allowed without petitioning is 5 (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html) without petitioning.
First run cap rubber:destroy_all.
To force Rubber to use only one security group go into rubber.yml and set...
auto_security_groups: false
isolate_security_groups: false
After that it may work, or you may get error saying security groups exists... Go here to read how to access security groups. Once in the panel delete all security groups but "default". http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#DeleteSecurityGroup
If you are getting errors about rules, then select the "default" user group in the AWS panel . This will bring up the rules. Delete all custom TCP rules. After this everything should work. You may need to repeat deleting groups and rules, since Rubber seems to do a terrible job of managing those.
You can request the VPC limits for your account to be raised via this form.
Related
I am running a windows 2016 server, we are running IIs 10 on it and i need to be able to assert if there is an AppPool setup before i deploy a website. If it doesn't exist i need setup the AppPool with a specific user and password.
All of this is done using a release agent through Azure Devops.
The agent is running as a NON-ADMIN, and i all accounts involved are running as NON-ADMIN. I have no intention at all to run any admin accounts, for security reasons i want to give least privildges to all accounts involved.
when i try to set up a AppPool using appcmd.exe i get the error msg:
KeySet does not exist.
When running everything as admin it works (and i have absolutely no intention in running any of this as admin).
What i have tried:
i have added the non-admin account to the IIS_IUSRS group.
Made sure that the user has read permissions to the file: 76944fb33636aeddb9590521c2e8815a_GUID in the %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys folder.
i have tried everything here: Error when you change the identity of an application pool by using IIS Manager from a remote computer
anyone that actually knows the cause of this problem?
UPDATE:
Microsoft clearly recommends that agents should be run using service accounts, which i am doing and i have no interest in giving build agents administrative rights to 1000s of servers when they clearly don't need that kind of powers actually. I want to restrict their powers to only be allowed to do what they need to do. I can't believe that giving everything admin is apparently the norm.
After a lot of googling, and i mean A LOT. I managed to solve this. And let me say, that it baffles me that "least privileged accounts" is not common practice in the Microsoft and windows world.
I found this excellent post by InfoSecMike locking down azure devops pipelines.
And we both have the exact same requirements and opinions on this topic.
You CLEARLY don't need admin rights to update IIs configurations (because that would be insane, right!?). The IIs configuration API does not care what rights you have, what you do need is access to certain files. But this is not documented. Microsoft themselves, just for simplicity, tells you that you need to be admin, and buries all the details really deep in documentation when this should be best practice. Also what amazes me is that no one questions it.
What you need is the following:
full access to C:\Windows\System32\inetsrv\Config
full acccess to C:\inetpub
read access to three keys in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\
6de9cb26d2b98c01ec4e9e8b34824aa2_GUID (iisConfigurationKey)
d6d986f09a1ee04e24c949879fdb506c_GUID (NetFrameworkConfigurationKey)
76944fb33636aeddb9590521c2e8815a_GUID (iisWasKey)
The 2 first bullet points can be obtained if you make sure your service account is a member of the group IIS_IUSRS.
This group will not give you access to the keys. You need to manually give read permissions to these 3 keys to the agent user.
If you don't give access to these keys you will get the obscure error message
Keyset does not exist ( exception from HRESULT : 0x8009000D)
Which is an incorrect error if you ask me as it should be an IllegalAccessException with proper reason telling you that you don't have access to read the key because the keys are there, they do exist (nice code microsoft, maybe you should open source this so we can fix).
I'll leave with this quote from infosecmike.
The goal was to lock down the permissions of the Azure Pipeline Agent {...}. I started Googling, pretty sure I would find a way to achieve this goal. I didn’t. It’s surprising to not find an answer about this. It seems like the principle of least privilege does not apply anymore in a devops world.
This is why i prefer Linux over Windows. This is a simple task there.
I want to create a 2-level security group heirarchy in AWS.
Location Groups - groups of IP addresses specific to different locations (e.g. "office", "home", "customer 1", etc.). Each of these base groups grants each IP access to All Traffic (ports 0-65535)
Environment Groups - I then am trying to add these base Location Groups to my higher-level Environment Groups (e.g. "test", "prod", "reporting db", etc.). I will use Environment groups for my different instances in EC2. So a server "uat_01" for example will reference the "test" environment group, which will in turn grant access to "office", for example.
Here's my inbound rule setup for security group sg-f2d8.... (office)
I'm adding the base groups using port ranges for access to HTTP (or HTTPS, or MySQL, etc., based on need), and referencing the base group using "Custom" configuration with the group identifier, e.g. "sg-f2d8...."
In the Security Groups panel, everything looks ok, but I can't get access from the selected IPs.
Please help! I've been told EC2 Security Groups can reference base groups this way, but I can't seem to figure it out!
Thanks!
When you put a security group as the source of an inbound rule (or destination for an outbound rule) you are referencing the resources associated with that group (i.e. the ec2 instances that you create that belong to said group) not really allowing the traffic that the group would allow (this is kind of a common misconception on aws-security groups). There is also no transitivity between security groups by referencing them this way.
Now in order to achieve what you want to achieve, the only workaround i can think about is creating groups of the style home-test, office-test, home-prod and putting in each one the source ip that you would see fit. At the end of the day these would be just "1-level" security groups.
The formal answer would be that no, you cannot create hierarchical aws sec groups.
We are using IAM permissions for groups and users with great success for S3, SQS, Redshift, etc. The IAM for S3 in particular gives lovely level of details by path and bucket.
I am bumping into some head scratching when it comes to EC2 permissions.
How do I create a permission that allows an IAM user to:
create up to n instances
do whatever he/she wants on those instances only (terminate / stop / describe)
...and makes it impossible for him/her to affect our other instances (change termination / terminate / etc.) ?
I've been trying Conditions on tag ("Condition": {"StringEquals": {"ec2:ResourceTag/purpose": "test"}}), but that means that all of our tools need to be modified to add that tag at creation time.
Is there a simpler way?
Limiting the number of instances an IAM user can create is not possible (unfortunately). All you have is a limit on the number of instances in the entire account.
Limiting permissions to specific instances is possible, but you have to specify the permissions for each instance-ID, using this format:
arn:aws:ec2:region:account:instance/instance-id
More information is available here:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-iam-actions-resources.html
A question that has stumped me for a while. I know this is possible over domains using Active Directory and all the rest, but what about on a basic local machine running on a basic network with many users.
Say this local machine is a communal work machine, which anyone with an account can use. All accounts are local, and are not roaming or on a domain, they are local to the machine.
Each user has different privileges, and are separated by groups.
While trying to create a group policy for a certain group, the group doesn't actually show up in the list. All that shows up in the list, are the local accounts individually, and two categories/groups: Administrators and Non Administrators
Where are the other groups? Why can I not create multiple policies specific to each individual group (Group1, Group2, Group3) that I have created?
The selection text quotes: "Local Users and Groups compatible with Local Group Policy". This seems to say that the groups I create seem not to be compatible with Group Policy?
Is there any fix to make custom groups 'Compatible' with Group Policy? Perhaps a registry or DLL fix?
Go to the Group Policy Management Console (gpmc.msc) and navigate to the required Organisational Unit. Right click, and select "Create a GPO..." and give it a name.
Right click on the newly created Group Policy Object, and deselect "Link Enabled" to prevent it from applying before you have finished configuring it.
Configure your GPO, and in the GPO Security Filtering panel, you are able to Add/Remove specific Active Directory users, groups and computers in which you want your GPO to apply to.
Hope this helps you
I have created the three security groups for the testing purpose on amazon aws. Now I want to delete them. But, every time I try to delete them it gives me the error:
Group XXXXXXX:testcluster is used by groups: XXXXXXXX:testcluster-master XXXXXXX:testcluster-zookeeper
Also, there is no option to delete multiple groups. How can I delete them?
The rules will reappear in the security group if you do not save any changes done.
You will have to do the following:
Go to your security group "testcluster-zookeeper".
Delete all referenced rules to testcluster
Press the "apply rule changes" button
Go to testcluster-master repeat steps 2 and 3
I had the same problem and solved it by editing the groups I wanted to remove and then deleting each and every inbound and outbound rule. Once this change was made I was able to delete the groups that were referencing each other.
Remember to delete also reference in ElastiCache security groups.
First delete all dependencies between the groups (any rules that refer one to the other) and then you can delete the groups themselves.
The reason you are not able to delete this is simple, Security Group you want to delete is being used in some other Security Groups Inbound/Outbound rules. Please delete them and you will be good to go.
It is quite tricky to delete instances from AWS, especially EMR instances as for some reason they keep getting automatically recreated on deletion. The simplest way I found was to go to the VPC settings and delete those. Was very helpful there on to delete the rest of the stuff.
P.S. I was trying to delete all my instances, hence took this route. In fact i decided to close my account which i had created for academic purposes. I did lose a lot of money unintentionally since i left the instances on for a couple of days, my bad! :(
make sure you delete , in-bound references of chosen security group from other security groups , vice-versa. I encountered this issue , removed in-bound/outbound references to fix
Maybe you encountered the same problem as mine.
I have 2 security groups refers to each other. I tried delete them many times but didn't work. Then I realized inbound rules of them refers to each others. I deleted the inbound rules first --> delete the groups --> works