RFD - Oracle join method

[atburke]

This change adds an RFD for the Oracle Cloud join method.

Part of #41705.

[zmb3]

This structure would mean that you have to allow joining from any region from any compartment.

Do we ever foresee a desire to further restrict this? Maybe something like:

allow:
- regions: [ phx ]
  compartments: [ compartment1, compartment2 ]
- regions: [ syd ]
  compartments: [ compartment3 ]

?

[atburke]

What you're suggesting is what I intended, I'm not sure what the difference is between that and what I wrote (other than that I forgot to mention that tenancy is required).

[atburke]

I made a small mistake with instance principal permissions; they only have permission to list compartments by default, not get a compartment. If we stick will no extra permissions, all this means is that we can use compartment names in the Teleport provision token, only OCIDs. I think I prefer this solution since it's less work to set up, but if we do want to keep compartment names, configuring those permissions isn't a huge hassle either.

[nklaassen]

I had a look at Vault's oci auth method https://developer.hashicorp.com/vault/docs/auth/oci

It looks like what they do is:

1. The client signs a request to their own vault URL with their oracle credentials, this is <vault_server>/v1/auth/login/role
2. On the vault server, they include the signed headers from this request in an actual request to the vault auth endpoint auth.<region>.oraclecloud.com/v1/authentication/authenticateClient (ref), this returns the client's principal and tenant ID
3. From there they send another request to get the client's group membership

The downside is this requires the vault server to have oci credentials and the following policy:

allow dynamic-group VaultDynamicGroup to {AUTHENTICATION_INSPECT} in tenancy
allow dynamic-group VaultDynamicGroup to {GROUP_MEMBERSHIP_INSPECT} in tenancy

I think it's possible we could do a version of this, where instead of our auth server signing the authenticateClient request, the node would have to pre-sign THAT request and send it to auth, to send to oracle.

The downside is this would unfortunately require every joining instance to have that AUTHENTICATION_INSPECT policy. The upside is we wouldn't be relying on getting the caller's tenant ID from the undocumented and unverified JWT. I'm not sure if this is viable for us but I wanted to share my findings

[viktor-doyensec-teleport]

Hey team! I just submitted our review of the RFD.

Overall, the "Security" section sufficiently outlines potential security-related issues with the feature. As a recap:

Replay Attacks

Adding a custom header with the challenge that Teleport generates will ensure the legetimacy of the request as well as ensuring that any replys after the token is accepted will be rejected.

JWT Validation

Because Teleport is not able to validate the signature of the JWT, the application cannot be certaing that the claims have not been tempered. To this end, only use values/claims that you can independently verify. All other values should not be considered safe and used without additional validation and verification.

Server-Side Request Forgery (SSRF)

To enrol an Oracle Cloud resource, Teleport will have to perform an HTTP request to Oracle's API to retrieve a list of available resources. This request is in partial control to the request. Proper precautions need to be taked to ensure that SSRF attacks are properly mitigated. This entails:

1. removing the ability for user-controlled URLs - Users should not have control over the destination of the request. This value should be statically defined in the application.
2. strict input validation - Any values that are user-controlled and will be used to build the final request need to undergo strict input validation. Validation should be performed based on the expected parameter type (e.g. UUID) or a pre-defined allowlist of expected values. Any deviations from the expected values should result in an error
3. HTTP redirects - To further protect the application from SSRF attacks, disable any unneeded HTTP redirects. This ensures that the target URL defined by Teleport is the final destination of the request

Let me known if you have any comments or questions.

[atburke]

Friendly ping @nklaassen @strideynet

[nklaassen]

Have you been able to find much about what exactly this policy allows and if it seems acceptable to allow this for all nodes that need to join teleport? If it only allows you call the authenticateClient endpoint it seems okay to me, all it allows is for the node to get information about itself

[atburke]

I haven't found anything that explicitly states what it allows, but these docs on the authentication_oci plugin for Oracle Heatwave (1, 2) suggest to me that it's only authenticateClient.

[atburke]

Friendly ping @strideynet

[strideynet]

Nit: Perhaps a oneof is appropriate here in the request/responses?

[rosstimothy]

@viktor-doyensec-teleport could you please take another look?

[viktor-doyensec-teleport]

Aside from the comment of the Oracle "Dynamic Groups", the RDF looks good to me!

[viktor-doyensec-teleport]

Have you taken dynamic groups misconfigurations into consideration, such as lax rules that would allow unauthorized resources become group members and be allowed to join the cluster? These misconfigurations usually arises from membership conditions that depend on attributes that can be specified by low-privileged users (eg. tags).

If I understand the flow correctly, to join the cluster, an instance needs to satisfy the following pre-conditions:

• be in the expected tenant (satisfied by default)
• be in the expected compartment (this is optional)
• be in the dynamic group (this will be satisfied if the group is misconfigured)

In such a scenario, gaining access to the dynamic group would effectively allow the instance to join the cluster.

I don't consider this an issue on Teleport's side. However, I think an update to the RDF or future documentation to highlight the dangers of such misconfiguration will definitely be useful.

[atburke]

In my mind, the membership of the dynamic group is not intended to be a criteria for which instances are allowed to join; it's just the only available vehicle for giving those instances the needed permissions. The provision token (expected tenancy/compartment/region) is the sole source of who's allowed to join. Ideally the matching rules would exactly match what's in the token; I've added that recommendation to the RFD and I'll include it in the future docs.