Red Hat created a knarly system of authentication with OpenShfit. The main issue is auth is handeled by a separate endpoint and when you use it to authenticate it redirects you right away before you can get the token. Here is a code snippit that will help you with that on you Python project.

def get_config_user_pass_hash():

    username = ""
    password = ""
     
    basic_auth_userpass = username + ":" + password

    # Encode to simple auth
    output_bytes = basic_auth_userpass.encode('ascii')
    b64_hash_bytes = base64.b64encode(output_bytes)

    return b64_hash_bytes.decode('ascii')

def get_os_token(hostname):

    url = "https://oauth-openshift.apps." + hostname + "/oauth/authorize"

    ## We need this to tell OAUTH what we want.
    querystring = {"response_type":"token","client_id":"openshift-challenging-client"}

    headers = {
        "Authorization": "Basic " + get_config_user_pass_hash()
    }

    ## The token is in the header before it gets redirected, you just need to turn off that redirect.
    response = requests.request("POST", url, headers=headers, params=querystring, verify=False, allow_redirects=False)

    ## Get the token from the Location header, which you also need to parse to get the token.
    token = urlparse(response.headers['Location'])[5].split("&")[0].replace("access_token=", "")

    return token

host = ""

# Login to cluster and make sure we are in the correct project
token = get_os_token(host)
subprocess.run(["oc", "login", "--server=https://api." + host + ":6443", "--token=" + token])

As you can see above, the token will work with the "OC" command. If you'd like to use a pure REST API request, you can simply use the token as a bearer token:

authentication:
    type: bearer
    token: sha256~

I decided to take a bit of a deep dive into deploying Palo Alto firewalls in Azure. I would like to share my findings and some code to help get people started.

Deployment Type:

In Azure you have an architectural decision based on your familiarity with Azure services. Traditionally, a firewall would be deployed using the cloud providers load balancers and your preferred vendor’s VM. Palo Alto made this process a bit easier by obfuscating all those underlying resources into one main Azure resource called “Cloud NGFWs by Palo Alto Networks”. Here is an overview of the two options:

1. Deploy a resource called “Cloud NGFWs by Palo Alto Networks”.

The advantage of this model is you don’t have to manage the Azure underlying resources, firewall version and scaling. It’s all done automatically for you. All you need to do is add your subnet default route to the internal VIP the resource gives you. You can also manage the firewall set with Panorama and the appropriate Azure plugin.

The disadvantage can also be you cannot control the underlying resources, scaling and license type. The license is purely pay as you go.

2. Deploy the Palo Alto VM-Series and necessary resources.

The advantage can be you get to control all aspects of the deployment like the load balancers, firewall versions, licensing and scaling. You can utilize BYOL licensing, giving you the option of going with firewall credits. This can potentially save money.

The disadvantage is you have to manage a lot more and need existing Azure cloud experience.

The Code:

I created a few repos demonstrating using Terraform and an Azure ARM template.

• Terraform - This will create option 2 above

https://github.com/jcdoes/azure-palo-ngfw

• Azure ARM template - This will create option 1 above.

https://github.com/jcdoes/palo-ngfw-azure-arm-template