I would like to add nodes to a certain vault before creating them, for example:
All vagrant machines that I provision with vagrant up that has the patter vagrant-dev-* could acces the chef vault secrets.
If i try to do this, I've got a warning that no one machine is on chef with that pattern.
WARNING: No clients were returned from search, you may not have got what you expected!!
If I try the command after the machine is provisioned it works, but then the provision fails because the machine does not have acces to the vault for configure the sensitive information.
knife vault create secrets root -M client -S "name:vagrant-dev-*"
How can I make the machines have access to the vaul before provisioning them?
Unfortunately this is not possible. For something to be added to a vault it needs to have an RSA public key available on the Chef Server. This is generally done as part of the node bootstrap and client creation. This is a structural limitation of this whole category of asymmetric pre-encryption systems, the keys for all secrets consumers must be known at the time of the pre-encryption process.
Related
I have the following configuration in Alibaba ECS:
Public Connector and Three Test Nodes
Connector has network connections on the public internet and the default VSwitch in the default VPC. Connector was created using the ECS web interface. The testnode[0-2] machines were created in a script using the Alibaba cli command: aliyun.
When the instances start running, the connector can ping none of them. If I set a password on any of the test nodes, and then restart the test node, ping starts working. The script uses a snapshot of the Connector as the image for the test nodes. The ```Connector`` has a randomly generated, long, and forgotten root password. Root access is via ssh with a passphrase protected key pair. It also has the same for a non-root user for the test code.
What I have tried is creating test nodes with the following CreateInstance options:
No --Password and no --InheritPassword options (original intent: why set a password? I have the access I need from the Connector image)
--InheritPassword option (I need a root password in order for the private network interfaces to work, the root password in the Connector image is fine)
--Password option (I need to explicitly set a root password on the test nodes)
The result is all the same, until I use the ECS web interface to set a password and restart a test node, Console cannot ping the test nodes.
What I know:
This is not a problem with the default security group, VPC, or VSwitch as I touch no settings on these entities in order for ping to work.
This is not a problem with the instance image because as soon as ping works, ssh to the test nodes works as well.
What I am doing wrong, or what am I missing? The whole purpose is to spin up instances without having to type away at the ECS web interface. I figured out what it took to get the private network traffic moving because I wanted to debug the situation on the test nodes, and for that, I had to set a root password and gain access from the ECS web console, which again, defeats the purpose of scripting.
Aliyun command for creating the test nodes:
aliyun ecs CreateInstance --ImageId m-2vchb2oxldfuloh51wp9 --RegionId=cn-chengdu --InstanceType=ecs.c6.xlarge --SpotStrategy SpotWithPriceLimit --SpotPriceLimit 0.25 --ZoneId cn-chengdu-a --InternetChargeType PayByTraffic --InternetMaxBandwidthOut 99 --InstanceName TEST_NODE-0 --HostName testnode0 --Password 'notgoingtotellyou'
Operating system for all instances is Ubuntu 18.0.4.
Aliyun command version is 3.0.30.
I got two answers. One from a co-worker. One from Alibaba.
Co-worker's answer:
The configuration fails because the Unbuntu 18.0.4 image that I created for the non-public test machines used a static address for the internal network interface. I changed the internal network interface (eth0) to use dhcp and all worked. See netplan configuration examples for how to change the IP address assignment.
Alibaba's answer:
Try using aliyun ecs RunInstances instead of three individual aliyun ecs CreateInstance and aliyun ecs StartInstance invocations. I did not try this solution as it would have involved rewriting my scripts. Alibaba could have done more to motivate me by providing an explanation as to why RunInstances would produce a different result than the combination of CreateInstance and StartInstance.
I am trying to automate bootstrapping a new node for instance an EC2 instance into Ansible as a slave node. I have seen some solutions like copying public keys using user-data. Can anyone suggest a more solid approach with an example on how I can achieve this? Thanks in advance
Ansible has two types of nodes
Master / Control Machines : The node from which ansible is invoked
Client / Remote Machine : The nodes on which ansible operates
Ansible's primary mode of transport is ssh, using which it applies the playbook to the remote machine. In order for ansible to ssh into the remote machine, ssh has to be already setup between the machine using private/public key authentication preferably.
When it comes to EC2:
1) Every node has a default key with which the instance is launched, and ansible could use this key to ssh, but this considered insecure / not a best pratice.
2) A key has to present in the client node, with which ansible can authenticate successfully, and the most preferred way is to pull the keys using user-data from a restricted S3 bucket.
I need to deploy my Java application to AWS EC2 Instance using terraform. The catch here, we should not use *.pem file to deploy the application.
I try to create ELB and associate instances using terraform.I can able to deploy the application using ssh and pem file to ec2 instances Private IPs. But we shouldn't use *.pem or *.ppk file, as it'll not be allowed in production servers.
I tried using chef with terraform , but that also requires *.pem to connect to AWS Instances.
Please let me know the detailed steps/suggestions of how to deploy the application using terraform without using pem file.
If you can't make any changes to your instance after creating it (including deploying the application) then you will need to bake any and all changes into the AMI that Terraform deploys.
You might want to look into using Packer to create AMIs with your intended configuration and then use Terraform to deploy these AMIs.
For reference, this strategy is known as "immutable infrastructure" so you might want to do some further reading into this area.
If instead it's simply that SSH connectivity is not allowed and you can make changes over other ports then you should be able to use an AMI that has a Chef client, Puppet agent or Salt minion on it (there may well be other tools that work over a non SSH protocol/port but this restriction rules out Ansible) and then use any of those tools to continue to configure your instance. Obviously you could find a suitable AMI from the AMI marketplace or, once again, use Packer to set up the relevant configuration management client.
Amazon only gives you a certain number of static ip address and the local (private) ips of each EC2 instance can change when the machine is restarted. This makes creating a stable platform where EC2 instances depend on each other ridiculously hard to use as far as I can tell.
I've search online a lot about various solutions and so far have found nothing reasonable outside of assigning an elastic ip address on ever EC2 even if its not public facing. Does anyone have any other good ideas that is actually easy to execute on?
Thanks!
See the AWS team's response to question Static local IP:
The internal IP address of EC2 instances is allocated via DHCP. On
instance shutdown, or when the DHCP lease expires, the IP address is
returned to the general EC2 DHCP pool of addresses available for other
instances.
There is no way to guarantee that you will obtain the same DHCP
address across reboots.
Edit: The answer is to use Amazon VPC. There is no downside except a trivial amount of extra setup because now you control the router. It's a world apart from plain old EC2 instance on AWS. It's so necessary in fact that VPC will be enabled for all future AWS setups by default. See this post for more information: http://www.reddit.com/r/aws/comments/1a3n0r/ec2_update_virtual_private_clouds_for_everyone/
The stock answers are:
Use AWS VPC so you have complete control over instance addressing
Use Elastic IPs, which will resolve to the instance's local address (not the public, as you'd expect) when used to communicate between EC2 instances
I stumbled upon third option. There's ec2-ssh by the Instragram folks. It's a python shell script that you install globally and lets you both query the public dns of your ec2 instances by tag name and also ssh in via tag name as well.
The documentation for it is virtually nonexistent. I've written down the steps to install below:
To install ec2-ssh:
sudo yum install python-boto (python wrapper for ec2 api)
git clone https://github.com/Instagram/ec2-ssh
In your ~/.bash_profile set your AWS access key and secret like so:
export AWS_ACCESS_KEY_ID=XYZ123
export AWS_SECRET_ACCESS_KEY=XYZ123
cd into the bin folder of the repo, there will be two files:
ec2-host and ec2-ssh
copy them to your /usr/bin or /usr/local/bin.
Now you can do awesome stuff like:
$ ec2-host ZenWorker
ec2-999-xy-999-99.compute-1.amazonaws.com
and
$ ec2-ssh ZenWorker
Connecting to ec2-999-xy-999-99.compute-1.amazonaws.com.
Note that in your regular shell scripts you can use backticks to call these global tools. I've timed these calls and they take between 0.25 and 0.5 second using an EC2 instance, so that's really the only downside. Perhaps you can live with the delay, or use the fact that public DNS only changes for an instance on reboot to work up a solution.
Note that these two programs are commandline scripts and you don't need any Python knowledge to use them. For PHP fans, or those that also want an easy way to scp files without knowing the changing public DNS, you can checkout ec2dns.
I was in the same situation once. I still dont have the expertise to solve it properly. My ugly solution was to use elb not really for load balancing but just for the endpoint.
But I think a good solution can be obtained by using aws vpc.
Here's another Ruby solution for Updating Route 53 DNS from instance on AWS. You shouldn't reference raw 3rd party system IP addresses in your applications or server configurations.
you can change Ip Address using Elastic Ip:
You Can Do Using C# Code:
var associateRequest = new AssociateAddressRequest
{
PublicIp = your Elastic Ip,
InstanceId = Your Instance Id Which You Assign
};
amazonEc2Client.AssociateAddress(associateRequest);
after That DeAssociate It.
var disAssociateRequest = new isassociateAddressRequest(publicIp.ElasticIpAddress1);
AmazonEc2Client.DisassociateAddress(your Elastic Ip);
your Public Ip Will Change
I've got an instance using this AMI - ami-b7a29cc3
http://thecloudmarket.com/image/ami-b7a29cc3--bitnami-wordpress-3-3-1-1-multisite-linux-ubuntu-10-04-ebs#/details
Which is a Wordpress Multisite Bitnami Image.
It's installed and booted up fine, I've setup the security groups SSH, HTTP, HTTPs.
But weirdly enough connecting via SSH is not working, despite the front end working fine.
I've tried the following users and commands to no avail, ubuntu, root and bitnami.
I keep getting something weird like this happen though when I run the command.
D-Hewards-MacBook-Pro:Downloads dheward$ ssh -i macbookpro.pem bitnami#176.34.127.170
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
9f:85:89:8a:7a:9d:db:e0:15:e4:11:d0:e0:4b:74:a9.
Please contact your system administrator.
Add correct host key in /Users/dheward/.ssh/known_hosts to get rid of this message.
Offending key in /Users/dheward/.ssh/known_hosts:17
RSA host key for 176.34.127.170 has changed and you have requested strict checking.
Host key verification failed.
D-Hewards-MacBook-Pro:Downloads dheward$
This is likely (i.e. you need to judge this yourself after reading and understanding my explanation, because otherwise your security would indeed be at risk!) just normal behavior of SSH coupled with reuse of the meanwhile scarce IP addresses by Amazon EC2 (see IPv4 address exhaustion):
Background
The server side of your SSH connection needs to identify itself by the mentioned fingerprint for the RSA key, which is subsequently checked by your client side SSH tooling to ensure you are not falling victim of a Man-in-the-middle attack.
Regular SSH Process
you connect to a new SSH server for the first time
the new server presents its RSA key identity to your SSH client
your SSH client asks you to confirm this servers identity and will import the RSA key in turn for future security checks (into /Users/dheward/.ssh/known_hosts in your case)
ideally you'd have received this RSA key on a secure channel to properly assess its validity, however, most people simply don't do that in nowadays ever changing cloud environments, see Eric Hammond's Poll: Verifying ssh Fingerprint on EC2 Instances
Eric's post mentions options to deal with this in principle already, i.e. For optimal security, you are supposed to request the instance console output and find the ssh host key fingerprint in the log to verify that it is the same as the fingerprint presented to you by the ssh command.
Furthermore, Eric discussed this topic in great detail in ssh host key paranoia.
Scott Moser has distilled a great summary how to actually Verify SSH Keys on EC2 Instances and provides instructions on how to update your known_hosts file in turn as well.
on every subsequent connect to the same SSH server, your SSH client will compare the stored RSA key with the one provided by the SSH server and will present a big fat warning regarding potential nastiness if it changes, because it usually shouldn't indeed (I'll skip the rare exceptions for now)
this means, if it suddenly changed (especially for a host you had been connecting to already without such a warning), you should indeed back out immediately and assess the situation first, i.e. if you don't know a reason for the change, your connection security is at risk
Cause (i.e. Your Experience)
You might have gone through steps 1-4 once for another SSH server on EC2, which happened to have the very same IP address from their pool (i.e. 176.34.127.170); while not encountered every day, this is all but unlikely over time given the limited number of IPv4 addresses available in general and the respective pool available for Amazon in particular.
Now, since you are connecting to an entirely different server then the one for which the RSA key had been stored in the first place (every started EC2 instance has a respectively unique identity), your SSH client cries foul and presents the properly escalated warning you are seeing.
Furthermore, it seems to disallow SSH access entirely in this situation, since you [or your system administrator] have requested strict checking. (Most desktop SSH clients seem to ask for confirmation just like on first commit in this case by default).
Solution
Make damn sure my explanation of your experience actually applies to your situation!
Follow the instructions given in the warning message already:
The fingerprint for the RSA key sent by the remote host is
9f:85:89:8a:7a:9d:db:e0:15:e4:11:d0:e0:4b:74:a9. Please contact your
system administrator. Add correct host key in
/Users/dheward/.ssh/known_hosts to get rid of this message. Offending
key in /Users/dheward/.ssh/known_hosts:17 RSA host key for
176.34.127.170 has changed and you have requested strict checking. [emphasis mine]
I.e. the SSH RSA key cache maintained in /Users/dheward/.ssh/known_hosts currently has an entry No. 17 for IP address 176.34.127.170 with a different RSA key then the one presented by the server with IP address 176.34.127.170 you are currently trying to connect to - this must be adjusted, if you are sure there is no man-in-the-middle-attack in place in fact (which is unlikely, given that this is a new host you just commissioned, though as mentioned in 3) above, you might want to ensure this by following Scott Moser's instructions how to actually Verify SSH Keys on EC2 Instances).
Good luck!