There are a number of tools available to developers working on the OpenShift platform to help ensure the confidentiality, integrity and availability of data within those systems. This is an overview of those tools, with links to specifics on each of the resources.
- OpenShift Platforrm Security
- Critical Systems Standard
- Platform Tools Security Assessments
- Platform Product Registry
- Access Management
- Kubernetes Network Policies
- Pipeline Templates (includes static and dynamic analysis)
- Container image scanning (ACS, Xray)
- Container runtime security
- TLS Certificates
- Secrets Management
- GitOps/Cluster Configuration Management
- API Management
- Application Resource Tuning Advisor and App Assessment Tool
- Logging/Monitoring (EKS, Kibana, Graphana, Sysdig Monitor, SIEM)
- Change Management
- Other considerations
Service definition - Silver/Gold - https://cloud.gov.bc.ca/private-cloud/our-services-in-private-cloud-paas/get-started-with-the-private-cloud-paas/
Our Silver Service is our standard DevOps platform offering, with on-cluster resiliencey based on application design.
Our Gold Service is our enhanced DevOps platform offering, with replication to a secondary cluster for disaster fail-over purposes.
Please take note of the Shared Responsibility Model. While the Platform Services Team manages infrastructure, OpenShift Container Platform and the Platform critical services as part of the Private Cloud PaaS, the Product Team bears the responsibility for the functionality and operations of their application(s) hosted on the Platform.
Specific details on OpenShift specific secuirty controls can be found here:
- these are highlighted as part of the OpenShift STRA.
The platform services team outsources for a penetration test annually to ensure the services we provide are configured to protect confidentiality, integrity and availability. Peneteration tests are procured through the pre-qualified list of vendors (https://www2.gov.bc.ca/gov/content/governments/services-for-government/bc-bid-resources/goods-and-services-catalogue/im-it-security-services).
A Privacy Impact Assessment has been completed for the OpenShift Container Platform service.
Personal Information upto and including Protected B Information Security Classification may be stored on OpenShift.
We are very close to obtaining critical systems standard compliance.
Documentation is in final stages of review for submission.
Many of the platform tools have completed security assessments. These include:
OpenShift v4.x and GitHub (Public)
KeyCloak Realm Registry
KeyCloak Common Host Single Sign-on
OCP Application Resource Tuning Advisor
1Password (SoAR complete, Cloud security schedule review complete) - not to be used corporately due to no background checks for staff/contractors
The following security assessments are underway:
- Platform Product Registry
- GitHub Enterprise (Cloud security schedule review underway)
The following security assessments are planned:
- Cert Manager for OpenShift
- Platform Security Dashboard
For specifics, please contact the platform services team at PlatformServicesTeam@gov.bc.ca.
While access to the registry is currently limited to the OpenShift Platform Services team (full view) and Product Owners/Technical Leads (limited view), we are working on creating roles for Ministry security staff to consume as well. Until then, you can contact PlatformServicesTeam@gov.bc.ca for details.
Community sharing, alerts and discussions take place on Rocket Chat, which we host as an app on OpenShift. Authentication via IDIR or GitHub (in BCGov org or invited by an existing member).
Mautic has been implemented to allow for subscription based communications for the DevOps community.
Access to OpenShift is brokered through our OpenShift SSO Service (currently leveraging KeyCloak).
GitHub has been the primary authentication to date on OpenShift, however we are in the process of introducing IDIR (via Azure AD). Both of these options require an account with 2FA/MFA enabled.
GitHub - All clusters
IDIR - KLAB, Silver (Gold, GoldDR to come in early 2022)
- GitHub 2FA - https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication
- IDIR MFA - https://www2.gov.bc.ca/gov/content/governments/services-for-government/information-management-technology/information-security-mfa
Cluster roles are managed either in private GitHub repositories (in the bcgov-c org) or through direct role bindings within a namespace. We are investigating third party tools to help improve the user management experience.
Platform Services Roles and Responsibilities can be found here:
The Platform Services team maintains an Access Control Policy for all platform tools.
Network policies help the platform and project teams to better control communications between components. While KNPs only apply as INGRESS rules (not egress), they help to improve our overall security posture. KNPs only apply to on-cluster communications (i.e. between pods in a namespace, or between namespaces). For off-cluster communications, hosting is investigating a VMWare tool called NSX-T. NSX-T governs network policies for our Emerald cluster.
Find our more about using KNPs to control network security for an application hosted on the Private Cloud Openshift Platform in the OpenShift network policies document.
More details on KNPs can be found here: https://kubernetes.io/docs/concepts/services-networking/network-policies/
In order to reduce effort in implementing secure tools into a build pipeline, we have developed pipeline templates that include components for build, aas well as static and dynamic vulnerability scanning.
The pipeline templates above make it easier to include the tools described below:
What do each of these types of scanning tools do for me?
Static Anaysis (i.e. SonarX, CodeQL)
- identifies coding issues that could lead to compromise, back doors, secrets, etc
Dynamic Anaysis (i.e. OWASP ZAP)
- testing against a live version of app for injection, Cross-site scripting (XSS), and other common web attacks (https://owasp.org/www-project-top-ten/)
- ensures image components are up-to-date and not vulnerable to known exploits (https://cve.mitre.org/, https://nvd.nist.gov/).
Image scanning/analysis comes in 2 forms - 1 active (RedHat Advanced Cluster Security - ACS), 1 passive (XRay).
This tool allows us to scan image registries and running containers for image vulnerabilities.
It allows us to create policies at build, deploy, and runtime.
It can also help in defining network security policies for your application and visualizing component communications.
Scoped access is granted based on identification as a Product Owner or Technical Lead in the OpenShift Product Registry.
Developer access can be granted by request. Requests must include the following:
- Product Owner approval
An add-on capability to Artifactory, XRay scans images and other artifacts for component vulnerabilities. Anyone with access to an image or artifact within Artifactory can see the XRay tab as part of the image/artifact details, and see what vulnerable components lie within, and what version will correct that deficiency.
We currently have runtime policies in place for the following using ACS. These look for things like:
- Integrity monitoring
Additionally, OpenShift uses CoreOS and the CRI-O container engine.
OpenShift uses a wildcard certificate for the majority of cluster communications security. This should be sufficient for dev and test workloads, but for production workloads, each team is required to obtain a dedicated TLS certificate from the Access & Directory Management Services (ADMS) team.
Note: by default, the wildcard will be used to protect project workloads. The Platform Services team worked through the wildcard issuance requriements for use on the OpenShift clusters. Obtaining a dedicated TLS cert is currently a manual process.
Details on these processes can be found here: https://ssbc-client.gov.bc.ca/services/SSLCert/documents.htm
Pre-requisites: Generate a .csr for each site:
- Business area creates/submits order
- Ministry Service Desk reviews order, creates iStore Number, sends to EA for Approval
- EA Approves
- Order is sent to DXC for fulfillment
- Once order is fulfilled/shipped by DXC, Ministry Service Desk sends 'Completed Order' notification to business area
- Note: This process may be slightly different using MyServiceCentre.
This 'secrets' store should actually only be used for configurations. Values are encoded as base64 and NOT encrypted. However, these 'secrets' can only be accessed with a role to a given namespace with permission to access them. Additionally, the physical etcd volume, where OpenShift secrets are stored, is encrypted.
The preferred secrets management tool for team use on OpenShift.
- Vault secrets management service
- Vault getting started guide
Argo CD provides a GitOps capability for sync'ing a Git repository with an OpenShift configuration (platform or application).
We are in the process of testing out the GitOps Operator, based on ArgoCD, that is integrated into OpenShift. This may replace (partially or completely) our custom ArgoCD implementation.
The Data BC team hosts an API Gateway for use by other government clients. Details can be found here:
Resource Tuning Advisor
App Assessment Tool
The Platform Services team provides a number of tools to help ensure our platform and applications are behaving as expected, while allowing us to investigate anomolies.
This tool provides a more wholistic view of logs for an application or at the platform level, as well as providing visualization and alerting capability.
This tool allows our platform admins and platfrom teams to build monitoring dashboards.
- Onboarding to application monitoring with Sysdig
Security Information and Event Monitoring (SIEM):
All cluster logs (system, audit, container) are regularly sent to the Security Operations SIEM environment.
Retention is set as follows:
- System, Container logs - 2 months
- Audit logs - 13 months
We are currently working on Azure AD integration (via KeyCloak) and user role mapping based on OpenShift namespace access. This activity has paused for the time being but will be re-started in the new year.
This tools help us to observe platform service availability:
Planning for platform and service changes is documented on the Platform Services ZenHub board.
Any service change will be communicated via the #devops-alerts RocketChat channel.
Strategic level changes are communicated to the DevOps community at regular Community Meetups, as well as to executive groups across government.
GitHub is the primary git repository for platform application code. There are some exceptions that use privately hosted GitLab or other source code repositories.
Here is a summary of the GitHub organizations we own and their purposes:
- bcgov - main developer git repository for platform application code and/or public sharing.
- bcgov-c - main private git repository used for cluster configuration management and non-public projects.
- bcdevops - alternate git repository for platform application code. Membership required for access to OpenShift.
- bcgov-platform-services - git repository for platform services team
These resources are available:
Teams may request GitHub apps to be associated with their own or all projects in a GitHub organization. These requests are reviewed by a platform administrator for validity and scope. These are also shared with Ministry security staff to ensure they are acceptable for connection.
We are currently piloting the use of GitHub Enterprise.
Payment Card Industry Compliance (PCI-DSS)
Our OpenShift implementation is NOT PCI-DSS compliant. If you wish to host an application on OpenShift that needs to perform financial transactions, please refer to the following: https://docs.developer.gov.bc.ca/payment-card-processing/. Some teams have decided to host PCI-scoped applications on-prem (non-OpenShift) or on a cloud based service (AWS, Azure, etc) to avoid linkages with government systems not under their control.
The platform services team provides training to onboarding teams, as well as support for issues experienced. Ministry staff that work with devops teams are also encouraged to attend training.
- Various Rocket Chat channels
App security self assessment:
Best practices for building apps on OpenShift:
Contact For all other matters concerning security on the OpenShift Container Platform, please contact PlatformServicesTeam@gov.bc.ca.