Attention Iron Bank Customers: On March 27, 2025, we are moving SBOM artifacts from the Anchore Scan job to the Build job to streamline the container hardening pipeline. If you currently download SBOMs from the Anchore Scan job, you can still get them from the Build job and from other sources, including IBFE and image attestations.
Current developer docs have multiple choices for deployment that are presented in a non-linear manner. Propose that we simplify the docs by removing choices. Would like to remove the embedding of credentials in remote configuration files.
Edited
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
If you are doing Package development then you need create the k3d cluster with the registry credentials.
If you are doing BigBang development then you SHOULD NOT create k3d cluster with the registry credentials. because the BigBang helm chart creates the registry pull secret in each namespace. And that functionality needs to be tested when developing BigBang.
With a remote k3d cluster there is not an option to not create the registry credentials config on the EC2 server.
I'd argue you shouldn't create the cluster with the credentials in either situation...
For BB development, you should be passing in a values file so that the IPS secret is created for you
For package development, you can "manually" create this secret in the package namespace
What I typically do for package development is (with a script):
create the namespace for the package
kubectl apply a pre-created yaml secret into that namespace (actually two, named private-registry and private-registry-mil)
helm install/upgrade passing in -f tests/test-values.y*ml (this is done because some packages put IPS names in the default values, some in the test values - if we pass in test values we guarantee to catch all cases)
This way the IPS secret gets created and you test that the package can properly accept and use it. I think its more dangerous and confusing to pre-configure your cluster since that's not really the proper BB way of doing it and is different from how you would do it in umbrella.
well stated. And I agree. The developer docs should describe how to manually create the needed secret/s in the cluster instead of instructing how to configure k3d with the registry creds.
The doc/developer/development-environment.md still talks about optionally setting k3d configuration for image pull secrets. That should be moved to an addendum at the end with appropriate wording discouraging its use.
The doc/developer/package-development.md #6 (closed) should have a section added explaining how to manually create a private-registry secret in the namespaces.