The combination of External Network and Network Security Policy resources can be used to control access from a given pod/namespace out to external network resources. Following are some examples. The BC Government's OCP environment also does a much better job at DNS resolution, allowing host names to be defined via DNS names rather than IP addresses in many cases.
Allow a backup-container to post notifications to rocket.chat:
kind: NetworkSecurityPolicy
name: backup
namespace: 09e0c5-dev
spec:
description: |
Allow the backup-container to access the application's database for backup purposes, as well as access to rocket.chat to log notifications.
destination:
role=db
app=fla
env=dev
$namespace=09e0c5-dev
ext:name=backup
source:
role=backup
app=Backup
env=dev
$namespace=09e0c5-dev
Allow a pod to access KeyCloak and other Organization specific resources:
kind: ExternalNetwork
name: web
namespace: 9b71af-dev
spec:
description: |
Define the network parameters for accessing remote resources.
entries:
- wsgw.dev.some.org.ca
- dev.oidc.gov.bc.ca
- logontest.gov.bc.ca
servicePorts:
- tcp/443
kind: NetworkSecurityPolicy
name: web
namespace: 9b71af-dev
spec:
description: |
Allow the application to access a defined set of external resources.
destination:
- - ext:name=web
source:
- - role=web
- app=a2a
- env=dev
- $namespace=9b71af-dev
The template snippets for the above configurations:
Managing creation/update of Network Security Policy and External Network resources:
Network Security Policy and External Network resources are defined statically, meaning you can not use something like,
valueFrom:
secretKeyRef:
....
to dynamically reference a secret.
In order to better facilitate the management of the parameters for such resources, the BCDevOps/openshift-developer-tools have been updated to allow hostname parameters to be parsed from user provided endpoints, be stored in secrets, and then read back from secrets during updates. Allowing the static resources to be updated, while the settings are retained.
The combination of External Network and Network Security Policy resources can be used to control access from a given pod/namespace out to external network resources. Following are some examples. The BC Government's OCP environment also does a much better job at DNS resolution, allowing host names to be defined via DNS names rather than IP addresses in many cases.
Allow a backup-container to post notifications to rocket.chat:
kind: NetworkSecurityPolicy name: backup namespace: 09e0c5-dev spec: description: | Allow the backup-container to access the application's database for backup purposes, as well as access to rocket.chat to log notifications. destination:
Allow a pod to access KeyCloak and other Organization specific resources:
The template snippets for the above configurations:
Other Examples
Access to an external oracle database:
The IP in this example was randomly generated for demo purposes
Access to an Indy Blockchain Ledger:
Managing creation/update of Network Security Policy and External Network resources:
Network Security Policy and External Network resources are defined statically, meaning you can not use something like,
to dynamically reference a secret.
In order to better facilitate the management of the parameters for such resources, the BCDevOps/openshift-developer-tools have been updated to allow hostname parameters to be parsed from user provided endpoints, be stored in secrets, and then read back from secrets during updates. Allowing the static resources to be updated, while the settings are retained.
Examples of this can be found here:
The resulting create and update flows then look like this:
Create:
Update: