<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>

CC BY-SA 3.0
2017-06-30T13:07:14.720Z
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.
Adrian
CC BY-SA 3.0
2017-06-30T13:13:19.690Z
@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.
Tensibai
CC BY-SA 3.0
2017-06-30T13:16:43.427Z
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.
Adrian
CC BY-SA 3.0
2017-06-30T13:19:22.760Z
@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.
Tensibai
CC BY-SA 3.0
2017-06-30T13:25:22.360Z
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.
Adrian
CC BY-SA 3.0
2017-06-30T13:31:39.093Z
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.
Tensibai
CC BY-SA 3.0
2017-06-30T14:39:34.643Z
@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.
James Shewey
CC BY-SA 3.0
2017-06-30T14:52:06.517Z
@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.
Tensibai
CC BY-SA 3.0
2017-06-30T07:48:32.417Z
2017-06-30T07:48:32.417Z
Tensibai
<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>

CC BY-SA 3.0
2017-06-30T02:55:05.140Z
My assumption is definitely yes if there are no firewall related issues.
Ta Mu
CC BY-SA 3.0
2017-06-30T04:00:34.150Z
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.
Philippe
<chef><azure><puppet>
Can I run Chef/Puppet server from Azure and manage my on-premise infrastructure?
Philippe
# 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=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**: @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.  

---

