Answers: <p>The prerequisites for a chef server are <a href="https://docs.chef.io/install_server_pre.html" rel="nofollow noreferrer">here</a> and common to any installation.</p>
  
  <p>You only need to allow https to port 443 from your inner infrastructure to the cloud server.</p>
  
  <p>If you have a proxy with SSL interception I'd recommend adding this proxy certificate to each client <code>cacert.pem</code> and set an environment variable <code>SSL_CERT_FILE=&lt;chef_install_path&gt;embedded/ssl/certs/cacert.pem</code> so other call from different ruby tools using openssl will also work.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-30T13:07:14.720Z
Answers: It's also a good idea to either a) IP restrict public internet access to your Chef server to your on-prem IP(s), or b) use a VPN connection to Azure to join on-prem to cloud and access it using private IPs.
Answers: Adrian
Answers: CC BY-SA 3.0
Answers: 2017-06-30T13:13:19.690Z
Answers: @Adrian every communication with the chef server have to be signed with a private key (client or user) and happens within a SSL tunnel, doing a SSL tunnel withing a VPN tunnel doesn't make much sense. IP restriction prevent DoS attacks, but that's usually not a real problem if the chef server is not accessible for a while due to the model of periodic configuration enforcing.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-06-30T13:16:43.427Z
Answers: SSL prevents eavesdropping/MITM attacks but does not provide any security against DDoS, brute force attack of the password-based web login, etc. And generally speaking, if you don't need to expose your central infrastructure management system to the entire world, you shouldn't. It certainly doesn't hurt to maintain simple best practices of least privilege and minimal attack surface.
Answers: Adrian
Answers: CC BY-SA 3.0
Answers: 2017-06-30T13:19:22.760Z
Answers: @Adrian that's a position, the web interface being a paid option, it is not in scope for the actual question, there's no login/password access. The only risk is a DoS and I gave my toughs above about it :) You're point is valid, I just don't deem it necessary here.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-06-30T13:25:22.360Z
Answers: Did they remove the basic web UI from Chef OSS? It's there in v11, just not as full-featured as the one in enterprise. I'm not saying it's necessary, I'm saying the LoE for the additional security is next to nothing, there's *no reason not to be more secure*. I don't see why anyone would advise *against* free extra security.
Answers: Adrian
Answers: CC BY-SA 3.0
Answers: 2017-06-30T13:31:39.093Z
Answers: In chef 12 it's free until 25 nodes, v11 is outdated and soon EoL. I don't recommend against, I just say that's not always so easy, some office have dynamic IPs and with a central server doing an IP filter is a hassle not worth the effort. I won't recommend absolutely setting an IP ingress filter on a chef server, that's out of scope for this question.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-06-30T14:39:34.643Z
Answers: @Tensibai - Adrian is right here - a site-to-site VPN *might* be called for. While Chef might operate over SSL which is OK in some scenarios, VPN tunneling makes sense if the user needs access to other devices: perhaps he is doing software defined networking and needs to access to networking equipment APIs or logins. Perhaps he needs to access a NAS to export SAMBA/CIFS/NFS mounts. It just depends on the use case.
Answers: James Shewey
Answers: CC BY-SA 3.0
Answers: 2017-06-30T14:52:06.517Z
Answers: @JamesShewey The question is using a Chef or Puppet server on Azure, while the VPN _may_ be something useful **if** there's other needs, it is irrelevant to this specific question. As "do not put passwords into cookbooks attributes" would be a far more relevant advice, but still off scope for this specific question. I won't go over each and every security good practice on system administration on a question asking "Is that possible?". the answer is yes it is, I already go a little further with ports to open and a word about SSL interception for the minimum for it to work.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-06-30T07:48:32.417Z
Answers: 2017-06-30T07:48:32.417Z
Answers: Tensibai
Body: <p>I would like to use Azure Chef server (or Puppet, or any other solution) from Azure to manage my infrastructure (around 25 servers and 20 desktops) wich is on-premise behind a corporate firewall.</p>
  
  <p>Is that possible? I tried searching for a similar solution but all I can find are articles how to manage Azure infrastructures.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-06-30T02:55:05.140Z
Comments: My assumption is definitely yes if there are no firewall related issues.
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2017-06-30T04:00:34.150Z
Comments: I tought so, but was looking for some kind of article about setting this up and what are common problems having this setup. Thank you for your comment.
Comments: Philippe
Tags: <chef><azure><puppet>
Title: Can I run Chef/Puppet server from Azure and manage my on-premise infrastructure?
UserDisplayName: Philippe
ThreadText: # Can I run Chef/Puppet server from Azure and manage my on-premise infrastructure?
  
  (Asked by: username_0 on 2017-06-29)
  
  I would like to use Azure Chef server (or Puppet, or any other solution) from Azure to manage my infrastructure (around 25 servers and 20 desktops) wich is on-premise behind a corporate firewall.
  
  Is that possible? I tried searching for a similar solution but all I can find are articles how to manage Azure infrastructures.
  
  **Tags:** chef, azure, puppet
  
  > **Comments:**
  > **username_1**: My assumption is definitely yes if there are no firewall related issues.  
  > **username_0**: I tought so, but was looking for some kind of article about setting this up and what are common problems having this setup. Thank you for your comment.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-06-30. Score: 3 | Accepted answer
  
  The prerequisites for a chef server are [here](https://docs.chef.io/install_server_pre.html) and common to any installation.
  
  You only need to allow https to port 443 from your inner infrastructure to the cloud server.
  
  If you have a proxy with SSL interception I'd recommend adding this proxy certificate to each client `cacert.pem` and set an environment variable `SSL_CERT_FILE=<chef_install_path>embedded/ssl/certs/cacert.pem` so other call from different ruby tools using openssl will also work.
  
  > **Comments:**
  > **username_3**: It's also a good idea to either a) IP restrict public internet access to your Chef server to your on-prem IP(s), or b) use a VPN connection to Azure to join on-prem to cloud and access it using private IPs.  
  > **username_2**: @username_3 every communication with the chef server have to be signed with a private key (client or user) and happens within a SSL tunnel, doing a SSL tunnel withing a VPN tunnel doesn't make much sense. IP restriction prevent DoS attacks, but that's usually not a real problem if the chef server is not accessible for a while due to the model of periodic configuration enforcing.  
  > **username_3**: SSL prevents eavesdropping/MITM attacks but does not provide any security against DDoS, brute force attack of the password-based web login, etc. And generally speaking, if you don't need to expose your central infrastructure management system to the entire world, you shouldn't. It certainly doesn't hurt to maintain simple best practices of least privilege and minimal attack surface.  
  > **username_2**: @username_3 that's a position, the web interface being a paid option, it is not in scope for the actual question, there's no login/password access. The only risk is a DoS and I gave my toughs above about it :) You're point is valid, I just don't deem it necessary here.  
  > **username_3**: Did they remove the basic web UI from Chef OSS? It's there in v11, just not as full-featured as the one in enterprise. I'm not saying it's necessary, I'm saying the LoE for the additional security is next to nothing, there's *no reason not to be more secure*. I don't see why anyone would advise *against* free extra security.  
  > **username_2**: In chef 12 it's free until 25 nodes, v11 is outdated and soon EoL. I don't recommend against, I just say that's not always so easy, some office have dynamic IPs and with a central server doing an IP filter is a hassle not worth the effort. I won't recommend absolutely setting an IP ingress filter on a chef server, that's out of scope for this question.  
  > **username_4**: @username_2 - username_3 is right here - a site-to-site VPN *might* be called for. While Chef might operate over SSL which is OK in some scenarios, VPN tunneling makes sense if the user needs access to other devices: perhaps he is doing software defined networking and needs to access to networking equipment APIs or logins. Perhaps he needs to access a NAS to export SAMBA/CIFS/NFS mounts. It just depends on the use case.  
  > **username_2**: @username_4 The question is using a Chef or Puppet server on Azure, while the VPN _may_ be something useful **if** there's other needs, it is irrelevant to this specific question. As "do not put passwords into cookbooks attributes" would be a far more relevant advice, but still off scope for this specific question. I won't go over each and every security good practice on system administration on a question asking "Is that possible?". the answer is yes it is, I already go a little further with ports to open and a word about SSL interception for the minimum for it to work.  
  
  ---
  
  