Vigil, the identity-aware proxy (IaP) implementing the Service and intercepting the requests from the Users to the protected upstream resource, is capable of operating at several widely used application-layer (L7) protocols. This application-layer awareness provides "secret-less" access for your Users to the protected upstream, by injecting application-layer credentials on-the-fly at the Service and authenticating to the protected upstream without sharing them with your Users. Such application-layer credentials could be API keys and access tokens for HTTP-based resources, SSH passwords and private keys, PostgreSQL and MySQL passwords, or mTLS for many other application-layer protocols.

Providing secret-less access solves a whole class of vulnerabilities and security-related issues that come with having to manage, distribute, share, and securely store such application-layer credentials especially at scale:

• Such credentials usually have too many privileges, or, sometimes, no limitations whatsoever in terms of permissions. For example, a SaaS API access token that grants full access or full write access to the entire API.
• Such credentials can be too long-lived. For example, an API key that does not have an expiry date; an SSH password or private key that naturally lacks an expiry date; or a TLS certificate used for mTLS authentication that expires within months or years from its creation date.
• Such credentials need to be managed, distributed and stored securely by the users who use them. This by itself increases the attack surface of the entire system and is one of the leading causes of countless serious breaches worldwide every year. This problem can be mitigated by delegating the management and sharing of credentials to secret managers and vaults. However, even if mitigated to an extent depending on the capabilities of the secret manager, the problem still persists and is merely delegated to another layer that suffers from the same fundamental issues.

Octelium's solution is to simply eliminate distributing such credentials to Users, and instead manage them from within the Cluster via Secrets (read more here), and transparently inject them on-the-fly for authorized Users' requests. Octelium supports secret-less access for the following modes:

• HTTP, GRPC and WEB modes where you can provide secret-less access without having to share and manage API keys and tokens, OAuth2 client credentials, AWS sigv4 auth, etc... (Read more here).
• SSH mode where you can provide secret-less access without having to share and manage passwords, private keys or manage a PKI (Read more here).
• POSTGRES mode where you can provide secret-less access without having to share and manage passwords (Read more here).
• MYSQL mode where you can provide secret-less access without having to share and manage passwords (Read more here).
• KUBERNETES mode where you can provide secret-less to Kubernetes cluster APIs without having to share or manage Kubeconfigs, bearer access tokens, or TLS client certificate private keys (Read more here).

Mutual TLS

In addition to the L7 specific credentials (e.g. HTTP API keys or PostgreSQL passwords), many application protocols are protected by mTLS. Octelium also provides secret-less access to mTLS-protected resources by using a client certificate to authenticate to the mTLS protected upstream server.

Here is an example. First, you need to create a Secret that contains your certificate information (i.e. the PEM representations of both the certificate chain and private key) as follows:

octeliumctl create secret client-crt-nats --cert /PATH/TO/CERTIFICATE_CHAIN.PEM --cert-key /PATH/TO/CERTIFICATE_PRIVATE_KEY.PEM

After creating the Secret, you can now reference the Secret by its name for mTLS authentication to the upstream as follows:

1
kind: Service
2
metadata:
3
  name: nats
4
spec:
5
  mode: TCP
6
  config:
7
    upstream:
8
      url: tls://my-nats.default.svc:9090
9
    tls:
10
      clientCertificate:
11
        fromSecret: client-crt-nats

In many cases, you might also want to explicitly set one or more trusted root certificate authorities (CAs). You can add a list of root CAs as follows:

1
kind: Service
2
metadata:
3
  name: nats
4
spec:
5
  mode: TCP
6
  config:
7
    upstream:
8
      url: tls://my-nats.default.svc:9090
9
    tls:
10
      trustedCAs:
11
      - |
12
        -----BEGIN CERTIFICATE-----
13
        CA_1
14
        -----END CERTIFICATE-----
15
      - |
16
        -----BEGIN CERTIFICATE-----
17
        CA_2
18
        -----END CERTIFICATE-----
19
      clientCertificate:
20
        fromSecret: client-crt-nats

By default, the list of trusted CAs override the default list of public trusted CAs used by the Service underlying container filesystem. You can, however, override that default behavior and append your trusted CAs to the system's via the appendToSystemPool field as follows:

1
kind: Service
2
metadata:
3
  name: nats
4
spec:
5
  mode: TCP
6
  config:
7
    upstream:
8
      url: tls://my-nats.default.svc:9090
9
    tls:
10
      trustedCAs:
11
      - |
12
        -----BEGIN CERTIFICATE-----
13
        CA_1
14
        -----END CERTIFICATE-----
15
      - |
16
        -----BEGIN CERTIFICATE-----
17
        CA_2
18
        -----END CERTIFICATE-----
19
      appendToSystemPool: true
20
      clientCertificate:
21
        fromSecret: client-crt-nats

You can also disable verifying the certificate provided by the upstream's server altogether via the insecureSkipVerify field as follows:

1
kind: Service
2
metadata:
3
  name: nats
4
spec:
5
  mode: TCP
6
  config:
7
    upstream:
8
      url: tls://my-nats.default.svc:9090
9
    tls:
10
      insecureSkipVerify: true
11
      clientCertificate:
12
        fromSecret: client-crt-nats