You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Will early adopters need the artifacts and components to be supported on multiple public or gov clouds? The initial effort will necessarily focus on one specific cloud environment to make it practical and deliver a proof of concept lab; but artifacts can be curated for extending the deployment to other cloud K8s implementations and control planes and supporting security capabilities.
Describe alternatives you've considered
We can make it explicitly "bare metal" and decide NOT to support commercial or public K8s platforms, and leave that to derivative project or forks, or as commercial or gov cloud provider projects.
Fully embrace multiple clouds and as soon as practicable, test all policy code and compliance code artifacts on multiple clouds, as well as add markdown content with specific details for commercial and gov cloud features/services. For example add cloud-specific operators and call cloud specific security services or use cloud specific IAM or encryption.
Make it configurable to do specific clouds but not actually implement anything specific - just stub things out and document the specific requirements.
Additional context and considerations
For an audit of the artifacts hosted in this project, the auditor likely needs to test an actual hosted environment using these artifacts. Therefore the cost of audit could expand significantly if we want to test multiple cloud implementations simultaneously. Adding elements to the project that are cloud specific and NOT auditing these may undermine the trust and assurance provided by the audit, which is a key goal for gaining early adopters in SLEDGEH environments.
The text was updated successfully, but these errors were encountered:
Describe the solution you'd like
Will early adopters need the artifacts and components to be supported on multiple public or gov clouds? The initial effort will necessarily focus on one specific cloud environment to make it practical and deliver a proof of concept lab; but artifacts can be curated for extending the deployment to other cloud K8s implementations and control planes and supporting security capabilities.
Describe alternatives you've considered
We can make it explicitly "bare metal" and decide NOT to support commercial or public K8s platforms, and leave that to derivative project or forks, or as commercial or gov cloud provider projects.
Fully embrace multiple clouds and as soon as practicable, test all policy code and compliance code artifacts on multiple clouds, as well as add markdown content with specific details for commercial and gov cloud features/services. For example add cloud-specific operators and call cloud specific security services or use cloud specific IAM or encryption.
Make it configurable to do specific clouds but not actually implement anything specific - just stub things out and document the specific requirements.
Additional context and considerations
For an audit of the artifacts hosted in this project, the auditor likely needs to test an actual hosted environment using these artifacts. Therefore the cost of audit could expand significantly if we want to test multiple cloud implementations simultaneously. Adding elements to the project that are cloud specific and NOT auditing these may undermine the trust and assurance provided by the audit, which is a key goal for gaining early adopters in SLEDGEH environments.
The text was updated successfully, but these errors were encountered: