enforcer command
The enforcer command allows the management of the enforcer.
collect subcommand
The commands allows you to collect debug information from a specific enforcer.
The enforcer is notified that it should collect and report its debug information.
The command waits until the collection is completed and downloads a tar.gz file.
coredump subsubcommand
The coredump subsubcommand is used to collect coredump from the enforcer.
Examples:
apoctl enforcer collect coredump 981e92db0290 --puid 76fc70b9e07e
counters subsubcommand
The counters subsubcommand is used to collect counters from the enforcer.
Examples:
apoctl enforcer collect counters 981e92db0290
logs subsubcommand
The logs subsubcommand is used to collect logs from the enforcer.
Examples:
apoctl enforcer collect logs 981e92db0290
packets subsubcommand
The packets subsubcommand is used to collect packets from the enforcer.
Examples:
apoctl enforcer collect packets 981e92db0290
pcap subsubcommand
The pcap subsubcommand is used to collect pcap from the enforcer.
Examples:
apoctl enforcer collect pcap 981e92db0290 --puid 870d81caf18f
pustate subsubcommand
The pustate subsubcommand is used to collect processing unit state from the enforcer.
Examples:
apoctl enforcer collect pustate 981e92db0290
techsupport subsubcommand
The techsupport command is a convenient wrapper for collecting logs, counters, and processing unit states from a specific enforcer.
The enforcer is notified that it should collect and report its debug information.
The command waits until the collection is completed and downloads a tar.gz file.
download subcommand
The download subcommand is used to download debug information from the enforcer.
It downloads the latest information sent by the enforcer. If you did not run the collect subcommand,
you will receive the previous information.
Examples:
apoctl enforcer download 981e92db0290 apoctl enforcer download 981e92db0290 -f /tmp/enforcer-981e92db0290.tar.gz
install subcommand
The install subcommand is used to deploy the enforcer on various platforms.
Depending on the platform, it will perform the various needed tasks
to deploy the enforcer and protect your workload.
kubernetes subsubcommand
The kubernetes subsubcommand can be used to deploy the enforcer on a Kubernetes cluster.
Running it over a cluster where everything is already installed will perform
an upgrade if needed.
By default, it will use the kubeconfig in ${HOME}/.kube/config. You can use different kubeconfig
by populating KUBECONFIG environment variable or by using the flag --kubeconfig. By default,
it will target the cluster described by the kubectl current context. You can use a different
context by using the flag --kubeconfig-context.
To deploy enforcer in OpenShift clusters use --enable-openshift=true.
In order to support private image, create the namespace manually and add the secrets
to the namespace before running this command. Once it is setup, you can use the
--image-pull-secrets=secret-name option to reference the secret created earlier.
By default, the latest versions of the charts will be installed.
You can always list all the available versions by using the flag --list.
You can then choose a particular version using the flags --enforcer-version.
apoctl will install the necessary Microsegmentation constructs in the namespace currently
targeted by apoctl with the standard --namespace flag.
Examples:
apoctl enforcer install kubernetes apoctl enforcer install kubernetes --list apoctl enforcer install kubernetes --raw-flags "--log-level=debug --log-format=human" apoctl enforcer install kubernetes --tag 'color=dark blue' --tag size=big
linux subsubcommand
The linux subsubcommand can be used to deploy the enforcer on a Linux host.
By default, apoctl will query the Microsegmentation Console for the local installation
repositories and will detect the current Linux distribution and which installation
procedure is the more suited for it.
It will create app credentials in the targeted namespace, install them on the
host, and deploy an enforcer.
To reduce the output verbosity, you can use the flag --quiet.
You can specify the authentication method to use by --auth-mode. The supported
options are cloud, token and appcred. The default is cloud based authentication which
requires a valid API authorization policy in the Microsegmentation control plane.
For example in AWS:
cat << EOF | apoctl api import -f - APIVersion: 0 label: ec2-enforcerd-auth data: apiauthorizationpolicies: - authorizedIdentities: - '@auth:role=enforcer' authorizedNamespace: /ns name: Authorize EC2 enforcer to access Aporeto control plane propagate: true subject: - - "@auth:realm=awssecuritytoken" - "@auth:rolename=bob" EOF
The subject above contains claims from the Microsegmentation token
retrieved using Amazon Security Token Service (AWS STS).
Refer apoctl auth -h for more details.
To use the token based auth mode, you must pass a valid token using the --token flag.
You should pass only short-lived tokens here which have a very limited lifetime.
The token is going to be passed to the enforcer which will use it to register itself with the Microsegmentation control plane.
It will then issue itself an app credential with reduced privileges.
This will allow the enforcer to reconnect to the Microsegmentation control plane.
However, it will not be possible for the enforcer any longer to register itself again in case the enforcer object was deleted by a third party out of band.
You can define additional enforcer tags by using the flags --tag.
Finally, you can pass additional raw flags that will be forwarded to the enforcer
by using the flag --raw-flags.
Examples:
apoctl enforcer install linux --namespace /my/namespace --token <token> apoctl enforcer install linux --tag color=blue --tag size=big apoctl enforcer install linux --raw-flags '--log-level=debug --log-format=human --disable-log-write=false'
linux-remote subsubcommand
The linux-remote subsubcommand allows you to install the enforcer on one or multiple hosts
using SSH.
It will connect to the provided hosts, make them download apoctl and
run apoctl enforcer install linux remotely.
This subcommand supports protecting various Linux distributions at once.
It also supports the flags supported by apoctl enforcer install linux so they
will be forwarded to the remote installation process.
You can pass the list of hosts as:
This command assumes the following:
Note that you can pass multiple SSH keys.
All the hosts should be able to use at least one of the provided key.
Password authentication is not supported.
You can define how many hosts to protect in parallel by using the flag
--concurrency.
Examples:
apoctl enforcer install linux-remote --docker user@host user@host1:2222 cat myhosts | apoctl enforcer install linux-remote
windows subsubcommand
The windows subsubcommand can be used to deploy the enforcer on a Windows host.
It requires admin privileges.
By default, apoctl will query the Microsegmentation Console for the local installation
repositories and will use the MSI package.
It will create app credentials in the targeted namespace, install them on the
host, and deploy an enforcer.
To reduce the output verbosity, you can use the flag --quiet.
You can specify the authentication method to use by --auth-mode. The supported
options are cloud and appcred. The default is cloud based authentication which
requires a valid API authorization policy in the control plane.
For example in AWS:
cat << EOF | apoctl api import -f - APIVersion: 0 label: ec2-enforcerd-auth data: apiauthorizationpolicies: - authorizedIdentities: - '@auth:role=enforcer' authorizedNamespace: /ns name: Authorize EC2 enforcer to access Aporeto control plane propagate: true subject: - - "@auth:realm=awssecuritytoken" - "@auth:rolename=bob" EOF
The subject above contains claims from the Microsegmentation token
retrieved using Amazon Security Token Service (AWS STS).
Refer apoctl auth -h for more details.
You can define additional enforcer tags by using the flags --tag.
Examples:
apoctl enforcer install windows --namespace /my/namespace --token <token> apoctl enforcer install windows --tag color=blue --tag size=big apoctl enforcer install windows --raw-flags "--log-level=debug --log-format=human --disable-log-write=false"
switch-to subcommand
The switch-to subcommand is used to upgrade (or downgrade) an existing enforcer to a different version.
There are three different ways in how you can target enforcers for an upgrade.
- You simply pass the IDs of the enforcers that you wish to upgrade to as arguments to the command. This simply tries to upgrade the enforcers with the specified IDs in the current namespace. You can change the namespace with the global --namespace flag.
- You can target all enforcers in a namespace by using the global --namespace flag and omitting the IDs of enforcers. If you want to target also all enforcers in all child namespaces recursively, you can additionally pass the --recursive flag.
- If targeting all enforcers in a namespace is too much, you can additionally build a tag expression to match only specific enforcers by using the --selector flag. The tag expression works the same way how for example subject and object expressions in network access policies work: all outer array tags are an "or" match, while the inner array performs an "and" match on all tags. The tag expression will try to match all enforcers in the given --namespace, or optionally in all child namespaces if you also pass the --recursive flag.
NOTE:
The --target-version flag is mandatory and specifies the version that you want to upgrade or downgrade to.
Valid options are the following:- You can pass a valid semver version that all targeted enforcers will be upgraded or downgraded to.
- namespace: You can pass the special value namespace which will try to upgrade or downgrade all targeted enforcers to the default version as set in the namespace of the targeted enforcer. Note that no upgrade or downgrade operation will be performed if the default enforcer version is not set on the namespace of the targeted enforcer.
You have to confirm the upgrade or downgrade operation by passing the --confirm flag.
Otherwise the command would simply print you the operation it would try to perform.
uninstall subcommand
The uninstall subcommand is used to uninstall enforcers
installed with the apoctl enforcer install command.
kubernetes subsubcommand
The kubernetes subsubcommand can be used to uninstall the enforcer and operator
from a Kubernetes cluster.
By default, it will use the kubeconfig in ${HOME}/.kube/config. You can use different kubeconfig
by populating KUBECONFIG environment variable or by using the flag --kubeconfig. By default,
it will target the cluster described by the kubectl current context. You can use a different
context by using the flag --kubeconfig-context.
It will clean the Helm charts deployed on the cluster, remove the Microsegmentation-specific
Kubernetes namespaces, and clean up the Microsegmentation namespace from any resources
previously created by the apoctl enforcer install command.
Example:
apoctl enforcer uninstall k8s --k8s.context mycluster
linux subsubcommand
The linux subsubcommand can be used to uninstall an enforcer from a Linux host.
By default, apoctl will detect the current Linux distribution and which uninstall
procedure is more suited for it.
It will delete the app credentials from the targeted namespace and uninstall
the enforcer.
To reduce the output verbosity, you can use the flag --quiet.
To leave the Microsegmentation repositories configured in the machine, pass
the flag --soft.
Examples:
apoctl enforcer uninstall linux -n /my/namespace
linux-remote subsubcommand
The linux-remote subsubcommand allows you to remove the enforcer from one or
multiple hosts using SSH.
It will connect to the provided hosts, make them download apoctl and
run apoctl enforcer uninstall linux remotely.
This subcommand supports unprotected various Linux distributions at once.
It also supports the flags supported by apoctl enforcer uninstall linux so they
will be forwarded to the remote installation process.
You can pass the list of hosts as:
This command assumes the following:
Note that you can pass multiple SSH keys.
All the hosts should be able to use at least one of the provided key.
Password authentication is not supported.
You can define how many hosts to protect in parallels by using the flag
--concurrency.
Examples:
apoctl enforcer uninstall linux-remote --docker user@host user@host1:2222 cat myhosts | apoctl enforcer uninstall linux-remote
windows subsubcommand
The windows subsubcommand can be used to uninstall an enforcer from a Windows host.
It requires admin privileges.
It will delete the app credentials from the targeted namespace and uninstall
the enforcer.
To reduce the output verbosity, you can use the flag --quiet.
To leave the Microsegmentation MSI package downloaded in the machine, pass
the flag --soft.
Examples:
apoctl enforcer uninstall windows -n /my/namespace
Most Popular
