Manager | Partner
Overview
Policy Profile uses OPA (Open Policy Agent) to centralize operations, security, and compliance.
When accessing the page, you can see an overview of all created profiles with selected rules and associated Projects.
Policy Profiles allow administrators to define specific configurations and security policies that are automatically enforced across their cloud infrastructure. When you set up Policy Profiles, these policies are immediately applied to all relevant resources without requiring manual intervention.
For instance, if your policy profile includes a rule to block certain actions, such as enabling NodePort services on instances, this rule will be enforced automatically. As a result, any attempt to enable NodePort will be automatically blocked by the policy, and this action will be logged in the system events for auditing and compliance purposes. This ensures that your cloud environment adheres to the defined security and operational standards consistently.
Below is an overview of the types of actions that can be blocked by Policy Profiles:
- Unauthorized Network Access: restricts access from specific IP addresses or ranges, protecting resources from potential malicious attacks and unauthorized access attempts.
- Resource Quota Exceeding: prevents the creation of resources that exceed predefined quotas, such as limits on virtual machines, storage, or memory, helping manage resource allocation efficiently and prevents overconsumption that could lead to additional costs.
- Unapproved Software Installations: blocks the installation of software packages that are not pre-approved. Ensures that only vetted software is used, maintaining security and compliance.
- Configuration Changes: prevents unauthorized modifications to system configurations and maintains system stability and prevents inadvertent or malicious changes that could impact operations.
- Access to Sensitive Data: restricts access to databases or storage buckets containing sensitive information, protecting sensitive data from unauthorized access and potential breaches.
- Port and Protocol Restrictions: blocks the use of specific network ports or protocols, enhancing network security by eliminating the use of insecure or unnecessary ports and protocols.
- Security Group Modifications: prevents unauthorized changes to security groups, ensuring that security group rules remain consistent and secure, controlling the flow of traffic appropriately.
- Public IP Attachments: blocks the attachment of public IP addresses to instances without proper authorization and reduces the risk of exposing instances to the public internet, enhancing overall security.
- Service Account Restriction: limits the permissions and capabilities of service accounts, preventing misuse of service accounts and limits the potential damage from compromised accounts.
- Auto-scaling Constraints: enforces rules on auto-scaling groups to prevent excessive scaling, controling costs and maintains system stability by preventing over-scaling.
Add Policy Profile
When adding a new Policy Profile, specify the following parameters:
- Name – choose a name for the profile
- Features
- Forbid NodePort– by choosing to forbid NodePort, you’re making sure that this method isn’t used to expose Services. This can be helpful for keeping things secure or ensuring specific networking rules are followed in your Kubernetes setup
- Forbid HTTP ingresses– activating this feature will require all Ingress resources to be HTTPS only, this means that any incoming traffic must be secured using the HTTPS protocol, and HTTP traffic will not be allowed. This requirement can enhance security by ensuring that communications between clients and the services exposed by Ingress are encrypted
- Require Probe– readiness probes ensure that a pod is ready to serve traffic, allowing Kubernetes services to route requests to it only when it’s ready to handle them. Liveness probes, on the other hand, check if a pod is still running as expected and, if not, can restart it automatically. So, by enforcing this policy, it ensures that pods have these crucial probes set up, promoting better reliability and resilience within your Kubernetes environment
- Unique Ingress- an Ingress resource defines how external traffic is routed to services within the cluster. Each rule within an Ingress specifies a host, and multiple rules can be defined within a single Ingress. By enforcing the Unique Ingress policy, it ensures that no two rules within the same Ingress resource can have the same host specified. This helps prevent conflicts and ensures clear and unambiguous routing of external traffic to the appropriate services within your Kubernetes cluster.
- Force Pod Resource- mandates all Kubernetes Pods to explicitly specify resource limits and requests for CPU and memory. Administrators or policies within the Kubernetes environment require that all Pods adhere to this best practice of explicitly defining resource requirements and limits. This helps ensure predictable performance and resource allocation across the cluster, preventing individual Pods from monopolizing resources or causing performance degradation for other workloads.
- Add
- Allowed Repositories– if a policy profile specifies a list of approved repositories, only container images from these repositories (or subdomains of these repositories) would be permitted. Images from other repositories would be rejected
- Forbid Specific Tags– when a policy profile forbids specific tags, it ensures that container images with any of the listed tags are not allowed to be deployed within the Kubernetes cluster. This restriction can be useful for enforcing best practices related to security, stability, or compliance.
- Ingress Whitelist– only specific Ingress resources listed in the whitelist are allowed to be configured and utilized within the cluster. Any Ingress resources that are not explicitly listed in the whitelist will be restricted or denied.
Add Profile to a Project
You can add the Profile during Project creation by checking “Add Policy Profile” from the drop-down selection.
Enforce Policies after the Project is created. You can disable it the same way.
Note
Please keep in mind that namespaces Monitoring, Velero, and Kube-system violate these policies