Using the Kubernetes API Server
The Prisma Cloud Microsegmentation API uses the apoctl CLI to access, create, or update backend resources. If you are using the kubectl CLI or Helm charts, you don’t need to learn apoctl or change your automation. The Microsegmentation API supports the Kubernetes API server to access resources that are part of the network.prismacloud.io API group.
This guide shows how to deploy the Kubernetes API server in Prisma Cloud and provides examples of the supported commands using the kubectl CLI.
Deploy the Kubernetes API Server
As you deploy the Prisma Cloud Enforcers, you can pass the --install-aggregated-apiserver flag. To learn how to deploy the Enforcer and pass the flag, see Enforcer configuration options.
Use the Kubernetes API Server
Not all Microsegmentation operations are available through the API server. To get the list of all supported API resources, use the following command:
kubectl api-resources --api-group=network.prismacloud.io
The following examples show the operations you can perform and how they are limited. You can copy the commands in these examples into the command line console, and check the output for your system.
Examples
The following examples provide guidance on how to use the kubectl API to operate the Prisma Cloud Microsegmentation API. You can find examples to operate at the enforcer level or at the namespace level of your deployment.
Working at the enforcer level
The following examples show commands and sample configurations that impact the enforcers in your deployment or specific Kubernetes Objects. Replace <object-name>` with the name of the Kubernetes Object in your deployment as needed.
Get the list of the enforcers with the following command:
kubectl get ClusterEnforcer
Get list of enforcer profiles with the following command:
kubectl get ClusterEnforcerProfile
Create an enforcer profile by applying a yaml with the following command:
kubectl apply -f cluster-enforcer-profile.yaml
apiVersion: network.prismacloud.io/v1 kind: ClusterEnforcerProfile metadata: name: cluster-enforcer-profile spec: description: "an enforcer profile created from aggregated-apiserver" targetNetworks: - 10.0.0.0/8 - 100.64.0.0/10 - 127.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16 - 198.18.0.0/15
Re-apply the YAML file to update an enforcer profile with the following command:
kubectl apply -f cluster-enforcer-profile.yaml
Delete the enforcer profile for a given Kubernetes object with the following command:
kubectl delete ClusterEnforcerProfile <object-name>
Replace <object-name>` with the specific Kubernetes Object you want to delete.
List the external networks in the same cluster namespace as the enforcer with the following command:
kubectl get ClusterExternalNetwork
Create an external network by applying a yaml with the following command:
kubectl apply -f external-network.yaml
Sample: external-network.yaml
apiVersion: network.prismacloud.io/v1 kind: ClusterExternalNetwork metadata: name: external-network spec: name: "external-network" description: "an external network for google.com" entries: [google.com, “*.google.com”]
Update an external network by re-applying a yaml with the following command:
kubectl apply -f external-network.yaml
Delete the external network with the following command:
kubectl delete ClusterExternalNetwork <object-name>
List all the network ruleset policies in the same cluster namespace as the enforcer with the following command:
kubectl get ClusterNetworkRulesetPolicy
Create a network ruleset policy using the cluster-network-ruleset-policy.yaml file with the following command:
kubectl apply -f cluster-network-ruleset-policy.yaml
apiVersion: network.prismacloud.io/v1 kind: ClusterNetworkRuleSetPolicy metadata: name: network-ruleset-policy spec: description: "a network ruleset policy created from aggregated-apiserver" outgoingRules: - action: Allow logsDisabled: false object: - - externalnetwork:name=external-network observationEnabled: false protocolPorts: - tcp/80 subject: - - $identity=processingunit
To update the network ruleset policy, apply the updated YAML file with the following command:
kubectl apply -f cluster-network-ruleset-policy.yaml
Delete the network ruleset policy with the following command:
kubectl delete ClusterNetworkRulesetPolicy <object-name>
List the processing unit in the same cluster namespace as the enforcer with the following command:
kubectl get ClusterProcessingUnit
Get the traffic action of the processing unit in the same cluster namespace as the enforcer with the following command:
kubectl get ClusterPUTrafficAction
Update the traffic action of the processing unit in the same cluster namespace as the enforcer with the following command:
Working at the namespace level
The following examples show commands and sample configurations that impact your deployment at the namespace level. Replace <namespace> with the name of the namespace in your deployment.
List the external networks in a Kubernetes namespace with the following command:
kubectl get ExternalNetwork -n <namespace>
To create an external network, apply the external-network.yaml file with the following command:
kubectl apply -f external-network.yaml -n <namespace>
Sample: external-network.yaml
apiVersion: network.prismacloud.io/v1 kind: ExternalNetwork metadata: name: external-network spec: name: "external-network" description: "an external network for google.com" entries: [google.com, “*.google.com”]
To update an external network, apply the updated YAML file with the following command:
kubectl apply -f external-network.yaml -n <namespace>
Delete the external network with the following command:
kubectl delete ExternalNetwork <object-name> -n <namespace>
List the network ruleset policies in a namespace with the following command:
kubectl get NetworkRulesetPolicy -n <namespace>
To create a network ruleset policy, apply the network-ruleset-policy.yaml file with the following command:
kubectl apply -f network-ruleset-policy.yaml -n <namespace>
Sample: network-ruleset-policy.yaml
apiVersion: network.prismacloud.io/v1 kind: NetworkRuleSetPolicy metadata: name: network-ruleset-policy spec: description: "a network ruleset policy created from aggregated-apiserver" outgoingRules: - action: Allow logsDisabled: false object: - - externalnetwork:name=external-network observationEnabled: false protocolPorts: - tcp/80 subject: - - $identity=processingunit
To update a network ruleset policy, apply the updated YAML file with the following command:
kubectl apply -f network-ruleset-policy.yaml -n <namespace>.
Delete the network ruleset policy with the following command:
kubectl delete NetworkRulesetPolicy <object-name> -n <namespace>
List the processing units in a namespace with the following command:
kubectl get ProcessingUnit -n <namespace>
Get the traffic action of a processing unit in a namespace with the following command:
Limitations and Known Issues
The Kubernetes API server support has the following limitations and known issues:
- Using the kubectl CLI, you can’t create two objects for a given resource with the same name. For example, you can’t create two external networks with the external-network-test` name since Kubernetes doesn’t allow it. If you need to create two objects with the same name, you can use the Prisma Cloud UI.
- Using the kubectl CLI, you can’t rename an object. If you name your network ruleset network-ruleset-1, you can’t change its name to network-ruleset-2 since Kubernetes doesn’t allow it. Alternatively, you can create a copy of the YAML file, rename the object, and apply it to create a new object.[WARNING] ==== Backend objects can be lost. After you create a backend object using the console or `apoctl` CLI, avoid creating a new backend object with the same name using `kubectl` and the Kubernetes API server. When you delete the objects using `kubectl`, it deletes all the objects with the same name. Use different names for all your backend objects to avoid deleting them inadvertently. ====When you delete Kubernetes namespaces, all objects created in the namespace using kubectl are deleted. The objects you created using apoctl or the web console are not deleted. If you synced the namespaces with your Prisma Cloud backend, the namespaces remain in the backend even after you delete them using the kubectl CLI.You must update any protected object has to be unprotected before deleting it.
Troubleshooting
Use apoctl to collect logs from the Enforcer.
For more information, see Troubleshooting enforcer.
Most Popular
