Frameworks are Shipa's policy engine and logical grouping of rules applied to the applications you deploy through them. They are a key component of Shipa.
Frameworks are also responsible for providing the binding connection between Shipa and your clusters.
Creating Frameworks
You can create a framework using your Shipa dashboard through the Frameworks page
When you click on the Create Framework button, a framework creation workflow will guide you through the different options you have to secure your applications.
- General
The first step in the workflow is the General tab, where you will be able to define:
Field | Description |
|---|---|
Name | The name of the framework |
Provisioner | The engine that should be used by Shipa when applications are deployed through this framework. Options are Kubernetes or Shipa nodes. Note: If you are using Shipa cloud, only Kubernetes is currently available as a provisioner |
Ingress | The ingress controller that Shipa should use when deploying applications through this framework. Note: If you select Istio as ingress, Shipa requires you to have Istio installed and configured in the cluster where this framework will be bound before binding this framework to the cluster. |
Kubernetes Namespace | By default, when a framework is bound to a cluster, Shipa will automatically create a new namespace in the destination cluster with the same name as the framework. If you want Shipa to use an existing namespace instead, you can specify the namespace name that should be used by Shipa using this field. |
Make this my default framework | By checking this box, your framework will be set as default. When no framework is specified when you create an application, this framework will be used |
Connect to cluster (Optional) | If you have existing clusters connected to Shipa through other frameworks, you can use this to directly bind the new framework to an existing cluster, avoiding the additional step of editing the cluster to add this new framework to it. |
- Resource Consumption
Resource consumption rules are used to limit the amount of CPU, memory, and swap applications can consume. These limits are automatically applied to applications at deployment time.
Plans are responsible for presenting resource consumption options. Before creating a framework, ensure plans are created and available to the teams assigned to the new framework.
Plan Management
You can find detailed information on managing plans here
- Access Control
The access control section of the workflow allows you to select which teams can deploy applications using the new framework. Multiple teams can be selected.
Field | Description |
|---|---|
Teams | The teams that can deploy their applications through the framework. Multiple teams can be selected and should have been created before creating the framework. |
Make the framework public | If selected, this option will make the framework available to all teams on Shipa to deploy their applications through it. |
- Application Quota
Application quota gives you control over application scalability. By setting the application limit, you control the number of units applications can scale up to.
Field | Description |
|---|---|
App quota | Set a limit to how much applications can scale or leave it as unlimited |
App limit | The number of units/containers an application can scale up to |
- Registry Control
The registry control step of the workflow is used for limiting registries where application images can be pulled from.
Multiple registry URLs can be specified in this step, with one entry per line.
- Network Policy Setup
You can leverage frameworks to enforce detailed network policies to applications deployed through them.
Field | Description |
|---|---|
Enforce Network Policy | If selected, the framework will add two additional steps to the workflow so you can define ingress and egress policies. Note: The network policies defined at the framework level will be automatically applied to every application deployed through this framework. |
Allow app-level policies | When defining network policies at the framework level, every application deployed will automatically receive these policies. If you check this box, the application owner will have the capability of customizing the network policies for his specific application post-deployment. If not, the application owner won't be able to change his application's network policy. |
- Security Scans
Shipa has a built-in scanner, based on Clair, that you can leverage to scan applications, images and list specific vulnerabilities that Shipa should ignore when deploying applications. Scans are run both during and post-deployment.
Field | Description |
|---|---|
Disable app scans | If selected, Shipa will not perform automated application-level security scanning both at deployment and post-deployment time for applications deployed through the framework. |
Disable platform scan | If selected, Shipa will not perform automated image-level security scanning both at deployment and post-deployment time for applications deployed through the framework. |
Components to ignore on scans | If desired, you can specify an individual or a group of components that should be ignored by Shipa when scanning applications deployed through this framework. The components specified here are treated as exceptions by Shipa. |
CVEs to ignore on scans | If desired, you can specify an individual or a group of CVEs that should be ignored by Shipa when scanning applications deployed through this framework. The components specified here are treated as exceptions by Shipa. |
Editing Frameworks
You can edit existing frameworks using your Shipa dashboard through the Frameworks page.
When editing frameworks, Shipa will open the framework creation workflow to give you a structured view of all details assigned to the specific framework you are editing.
By clicking on Update at the end of the workflow, Shipa will update the framework information, and new applications deployed through it will automatically have the new configuration enforced.
Deleting Frameworks
You can remove existing frameworks using your Shipa dashboard through the Frameworks page
The option to delete a framework will be blocked when there are running applications deployed through this framework.
Once the framework has no running applications, you can delete the framework.
Updated 8 days ago