Air-gapped environments are those that are physically isolated from other networks, but most importantly isolated from the Internet. No proxies, no jump hosts - nothing. The only way to get data into or out of the environment is via manual data transfer or, if you are extremely lucky, a one-way data diode. Most of the time you’ll be relying on manual data transfers.
An Operator needs to be written with air-gapped environments in mind, but thankfully the key requirements are all fairly straightforward. If you follow the recommendations below you’ll go a long way to creating an Operator that works in air-gapped environments.
That’s great, but why should I care?
Many Kubernetes and OpenShift deployments are in air-gapped environments. These are particularly common in Government, Financial Services, and really any industry where specific data or workloads need to be kept strongly isolated from the public Internet. Without a consideration of these environments you’re artificially limiting the user base that can consume your Operator.
Some Operators will never be suited for an air-gapped environment if they have hard and immovable dependencies on Internet-based resources - but for everyone else, there’s a few small things you can do to maximise the “air-gap friendliness” of your Operator.
How do we make an “air-gap friendly” Operator?
It’s not as complicated as you might think - just think NIRDD:
- Never hardcode a URL.
- Inject trusted certificates.
- Related images.
- Digests, not tags.
- Documentation
Let’s go down the list!
Never hardcode a URL
Hard coding URLs into your Operator when there’s no Internet access is the number one way to prevent your Operator from working in air-gapped environments. Image references to Internet-based registries are probably the primary culprit here.
Don’t hardcode anything. Always allow the users to specify this detail through ConfigMaps, environment variables, Secrets, or - my preference - as additional fields in the spec for your custom resource. As an example, see how the Trident CSI driver allows overriding the source registry, repository and image.
Have defaults defined in the code of your Operator but overrides from external sources. You’re probably 80% of the way to being air-gap friendly if all you do is allow overrides - 90% if you also document them!
Inject trusted certificates
Good practice regardless, but in air-gapped environments this is even more important. You must not rely on external services being signed by a trusted CA within the default trust store in your container. Always give users a means to inject additional trusted certificates. My go-to technique is to let users provide the name of a ConfigMap that you will mount directly into your container in the correct location.
For one such example, have a look at how the Gitea Operator allows users to specify a ConfigMap as an extra field on the CustomResourceDefinition, and injects that ConfigMap into a known location for golang to use.
Related images
Operators generally orchestrate other containers in support of an application. They need to generate Kubernetes resources that refer to container images and so those container images need to exist in the air-gapped environment. If there’s no listed source for exactly which containers your Operator requires, the user will never know to mirror them, and your Operator will fail to deploy with ErrImagePull errors.
Your users start playing “whack-a-mole” as they mirror containers one-by-one until your Operator deploys - or they give up and find another Operator to try. There are two solutions to this problem:
Option A is just to document your image dependencies. This is perfectly OK and is the minimum standard to aim for.
Option B is to do Option A and also use the `relatedImages` field on the ClusterServiceVersion.
relatedImages allows you to explicitly list which extra images your Operator can use, and to explicitly mark those as ‘required’ so that installation will fail if they are not available in the environment. Even better, this will allow images your Operator requires to be captured by the mirroring capabilities of the `oc` tool - and that makes mirroring your Operator much simpler.
For detail on using relatedImages, take a look at the proposal document.
Unsurprisingly, I like to combine Option A and Option B, and I recommend you do too!
Digests, not tags
While it is possible to create transparent registry mirrors using ImageContentSourcePolicy custom resources, ICSPs generate mirror configuration that only allows mirrors to take effect when the image is pulled by digest. The mirror will never be used if you configure that mirror via an ICSP and then try to pull with a tag reference.
You can create your own custom registries.conf configuration using MachineConfig objects and explicitly allow mirror overrides by tag, however this is a step your users will need to complete unless you provide tooling for them.
Where possible, use digests to refer to the images your Operator requires. There’s a couple of advantages here:
Firstly, you know exactly what images a particular version of your Operator is running. This simplifies your troubleshooting and eliminates tagging mistakes as a source of problems - for example, the operator deploys the “v2.1” tag but a tired sysadmin has mistakenly tagged “v2.1” against an image that is actually version 2.0 of the code.
Secondly, you can use existing ImageContentSourcePolicy resources without customisation.
If you’d prefer to use tags there’s a little more work involved - either you need to allow users to override your registry, repository and image (as described above, and my personal preference), or you need to provide documentation for users to create a custom ImageContentSourcePolicy if deploying on OpenShift.
Documentation
Last, but not least, don’t forget some documentation. Describe how to:
- Bundle up your Operator and all associated artifacts for transfer across to the air-gapped environment.
- Identify and pull all required images that your Operator attempts to deploy.
- Install on the air-gapped side.
- Configure the container image, repository and registry (if needed).
- Import/export artifacts and extra content that your Operator may rely on (e.g. OVAL data).
Don’t forget your friendly air-gapped users
Air-gapped environments are common in high security or high sensitivity environments, but don’t let an air-gap prevent your Operator from running.
Just remember to think NIRDD - Never hardcode URLs, Inject certificates, list Related images, and use Digests, not tags, and don’t forget your Documentation.
Looking for a list of Red Hat Operators that work in Disconnected/Air-Gapped environments? Have a look at this knowledge base article.
Sull'autore
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit