Beta feature

The Configuration Profiles feature is in beta state for release 1.12. Please contact Tetrate if you have any questions or concerns.

Configuration Profiles

The Configuration Profiles feature adds an enhanced configuration experience for larger-scale TSB deployments. Configuration Profiles provide a flexible, template-based approach to managing traffic and security settings in TSB. They address limitations of the traditional hierarchical model by decoupling configuration definition from application. This allows for reusable configuration templates that can be attached at various levels. At the core, Configuration Profiles allow for the creation of configuration objects that can be created at the Organization, Tenant, or Workspace level and be attached to multiple resources like Tenants, Workspaces, or Groups in a distinct hierarchical order.

Introduction

Configuration Profiles are designed to help solving potential issues overlaying the organizational needs and requirements on TBS’s management plane resources. Since there can be a difference between where a Configuration Profile is created and where it is attached,it allows for usage delegation patterns as well as removing the need for duplication of configuration settings amongst the resources needing it.

Challenges for organizations

The standard TSB operating model uses a hierarchy of Organization, Tenant, Workspace, and Groups for configuration and resource isolation. It provides a single dimensional isolation of configuration and physical infrastructure. This hierarchy can be seen as a simple tree structure with Organization at the root which allows for highly granular targeted configuration all the way to individual namespace per cluster. While effective for application teams, the standard operating model can pose several challenges when scaling TSB in large operating environments:

• Repetitive configuration: Defining the same configuration for multiple workspaces, or redundant configuration definitions for subsets of workspaces, is tedious.
• Cross-cutting policies: Policies mandated by compliance (organization-wide polices) may not align with the existing workspace structure or fit the existing isolation areas.
• Policy management complexity: Defining, applying, enforcing, and visualizing policies at different levels is difficult.
• Suboptimal deployments: Trying to fit cross-cutting concepts (environments, security zones) into the hierarchy can lead to complications.

How can Configuration Profiles help?

The Configuration Profiles feature addresses these potential issues. In essence, Configuration Profiles aim to simplify and enhance configuration management in TSB by providing reusable templates and clear rules for applying those templates across different levels of the hierarchy. Configuration Profiles are designed to augment, not replace, the existing TSB operating and configuration model. Its functionalities include defining policies, previewing their impact, providing compliance evidence, delegating policy definition, and improving policy analytics.

Target Audience

The overall goal is to provide more flexibility and address the needs of TSB platform operators in managing complex policies.

Common use cases

Organization-wide policies
A common use case for Configuration Profiles is to define a set of security policies that apply to all workspaces within an organization. For example, an organization may have a requirement to enforce specific security settings, such mutual TLS (mTLS), across all workspaces. By creating a Configuration Profile with these settings, the organization can ensure that all workspaces adhere to the same security standards without having to configure each workspace individually.

Centralized management: Another use case is to centralize the management of traffic and security settings for multiple workspaces. For instance, an organization may have multiple workspaces that require similar traffic management settings, such as circuit breaking or rate limiting. By creating a Configuration Profile with these settings, the organization can apply them to all relevant workspaces, ensuring consistency and reducing the risk of misconfiguration.

Delegated management
Configuration Profiles also enable delegated management of configurations. For example, a tenant administrator may want to delegate the management of specific traffic settings to a workspace administrator. By creating a Configuration Profile with these settings and attaching it to the appropriate workspace, the tenant administrator can allow the workspace administrator to manage the settings without granting them full access to the entire tenant configuration.

Environment-specific configurations
Configuration Profiles can also be used to define environment-specific configurations. For example, an organization may have separate environments for development, staging, and production. By creating separate Configuration Profiles for each environment, the organization can ensure that the appropriate settings are applied to each environment without having to manage them individually.

Compliance and auditing
Configuration Profiles can help organizations meet compliance and auditing requirements by providing a clear and consistent way to define and enforce policies. For example, an organization may have specific security requirements that must be met for regulatory compliance. By creating a Configuration Profile with these requirements, the organization can ensure that all workspaces adhere to the same standards and can easily demonstrate compliance during audits.

Testing and validation
Configuration Profiles can also be used to test and validate configurations before applying them to production environments. For example, an organization may want to test a new traffic management setting in a staging environment before applying it to production. By creating a Configuration Profile with the new setting and applying it to the staging environment, the organization can validate its behavior and ensure that it meets the desired requirements before deploying it to production.

Simplified onboarding
Configuration Profiles can simplify the onboarding process for new tenants or workspaces. For example, when a new tenant is created, the organization can apply a pre-defined Configuration Profile that includes the necessary traffic and security settings. This ensures that the new tenant is configured consistently with existing tenants and reduces the time and effort required for onboarding.

Versioning and rollback
Configuration Profiles can also provide versioning and rollback capabilities for configurations. For example, if a new configuration is applied and causes issues in production, the organization can easily revert to a previous version of the Configuration Profile to restore the previous settings.

Benefits of Configuration Profiles

Configuration Profiles offer several benefits to TSB operators, including:

• Simplified Configuration Management: Profiles provide a flexible, template-based approach to managing traffic and security settings, reducing the complexity of configuration management.
• Centralized Configuration Management: Operators can define and manage configurations centrally, reducing boilerplate and ensuring consistency across environments.
• Flexibility and Reusability: Profiles can be defined once and applied to multiple Tenants, Workspaces, or Groups, simplifying complex deployments.
• Enforcement of Security Policies: Mandates allow operators to enforce security requirements across the platform, ensuring compliance with organizational policies and industry regulations.
• Gradual Migration: Existing configurations can coexist with profiles, enabling a gradual migration strategy without disrupting existing services.
• Simplified Onboarding: New tenants can be quickly onboarded with pre-defined profiles tailored to their specific needs. Reduced Operational Overhead: Automation and self-service capabilities can be built around profiles, reducing the manual effort required to manage configurations.

Core Concepts and Terminology

The following concepts are key elements of Configuration Profiles, and references throughout this document:

• Profiles: Pre-set configuration templates containing traffic and security settings.
• Defaults vs. Mandates: Profiles distinguish between default configurations (overwritable) and mandatory configurations (non-relaxable).
• Attachment: Profiles can be attached at different levels in the hierarchy, allowing for granular control.
• Precedence: Existing TSB noun resources (old style configuration) take precedence over profiles by default to ensure backward compatibility.

Key Considerations

Configuration Profiles are designed to address specific use cases and scenarios within the TSB platform. Operators should carefully consider the implications of using Configuration Profiles in their environment and ensure that they align with their organizational goals and requirements. The following are some key points to consider:

• Configuration Management: Profiles are designed to manage traffic and security settings within TSB. They do not cover all aspects of configuration management, such as network reachability or authorization settings.
• Hierarchical Configuration: Profiles follow a hierarchical configuration model, allowing for inheritance and customization at different levels. This model may not be suitable for all use cases, such as flat or non-hierarchical configurations.
• Granularity: Profiles provide a high level of granularity in configuration management, allowing for fine-tuned control over traffic and security settings. This level of granularity may not be necessary for all deployments and can add complexity to the configuration management process.
• Migration: Profiles can coexist with existing configurations, allowing for a gradual migration strategy. Migrating existing configurations to profiles may require careful planning and testing to ensure a smooth transition.
• Security Policies: Profiles can enforce security policies through mandates, ensuring compliance with organizational policies and industry regulations. Profiles primarily deal with traffic-related and security settings (excluding ACLs). This includes settings such as circuit breaking, timeouts, retries, CORS, TLS, and rate limiting. Profiles do not cover all aspects of security policy management, such as authorization settings.
• Operational Overhead: Profiles can reduce operational overhead by providing a centralized configuration management solution. Managing profiles and ensuring consistency across environments may require additional effort and resources.
• Automation: Profiles can be automated using tools such as Terraform or Ansible to reduce manual effort and ensure consistency. Automation requires careful planning and testing to ensure that profiles are applied correctly and do not introduce unintended consequences.
• Documentation: Profiles should be well-documented to ensure that operators and developers understand how to use them effectively. Clear documentation can help prevent misconfigurations and ensure that profiles are applied correctly.
• Testing: Profiles should be thoroughly tested in staging environments before being applied to production. Testing can help identify and resolve issues before they impact production traffic and ensure that profiles are applied correctly.
• User Education: Operators and developers should be educated on how to use profiles effectively and understand the implications of different configuration settings. User education can help prevent misconfigurations and ensure that profiles are applied correctly.
• Cross-Cutting Security Policies: Security policies dealing with cross-cutting relationships are handled by attribute-based security policies logic. This includes policies that apply to multiple resources based on attributes.
• Istio Direct Settings: Configuration Profiles do not include Istio direct settings. These settings are managed directly within Istio.

Definition Levels and Hierarchy

Profiles can be created at different levels: Organization, Tenant, and Workspace levels. This allows for customization at different levels of granularity. A profile that is created at a higher level can be used at a lower level. The standard TSB hierarchy is honored: Organization -> Tenant -> Workspace -> Group.

Summary

• Profiles can be created at Organization, Tenant and Workspace level
• Profiles can be attached at Organization, Tenant, Workspace and Group level.
• The order of attachment matters!
• Profiles are processed top-down and left-to-right for peers, which allows for layering of configurations.

Organization

The Organization Setting object allows configuring global settings for the Organization. Settings such as network reachability or regional fail-over that apply globally to the organization are configured in the Organization Setting object. Organization Setting is a global object that uniquely configures the organization, and there can be only one Organization Setting object defined for each organization.

It also offers a way to provide default Traffic and Security settings for all of TSB, which can be overridden at the Tenant, Workspace, or Group level; if the Propagation Strategy permits.

Tenant

The Tenant Setting object allows configuring default traffic and security settings for a specific Tenant and will be applicable to all underlying Workspaces.

Workspace

The Workspace Setting object allows configuring default traffic and security settings for a specific Workspace and will be applicable to all underlying Groups.

Group

Four different Group types are available in TSB. Each group provide task specific configurations and policies, and each of them have their own settings objects:

• Security
• Traffic
• Gateway
• Istio Internal

info

Click here to learn more about TSB config groups.

Note
The Istio Internal group is a special group that is available for customers needing direct access to specific Istio resources. It groups highly coupled and implementation-detailed oriented Istio resources together, that don't provide any TSB guarantees or backward forward compatibilities that other groups like traffic, security of gateway can provide.
Therefore, this group is only meant to be used for users/administrators that are confident with those advanced features, knowing that the defined resources under this group will not interfere with the TSB provided mesh governance functionalities.

Example scenario

The example below shows how a Tenant setting object Profile X is created at tenant research, and attached at workspace research-frontend-ws to govern the default settings for that partical Workspaces.

info

Click here to learn how to view configuration profiles.

Subset Application

Configuration Profiles are designed to encompass all possible configuration properties. However, the applicability of these properties depends on the attachment point of the profile. While Configuration Profiles offer a comprehensive set of configuration properties, their application is resource-specific. For instance, when a profile is attached to a specific resource, such as a Workspace or a Group, only the properties supported by that resource will be applied.

Any unsupported properties will be ignored during the configuration process. Currently, this behavior is particularly relevant for Group-level resources, which include traffic, security, and gateway groups. These groups support only a subset of the configuration properties defined in a profile. As a result, only the applicable properties are utilized, while the rest are disregarded. This ensures that only relevant configuration settings are applied to each resource, preventing conflicts or inconsistencies.

Note: Configuration Profiles do not include Istio direct settings. These settings are explicitly excluded from the scope of Configuration Profiles and must be managed directly within Istio. This separation ensures that Configuration Profiles focus solely on their intended purpose without overlapping with Istio-specific configurations.

Multiple Attachments and Order of Precedence

A resource can have multiple profiles attached, and order of attachment and the sequence in which these profiles are attached play a crucial role in determining the final configuration. Profiles are evaluated in a top-down manner, starting from higher levels in the hierarchy, such as Organization, and moving down to lower levels, such as Tenant, Workspace, and Group. For profiles attached at the same level, the order of attachment is processed from left to right. This ensures that configurations can be layered effectively, with later profiles potentially overriding or augmenting earlier ones.

Defaults vs. Mandates

A key trait of Configuration Profiles is the distinction between default settings and mandated settings. When applying configuration settings, it is important to distinguish different configuration types. Configuration Profiles support two primary types of settings: defaults and mandates. These settings serve distinct purposes and provide a flexible mechanism for managing configuration properties across the platform.

In short:

• When a setting is created as a default, it means it can be overridden by a configuration profile attached lower in the hierarchy.
• When a setting is created as a mandate, it means it cannot be overridden.
• Where the hierarchical configuration objects Organization Setting, Tenant Setting, and Workspace Setting only allow for mandates in security settings using the PropagationStrategy property, configuration profiles allow for mandates in all settings types.

Defaults

Serve as initial configuration values that are applied when no other configurations are specified.
Defaults can be overridden by configurations defined at lower levels in the hierarchy.
They provide a baseline for configuration settings, ensuring consistency across resources.
Operators can use defaults to simplify configuration management while allowing flexibility.
Defaults are particularly useful for defining common settings that apply to most resources.

Mandates

Mandates are strict configuration requirements that must be adhered to and cannot be relaxed.
They ensure compliance with organizational policies and regulatory standards.
A mandate can only be overridden by a stricter configuration, providing a robust mechanism for enforcing critical settings.
Operators can use mandates to define non-negotiable policies that apply across the platform.
Mandates are particularly useful for enforcing security and compliance requirements at all levels of the hierarchy.

Unset vs. Zero Value

Configuration properties within profiles must differentiate between an unset value and a zero value.
An unset value indicates that the property has not been explicitly defined and will inherit defaults or remain undefined.
A zero value, on the other hand, explicitly sets the property to zero, overriding any defaults or inherited values.
This distinction is crucial for ensuring accurate configuration behavior and avoiding unintended consequences.
Operators should carefully review profile settings to ensure the correct interpretation of unset and zero values.

Segmentation

Configuration Profiles allow for addressing almost all settings types, except for those that are organization specific (e.g. network reachability) and the Authorization settings as currently found in the Security Settings resources, which deal with platform isolation concerns. These settings will be handled and enhanced in a new feature called segmentation, scheduled for initial release in TSB 1.12.

Granularity in Configuration

When creating a Configuration Profile, it is not required to fill in all settings. This allows for the creation of topic-specific configurations. As mentioned above, multiple configuration profiles can be attached to a resource, and the order in which they are attached determines the order in which they are applied.

Configuration Resolution Process

The following process is used to resolve the final configuration for a resource:

1. Start with Empty Configuration: Begin with a configuration set with all default values.
2. Organization Profiles: Process attached Organization profiles from left to right.
   • Defaults are overridden by set values.
   • Mandates are overridden by stricter values.
3. Old Style Organization Configuration: Override calculated defaults with existing Organization configuration.
4. Tenant Profiles: Process attached Tenant profiles similarly.
5. Old Style Tenant Configuration: Override defaults with existing Tenant configuration.
6. Workspace Profiles: Process attached Workspace profiles similarly.
7. Old Style Workspace Configuration: Override defaults with existing Workspace configuration.
8. Workspace Level Configuration: Merge defaults and mandates for workspace-bound resources. Defaults are overridden by mandates unless a default is more restrictive.
9. Group Profiles: Process attached Group profiles similarly.
10. Old Style Group Configuration: Override defaults with existing Group configuration.
11. Group Level Configuration: Merge defaults and mandates for group-bound resources. Defaults are overridden by mandates unless a default is more restrictive.
12. Activate Configuration: Apply the resolved configuration to the applicable resources.

Note: Existing TSB noun resource configurations (old style) take precedence over profile configurations by default. An option at the Organization level can force the new configuration system only for greenfield customers or those who have completed migration.

Implementation considerations for Operators

When implementing Configuration Profiles in a TSB environment, operators should consider the following best practices:

Migration Strategy

Plan a gradual migration from old style configurations to profiles. Start by identifying candidate configurations that are suitable for migration. Develop a testing strategy to validate the new profile-based approach in a staging environment. Gradually roll out the profiles to different groups of services, ensuring minimal disruption to existing operations. Monitor the migration process closely to identify and address any issues that arise. Communicate the migration plan and progress to all stakeholders to ensure alignment and understanding.

Profile Organization

Organize profiles logically based on function, environment, or team ownership. This will make it easier to manage and maintain profiles as the platform grows. For example, create separate profiles for development, staging, and production environments to ensure consistency and reduce the risk of misconfiguration. Group profiles by their purpose, such as traffic management, security policies, or compliance requirements, to simplify their usage and maintenance. Use clear and descriptive naming conventions for profiles to make their purpose immediately apparent to operators and developers. Regularly review and update profiles to ensure they remain relevant and aligned with organizational goals. Establish a versioning system for profiles to track changes and facilitate rollback if needed. Document the structure and purpose of each profile to help team members understand their usage and avoid duplication. Consider assigning ownership of profiles to specific teams or individuals to ensure accountability and proper maintenance. Finally, implement a process for deprecating and retiring outdated profiles to keep the configuration system clean and efficient.

Mandate Enforcement

Carefully define and enforce mandates to ensure security and compliance. This may involve creating separate profiles for mandatory settings and ensuring that they are attached at the appropriate level. Clearly document the purpose and scope of each mandate to avoid confusion and misapplication. Regularly review and update mandates to ensure they remain aligned with organizational policies and regulatory requirements. Use descriptive naming conventions for mandate profiles to make their purpose immediately clear. Test mandates thoroughly in staging environments to validate their behavior and impact before applying them to production. Monitor the enforcement of mandates to ensure they are being applied correctly and consistently across the platform. Provide training and guidance to operators and developers on how to work with mandates effectively. Establish a process for handling exceptions or conflicts that may arise from mandate enforcement. Ensure that mandates are applied in a way that minimizes disruption to existing services while maintaining compliance. Finally, maintain a version history of mandates to track changes and facilitate rollback if necessary.

Testing

Thoroughly test profile configurations in staging environments before applying them to production. This will help to identify and resolve any issues before they impact production traffic. Begin by creating a comprehensive test plan that covers all possible scenarios, including edge cases and failure conditions. Use automated testing tools to validate the behavior of profiles and ensure they meet the desired requirements. Perform load testing to evaluate the performance of profiles under different traffic conditions. Conduct security testing to verify that profiles enforce the intended security policies and do not introduce vulnerabilities. Involve multiple stakeholders, including developers, operators, and security teams, in the testing process to gather diverse perspectives and identify potential issues. Document the results of testing and any changes made to profiles based on the findings. Establish a process for re-testing profiles after updates or changes to ensure continued reliability. Finally, maintain a version history of tested profiles to track changes and facilitate rollback if necessary.

Monitoring

Monitor configuration changes and their impact on the platform. This will help to identify any unintended consequences of configuration changes and ensure that the platform is operating as expected. Implement tools and processes to track changes to profiles and their attachments, including version control and change logs. Use monitoring tools to observe the behavior of services and resources affected by profile changes, such as traffic patterns, error rates, and latency. Set up alerts to notify operators of any anomalies or unexpected behavior resulting from configuration changes. Regularly review monitoring data to identify trends and potential areas for improvement. Conduct post-change reviews to evaluate the impact of configuration updates and gather feedback from stakeholders. Establish a process for rolling back changes if issues are detected. Provide training to operators on how to interpret monitoring data and respond to alerts effectively. Document the monitoring strategy and ensure it is aligned with organizational goals and compliance requirements. Continuously refine the monitoring approach based on lessons learned and evolving platform needs.

Documentation

Maintain clear and up-to-date documentation on profile configurations. This will help other team members understand the purpose and usage of different profiles. Clearly outline the structure, purpose, and scope of each profile to avoid confusion and misapplication. Use descriptive naming conventions to make profiles easily identifiable. Include examples and best practices to guide operators in creating and managing profiles effectively. Regularly review and update documentation to ensure it reflects the latest changes and organizational requirements. Provide a version history of profiles to track changes and facilitate rollback if necessary. Make the documentation accessible to all relevant stakeholders, including operators, developers, and security teams. Establish a process for gathering feedback on documentation to continuously improve its quality and usability. Ensure that the documentation aligns with organizational goals and compliance requirements. Finally, provide training or workshops to help team members understand and utilize the documentation effectively.