This topic tells you how to deactivate Grype in Namespace Provisioner and how to configure the default
service account to work with private Git repositories in Tanzu Application Platform (commonly known as TAP).
Grype is installed with Namespace Provisioner by default. If you prefer to use a different scanner for namespaces instead of Grype, you can deactivate the installation of the default Grype scanner.
To deactivate the default installation of Grype for all namespaces managed by the Namespace Provisioner, set the skip_grype
parameter to true
in the default_parameters
section of the tap-values.yaml
:
namespace_provisioner:
default_parameters:
skip_grype: true
By enabling the skip_grype: true
setting, the PackageInstall and the secret grype-scanner-{namespace}
are not generated in the tap-install
namespace for any namespaces that are managed by the Namespace Provisioner.
Using Namespace Provisioner Controller
: To deactivate the installation of Grype for a specific namespace, annotate or label the namespace
by setting the reserved parameter skip_grype
to true
. Use the default or customized parameter_prefixes
. For more information, see Customize the label and annotation prefixes that controller watches.
Using GitOps
: Add the parameter skip_grype
with the value true
in the namespaces file in the GitOps repository.
This section provides instructions on how to configure the default
service account to work with
private Git repositories for workloads and supply chain using Namespace Provisioner.
To configure the service account to work with private Git repositories, follow the steps below:
-
Create a secret in the
tap-install
namespace, or any namespace that contains the Git credentials in the YAML format.host
,username
, andpassword
values for HTTP based Git Authentication.ssh-privatekey, identity, identity_pub
, andknown_hosts
for SSH based Git Authentication.
Note stringData key of the secret must have .yaml or .yml suffix at the end.
#! Example shows HTTP as well as SSH based authentication cat << EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: workload-git-auth namespace: tap-install type: Opaque stringData: content.yaml: | git: #! For HTTP Auth. Recommend using https:// for the git server. host: GIT-SERVER username: GIT-USERNAME token: GIT-PASSWORD #! For SSH Auth ssh_privatekey: SSH-PRIVATE-KEY identity: SSH-PRIVATE-KEY identity_pub: SSH-PUBLIC-KEY known_hosts: GIT-SERVER-PUBLIC-KEYS EOF
-
Create a scaffolding of a Git secret, this must be added to the service account in your developer namespace in your GitOps repository. A sample secret is available in the vmware-tanzu/application-accelerator-samples Git repository. Instead of putting the user name and password in the secret in your Git repository, use the
data.values.imported
keys to put the reference to the values in the git-auth secret created in step 1. For example:#@ load("@ytt:data", "data") #@ load("@ytt:base64", "base64") --- apiVersion: v1 kind: Secret metadata: name: git annotations: tekton.dev/git-0: #@ data.values.imported.git.host type: kubernetes.io/basic-auth stringData: username: #@ base64.encode(data.values.imported.git.username) password: #@ base64.encode(data.values.imported.git.token)
-
Complete the process by customizing the SupplyChain ServiceAccount for all or specific namespaces as described in the following sections.
Customize the SupplyChain ServiceAccount by adding additional secrets
or imagePullSecrets
for all namespaces managed by the Namespace Provisioner. Edit the supply_chain_service_account
parameter in the default_parameters
section of
the tap-values.yaml
file. If you have a separate Service Account for delivery purposes, configure it using the delivery_service_account
parameter. For example:
namespace_provisioner:
controller: true
additional_sources:
- git:
ref: origin/main
subPath: ns-provisioner-samples/credentials
url: https://github.com/vmware-tanzu/application-accelerator-samples.git
import_data_values_secrets:
- name: workload-git-auth
namespace: tap-install
create_export: true
default_parameters:
supply_chain_service_account:
secrets:
- git
imagePullSecrets: [] #! optional
delivery_service_account: #! Not required, specify only if the Service account is different from the Supply chain service account.
secrets: [] #! optional
imagePullSecrets: [] #! optional
- This adds the
git
secret to the Service Account mentioned inootb_supply_chain_*.service_account
. If not specified, it takes thedefault
service account. additional_sources
points to the location where the templated Git secret resides which will be created in all developer namespaces.- Import the newly created
workload-git-auth
secret into Namespace Provisioner to use indata.values.imported
by adding the secret to theimport_data_values_secrets
. - Add the secret to be added to the ServiceAccount in the
default_parameters
To customize the SupplyChain ServiceAccount for a specific namespace managed by the Namespace Provisioner and include additional secrets
or imagePullSecrets
, use the supply_chain_service_account
parameter. This parameter allows you to edit the ServiceAccount and add any required secrets
or imagePullSecrets
.
If you have a separate ServiceAccount for delivery purposes, you can also configure it using the delivery_service_account
parameter.
Using Namespace Provisioner Controller
: Add the following configuration to your tap-values.yaml
file:
Using GitOps
: Add the following configuration to your tap-values.yaml
file:
Note
create_export
is set totrue
inimport_data_values_secrets
meaning that a SecretExport is created for theworkload-git-auth
secret in thetap-install
namespace automatically by Namespace Provisioner. After the changes are reconciled, the secret named git is in all provisioned namespaces and is also added to the default service account of those namespaces.
Namespace Provisioner creates the LimitRange resources on Run clusters in all Namespace Provisioner managed namespaces. For more information, see Default Resources.
You can opt-in to have the LimitRange resource created on Full and Iterate clusters. For more information, see Set/Update LimitRange defaults for all namespaces and Set/Update LimitRange defaults for a specific namespace.
Namespace Provisioner does not create LimitRange resource in Build and View clusters.
Default values in LimitRange resource are as follows:
limits:
default:
cpu : 1500m
memory : 1Gi
defaultRequest:
cpu : 100m
memory : 1Gi
To update the values in LimitRange for all Namespace Provisioner managed namespaces, specify the default_parameters
configuration in tap-values.yaml
as follows:
namespace_provisioner:
default_parameters:
# overwrite default limits set by the OOTB LimitRange (in Run Cluster) for all namespaces
# set default limits for Full and Iterate Cluster in all namespaces
limits:
default:
cpu: 1000m
memory: 1Gi
defaultRequest:
cpu: 200m
memory: 500Mi
Override the LimitRange for specific namespaces as follows:
Using Namespace Provisioner Controller
: Annotate or label a namespace using the default parameter_prefix param.nsp.tap/
followed by the
YAML path to CPU or memory limits as follows:
Using GitOps
: Add the following configuration to your tap-values.yaml
file to add parameterized limits to your developer namespace:
The Namespace Provisioner generates a Kubernetes LimitRange object as a default resource in the namespaces it manages within the Run profile clusters. Additionally, the Namespace Provisioner offers the capability for Platform operators to enable LimitRange object stamping in Full and Iterate profile clusters using namespace parameters. The following options are available to deactivate the installation of the default LimitRange object:
To exclude the installation of the default LimitRange, set the skip_limit_range
parameter to true
in the default_parameters
section of the tap-values.yaml
file as shown here:
namespace_provisioner:
default_parameters:
skip_limit_range: true
Using Namespace Provisioner Controller
: To deactivate the LimitRange for a specific developer namespace, annotate or label the namespace using the parameter skip_grype
and set its value to true
. Use the default or customized parameter_prefixes
, for more information, as explained in the Customize the label and annotation prefixes that controller watches section.
Using GitOps
: Add the parameter skip_limit_range
with the value true
in the namespaces file in the GitOps repository as shown below: