Framework Management
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 Policy Frameworks
You can create a framework using your Shipa dashboard through the Frameworks page. To access it, go to "Environments" and choose the tab "Frameworks" in the top right corner.
When you click on the Create button, a framework creation workflow will guide you through the different options you have to secure your applications.
The first step is to select the overall purpose that your framework will have, so Shipa can help you narrow down the options to fill out and make the process easier.
Options
| Purpose | Meaning |
|---|---|
| Deploy applications with reasonable defaults | Creates the simplest version of a framework by providing minimal information. A framework created with this option will have virtually no policies other than access control based on the teams selected and limited resources based on the plan chosen. This can be a valid option for testing purposes or if your team has no need for further control. |
| Discover existing applications | Creates a framework that when tied to a namespace facilitates the discovery of existing applications running in your cluster |
| Define detailed policies for advanced deployments | Creates a framework by specifying explicitly the values of each one of the supported policies by Shipa |
For the sake of this documentation, select the third option "Define detailed policies for advanced deployments" so each option can be thoroughly described.
The following steps will be shown accordingly:
- 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 |
| 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 |
- 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. |
- Auto Scale
Auto scale gives you control over application scalability by using Kubernetes' Horizontal Pod Autoscaler (commonly known as HPA). To set it up for all the apps using the suggested framework, simply check the option "enable application auto-scale" and provide the required replicas and the CPU percentage that should be used as a threshold to trigger the autoscaling process
| Field | Description |
|---|---|
| Enable application auto-scale | Option to enable the setup of the auto-scale policy in the framework |
| Allow app-level policies | Option to determine if applications can override the framework auto-scaling rules during their deployment |
| Min replicas | The minimum amount of replicas that applications' pods should have |
| Max replicas | The maximum amount of replicas that applications' pods can reach when performing auto scales |
| CPU percentage | The CPU percentage threshold that pods should reach to trigger the auto scale |
- 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.
- Application Control
Node selector rules and Allowed CNAMEs that your applications using this framework should hold
| Field | Description |
|---|---|
| Node labels | list of labels and values that an application should hold to be deployed in a specific node of the cluster |
| Enable strict mode | Boolean flag that determines if only one of the node selectors should be present or if all of them should exist. Non-compliance of this rule by any app will report a policy violation |
| Allowed CNAMEs | A list of CNAMEs that your application can have. Any CNAME added outside of this list will report a policy violation |
- 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 Policy 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 Policy 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 4 months ago