Enterprise: Difference between revisions

From NixOS Wiki
← Older edit
VisualWikitext
imported>Makefu
m clarify what intercepting proxy means
m fetchFromGithub -> fetchFromGitHub
 
(7 intermediate revisions by 3 users not shown)
Line 3: Line 3:
== Private resources ==
== Private resources ==


Building internal projects will require fetching of internal (private) source code and other resources. These resources usually are protected some form of credentials.
Building internal projects will require fetching of internal (private) source code and other resources. These resources usually are protected by some form of credentials.


=== fetchurl ===
=== fetchurl ===


<code>fetchurl</code> is used to retrieve HTTP resources, but is also used by <code>fetchFromGithub</code>. For private resources this will usually result in an error like the following:
<code>fetchurl</code> is used to retrieve HTTP resources, but is also used by <code>fetchFromGitHub</code>. For private resources this will usually result in an error like the following:


  curl: (22) The requested URL returned error: 401 Unauthorized
  curl: (22) The requested URL returned error: 401 Unauthorized


Nix will not know about your credentials in your home directory, as the builders have no access to those files. However, Nix has a few options borrowed from curl that will help in this situation. A netrc file can be used that holds the credentials for all domains that require authorisation. More information on netrc can be found in the [https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html GNU manual].
Nix will not know about your credentials in your home directory, as the builders have no access to those files. However, Nix has a few options borrowed from <code>curl</code> that will help in this situation. A netrc file can be used that holds the credentials for all domains that require authorisation. More information on netrc can be found in the [https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html GNU manual].
For our example, we will create the file in <code>/etc/nix/netrc</code>. The contents will look similar to the following:
For our example, we will create the file in <code>/etc/nix/netrc</code>. The contents will look similar to the following:


Line 20: Line 20:
Next the netrc file needs to be accessible in the builds. We will configure Nix to allow access to this file directly from the build sandboxes. Edit your <code>/etc/nix/nix.conf</code> file so that it includes the following lines:
Next the netrc file needs to be accessible in the builds. We will configure Nix to allow access to this file directly from the build sandboxes. Edit your <code>/etc/nix/nix.conf</code> file so that it includes the following lines:


  build-sandbox-paths = /etc/nix/netrc
  netrc-file = /etc/nix/netrc


Lastly, the builds need to know that they need to use the netrc file in <code>fetchurl</code>. We will override the definition of <code>fetchurl</code> to include <code>--netrc-file /etc/nix/netrc</code> in the curl options used by <code>fetchurl</code>. The following shows how this might look in your Nix file:
Lastly, the default way of fetching urls is using <code>curl</code> inside a build sandbox. This is a powerful command, but it will not use (and cannot use) a netrc file that is outside of the build sandbox. <code>netrc-file</code> is thus only applicable to fetches being done by Nix itself. In addition, we do not want to place the netrc file inside the sandbox, because that could potentially leak private credentials into builds. <code>fetchurlBoot</code> uses this builtin function and makes sure the call-sign is mostly compatible with the regular <code>fetchurl</code>. This function is used most often to bootstrap some of the more basic packages like <code>curl</code> itself, but it can also be very useful for fetching files outside of the sandbox.
 
Since '''fetchurlBoot''' is mostly compatible with '''fetchurl''' we can override '''fetchurl''' where needed:
<syntaxHighlight lang=nix>
<syntaxHighlight lang=nix>
let pkgs = import <nixpkgs> {
mypackage = callPackage <mypackage.nix> {
  config = {
  fetchurl = stdenv.fetchurlBoot;
    packageOverrides = pkgs: rec {
};
      fetchurlPrivate = opts: pkgs.fetchurl (opts // {
        curlOpts = "${pkgs.lib.optionalString (opts ? curlOpts) "${opts.curlOpts}"} --netrc-file /etc/nix/netrc";
      });
      fetchurl = fetchurlPrivate;
  };
}
in
  ...
</syntaxHighlight>
</syntaxHighlight>


Now all '''fetchurl''' calls will use the specified netrc file with the credentials of your choice.
Now the package is built exactly the same way as before, but resources will be fetched using '''fetchurlBoot'''. '''fetchurlBoot''' will in turn download the resources within Nix itself, which will use the netrc-file and use the right credentials for the domain names that you have defined.


== TLS Intercepting Proxy ==
== TLS Intercepting Proxy ==
 
TLS-Intercepting proxies will intercept each and every TLS connection and replace the original certificate with it's own to be able to introspect the traffic. This of course creates validation issues with the "official" ca-certificate project.
As of right now there currently does not seem to be a way to install nix packages via an intercepting proxy which replaces the ''original'' TLS certificate with the certificate created by the intercepting proxy, see [https://github.com/NixOS/nix/issues/1896 nix issue #1896].
Since [https://github.com/NixOS/nix/issues/1896 nix pr #2181] you are able to set your intercepting Proxy certificate via <code>NIX_SSL_CERT_FILE</code> to a file on your system which contains the root and intermediate certificates of your proxy.
See also [https://nixos.org/nix/manual/#sec-nix-ssl-cert-file the appropriate section in the nix manual]


The proxy itself can be set via the environment variables <code>HTTP_PROXY</code> and <code>HTTPS_PROXY</code>.
The proxy itself can be set via the environment variables <code>HTTP_PROXY</code> and <code>HTTPS_PROXY</code>.

Latest revision as of 18:20, 30 August 2024

When trying to use Nix and NixOS in corporations there are a number of issues one will run into. This page tries to provide a solution to each of these issues.

Private resources

Building internal projects will require fetching of internal (private) source code and other resources. These resources usually are protected by some form of credentials.

fetchurl

fetchurl is used to retrieve HTTP resources, but is also used by fetchFromGitHub. For private resources this will usually result in an error like the following: 

curl: (22) The requested URL returned error: 401 Unauthorized

Nix will not know about your credentials in your home directory, as the builders have no access to those files. However, Nix has a few options borrowed from curl that will help in this situation. A netrc file can be used that holds the credentials for all domains that require authorisation. More information on netrc can be found in the GNU manual. For our example, we will create the file in /etc/nix/netrc. The contents will look similar to the following: 

machine DOMAINNAME
    login USERNAME
    password SECRET

Next the netrc file needs to be accessible in the builds. We will configure Nix to allow access to this file directly from the build sandboxes. Edit your /etc/nix/nix.conf file so that it includes the following lines: 

netrc-file = /etc/nix/netrc

Lastly, the default way of fetching urls is using curl inside a build sandbox. This is a powerful command, but it will not use (and cannot use) a netrc file that is outside of the build sandbox. netrc-file is thus only applicable to fetches being done by Nix itself. In addition, we do not want to place the netrc file inside the sandbox, because that could potentially leak private credentials into builds. fetchurlBoot uses this builtin function and makes sure the call-sign is mostly compatible with the regular fetchurl. This function is used most often to bootstrap some of the more basic packages like curl itself, but it can also be very useful for fetching files outside of the sandbox.

Since fetchurlBoot is mostly compatible with fetchurl we can override fetchurl where needed: 

mypackage = callPackage <mypackage.nix> {
  fetchurl = stdenv.fetchurlBoot;
};

Now the package is built exactly the same way as before, but resources will be fetched using fetchurlBoot. fetchurlBoot will in turn download the resources within Nix itself, which will use the netrc-file and use the right credentials for the domain names that you have defined.

TLS Intercepting Proxy

TLS-Intercepting proxies will intercept each and every TLS connection and replace the original certificate with it's own to be able to introspect the traffic. This of course creates validation issues with the "official" ca-certificate project. Since nix pr #2181 you are able to set your intercepting Proxy certificate via NIX_SSL_CERT_FILE to a file on your system which contains the root and intermediate certificates of your proxy. See also the appropriate section in the nix manual

The proxy itself can be set via the environment variables HTTP_PROXY and HTTPS_PROXY.

Retrieved from "https://wiki.nixos.org/w/index.php?title=Enterprise&oldid=17020"